Why LLMs Belong in Coordination, Not Commitment
The seam between probabilistic inference and deterministic commitment is the most important architectural boundary in AI-augmented systems
The Problem
LLMs are impressive at synthesis, surfacing context, and generating options. They are also probabilistic — the same prompt, run twice, may produce different outputs. For many tasks, this is acceptable. For commitments, it is not.
A commitment must be deterministic and attributable. "Who authorized this?" must have a precise answer. "On what evidence?" must have a precise answer. "Under what constraints?" must have a precise answer. A probabilistic output can approximate these answers. It cannot guarantee them.
The worst failure mode in AI-augmented organizational systems is not a hallucination in a summary. It is a system where an LLM "decides" something — generates a commitment-shaped output — and the organization treats it as a commitment, with no record of who authorized it, on what evidence, under what constraints. The commitment was never formed. An inference was mistaken for one.
This is not a criticism of LLMs. It is a precision about what they are. LLMs are fast inference engines that reduce the cost of coordination. They are not authoritative signatories. Confusing the two is not a prompt engineering problem — it is an architectural error. The fix is a hard type boundary, not a better prompt.
Current Options
Why LLMs
LLMs can synthesize evidence across sources, documents, prior commitments, and stakeholder inputs faster than any human process. The coordination cost drops by an order of magnitude.
Organizations often reach surface-level agreement while holding conflicting assumptions. LLMs can surface these conflicts explicitly — "Stakeholder A assumes X; Stakeholder B assumes not-X" — before the commitment is formed.
Rather than presenting a single recommended option, the coordination layer generates multiple options with explicit trade-off structures. Decision-makers commit to an option, not to an LLM recommendation.
Knowledge is distributed across people, documents, and prior commitments. LLMs can translate this distributed knowledge into a shared model that all stakeholders can evaluate before committing.
Trade-offs
The same coordination inputs may produce different outputs across runs. This is acceptable for a synthesis step; it is not acceptable for commitment formation. The type boundary enforces this separation.
An LLM output is not attributable to a specific authorizer with specific credentials. Commitment events require this. The coordination layer produces outputs; the commitment layer produces attribution.
LLMs approximate. A resource constraint is not an approximation problem — it is a satisfaction problem. The commitment layer uses constraint solvers, not inference engines, for hard constraint checking.
The log of what an LLM inferred is not an audit trail for regulatory purposes. A commitment event with a typed authorizer, evidence hash, and constraint verification result is. These are structurally different things.
Our Motivation
The design choice in the commitment infrastructure is explicit: the boundary between the LLM coordination layer and the commitment formation step is a hard type boundary in Rust.
The LLM returns a `CoordinationOutput` struct. This struct is validated — fields are required, types are checked, evidence references must resolve. If the LLM output cannot be parsed into this struct, the coordination step fails with an explicit error, not a silent degradation.
The commitment formation step consumes the validated `CoordinationOutput` and produces a `CommitmentEvent`. The `CommitmentEvent` carries the authorizer identity, the evidence (by reference to the `CoordinationOutput`), the constraint verification result, and the stopping criteria. No string carrying semantic content crosses the boundary without being parsed into a typed field.
This architecture prevents the failure mode by construction. There is no code path where an LLM output becomes a commitment without passing through the typed boundary. If someone wants to bypass the boundary, they must write code that changes the types — and that code will be reviewed. The architecture does not rely on convention. It relies on compilation.
In Practice
/// Output produced by the LLM coordination layer.
/// Must be validated before crossing into the commitment layer.
#[derive(Debug, Deserialize, Validate)]
pub struct CoordinationOutput {
/// Structured summary of evidence reviewed
pub evidence_summary: EvidenceSummary,
/// Explicit list of stakeholder assumptions surfaced
pub surfaced_assumptions: Vec<Assumption>,
/// Conflicts identified across stakeholder positions
pub identified_conflicts: Vec<Conflict>,
/// Options generated, each with explicit trade-off structure
pub options: Vec<ProposedOption>,
/// The option the coordination layer recommends, with rationale
pub recommendation: Recommendation,
}
/// An option proposed by the coordination layer.
/// The commitment layer will validate feasibility before forming a commitment.
#[derive(Debug, Deserialize)]
pub struct ProposedOption {
pub id: OptionId,
pub description: String,
pub resource_requirements: ResourceRequirements,
pub dependencies: Vec<DependencyRef>,
pub risks: Vec<Risk>,
pub trade_offs: Vec<TradeOff>,
}The LLM produces JSON that is deserialized into this struct. If any required field is missing or malformed, the coordination step returns Err — not Ok with degraded data. Validation is structural, not defensive.
/// A commitment event. Append-only — once written, never mutated.
/// This is what the commitment layer produces from a validated CoordinationOutput.
#[derive(Debug, Serialize)]
pub struct CommitmentEvent {
pub id: CommitmentId,
/// The identity that authorized this commitment
pub authorized_by: AuthorizedIdentity,
/// Reference to the CoordinationOutput this commitment was formed from
pub coordination_ref: CoordinationRef,
/// The specific option selected from the coordination layer's proposals
pub selected_option: OptionId,
/// Result of constraint verification — must be Feasible to form a commitment
pub constraint_result: ConstraintVerificationResult,
/// Explicit stopping criteria — when is this commitment discharged or revisited?
pub stopping_criteria: StoppingCriteria,
pub formed_at: DateTime<Utc>,
}
/// Transforms a validated CoordinationOutput into a CommitmentEvent.
/// This function is the hard seam between the probabilistic and the deterministic.
pub fn form_commitment(
output: CoordinationOutput,
selected: OptionId,
authorizer: AuthorizedIdentity,
constraint_result: ConstraintVerificationResult,
stopping: StoppingCriteria,
) -> Result<CommitmentEvent, CommitmentError> {
// Constraint result must be Feasible — infeasible proposals cannot become commitments
if !constraint_result.is_feasible() {
return Err(CommitmentError::InfeasibleProposal {
option_id: selected,
infeasibility_report: constraint_result.infeasibility_report(),
});
}
Ok(CommitmentEvent {
id: CommitmentId::new(),
authorized_by: authorizer,
coordination_ref: CoordinationRef::from(&output),
selected_option: selected,
constraint_result,
stopping_criteria: stopping,
formed_at: Utc::now(),
})
}The transformation from CoordinationOutput to CommitmentEvent is explicit, typed, and validated. The constraint result must be Feasible. The authorizer must be present. There is no pathway from LLM output to CommitmentEvent without passing through this function — and this function either succeeds with a valid CommitmentEvent or fails with a typed error.
Looking Forward
The structured coordination layer pattern will become standard as organizations build AI-augmented commitment systems at scale. The alternatives — full LLM autonomy and manual entry — both fail in predictable ways that become visible when the stakes are high enough.
Full LLM autonomy fails when someone asks "who authorized this?" and the honest answer is "the LLM did, under conditions we cannot precisely reconstruct." Manual entry fails when the coordination overhead is high enough that the LLM benefit disappears under the weight of human review bottlenecks.
The structured coordination layer is not a compromise between these failure modes. It is a different architectural choice that avoids both failure modes by being precise about what LLMs are good at and what they are not.
As LLM capabilities improve, the coordination output structs will become richer — more evidence fields, more option types, more explicit trade-off structures. The type boundary will not disappear. If anything, it will become more important as the coordination layer becomes more capable and the temptation to let it also form commitments grows.
Recommendation
Use LLMs to reduce the cost of coordination — synthesizing evidence across sources, surfacing implicit disagreements, translating distributed knowledge into a shared model, generating options with explicit trade-off structures.
Use deterministic typed systems to form commitments. The commitment event carries the authorizer, the evidence reference, the constraint verification result, and the stopping criteria. None of these fields are approximate.
Never allow the probabilistic and the authoritative to share a type. If your system has a code path where an LLM output becomes a commitment without passing through a typed, deterministic transformation, that code path is an architectural liability. The fix is not a better prompt. The fix is a type boundary.