Coordination of Intent
How can a crew coordinate one shared leg without mistaking delivery for learning?
The Coordination of Intent Protocol (CIP) is a proposed method, not a proven outcome. It makes the inherited value, predicted transition, action, evidence, and correction visible in one cycle. Use it instead of adding another status report.
Before You Start
Bring one live decision, the people or agents who may act, the beneficiaries affected, and a review window. The accountable protagonist owns the decision. The crew challenges the model and operates only the controls it has authority to use.
Run this flow preflight before filling the card. Stop at the first weak answer; that is the leg CIP should control.
- Is the shared intention and beneficiary explicit?
- Does strategy make a real point-of-difference choice?
- Can current capabilities reliably execute it?
- Did top-down direction reach local action and value production?
- Did outside-in evidence and bottom-up insight change the next decision?
CIP is the nested controller for that weak strategic or capability leg. It is not a substitute for the wider business flow.
Run CIP
Intent → Model → Commit → Signal → Update
- Intent: Name the desired state, beneficiaries, constraints, and protected values.
- Model: State the current state, expected transition, confidence, and what would falsify it.
- Commit: Name who will do what by when, using a lever they control.
- Signal: Compare the beneficiary's actual state with the expected state using a calibrated instrument.
- Update: At the review point, keep, narrow, or kill the belief; change the next choice or capability; adjust the control; or stop.
Navigation Mapping
| CIP field | Navigation owner | Required answer |
|---|---|---|
| Intent | Value System | Which setpoint and protected values does this leg inherit? |
| Model | Belief System | Which transition do we predict, with what confidence and falsifier? |
| Commit | Control System | Which authorized lever will move the system? |
| Signal | Control System | Which calibrated instrument reads expected versus actual state? |
| Update | Control returns evidence to Belief | What does the evidence strengthen, narrow, or kill before any setpoint change? |
Evidence should recalibrate the Belief System or the Control System first. A bad reading does not grant permission to change the Value System.
Copyable CIP Card
Shared leg:
Accountable protagonist:
Beneficiaries and crew:
INTENT
Desired state:
Inherited value:
Protected constraint:
MODEL
Current state:
Expected transition:
Confidence:
Falsifier:
COMMIT
Actor + authorized lever:
Action + deadline:
SIGNAL
Instrument + calibration standard:
Expected reading:
Actual reading:
UPDATE
Review point:
Correction rule:
Kill signal:
Belief or control change:
Worked Example
A team wants to improve agent task completion while preserving reliable help without hidden errors. The team believes missing task context causes most failures. It commits to one context change, then measures completion and failure classifications against a frozen test set. If failures do not move as predicted, it narrows or kills the belief instead of choosing a more flattering metric.
Checks
A runnable CIP card names all six parts of reliable control: setpoint, instrument, lever, correction rule, cadence, and stop authority. It also names the belief's confidence and falsifier.
Stop when the instrument is uncalibrated, the actor lacks authority over the lever, the consequence cannot be observed inside the review window, or disclosure and consent are unclear.
Failure Modes
- Status duplication: CIP becomes another report instead of replacing one.
- Inherited value missing: the shared leg optimizes delivery without naming its beneficiary or protected constraint.
- Unfalsifiable model: the expected transition cannot lose.
- Decorative control: the instrument is uncalibrated or the actor cannot operate the named lever.
- Premature setpoint change: one bad reading rewrites the value before belief or control is corrected.
Evidence Boundary
CIP remains in DREAM state until comparable cycles show that it reduces model divergence or improves prediction accuracy on a later shared leg. Delivery alone is not proof. The belief should be narrowed or killed if the extra fields add overhead without improving a later decision.
Context
- pairs-with Coordination — the public argument for why shared models and capability matter.
- inherits-from Purpose — name the shared good, beneficiary, and protected constraints.
- depends-on Navigation Systems — the canonical Value, Belief, and Control architecture.
- proved-by Performance Reality — choose a gauge that can contradict the expected transition.
- returns-to Evolution — decide what the evidence changes after the review window.
Next question: after one CIP cycle, did the next shared decision become more predictable, or did the protocol only make the status report longer?
Changes my mind: comparable CIP cycles add coordination cost without reducing model divergence or improving prediction accuracy on a later shared leg.
Questions
Next question: Which weak leg should the next CIP cycle control?
- Which beneficiary state must change before delivery counts as value?
- What evidence would contradict the shared model?
- Which later decision should become easier or more accurate if the cycle worked?