Chapter 7 – Mission Objects: From Intent to Activation

Before Activation, a Mission Object is only a proposed work contract. Activation by an authorized identity or adopted policy must name its exact content-addressed Mission identity; the drafter cannot authorize execution merely by producing it. Parsing proves only that the object has the required structure. It does not prove that the intent is correct or grant permission to execute it.

The lifecycle separates three authority events. Activation authorizes one exact Mission identity to run. Admission makes a candidate effective in Terrain. Adoption makes a Map or policy authoritative. None implies either of the others.

The Mission Object packages bounded context, comparable evidence, and finite stopping so payments-service work can run repeatedly without reconstructing authority from tickets, chats, or prompts. Chapters 8 and 9 carry that contract into Map maintenance and recurring selection.

What Belongs in the Contract

The categories in the opening table serve different purposes.

The objective names the outcome without prescribing every implementation move. Authority identifies the adopted contracts, policies, or decisions allowed to define correctness for the governed property. Read access does not confer authority: a source may be relevant evidence while remaining unable to instruct the run.

Effects bound where and how work may occur. They include writable regions, denied paths, external systems, network access, credentials, and any behavior the run may not perform. Outputs and checks define what the workflow must produce and how selected properties will be evaluated. “Fast enough” is not an executable condition; a fixed workload, environment, measurement protocol, threshold, and tolerance can be.

The contract also fixes when execution must stop and what may happen afterward. Stopping and handoff name the budgets, permitted routes, required approvals, response to missing evidence, and declared handoff for each output. That handoff may be local acceptance, report delivery, Admission, or Adoption.

Declared routing ends a run as complete, no_change, blocked, or failed. A checked-report workflow may reach complete without producing a proposal. In proposal-producing work, complete records proposal closure: the final artifact is a supported proposal, and the Run Record is sealed. no_change means the required property already held and no candidate effect exists. blocked names an external repair or decision; other unsuccessful execution ends as failed. None of these results merges, deploys, admits, or adopts an artifact.

A criterion that cannot produce evidence under a declared decision protocol remains an explicit human review item or a deferred quality goal. A machine-readable field must not conceal subjective judgment.

Authority and Evidence Are Different Artifacts

One mutable document cannot safely serve as both instruction and history. A run uses two related artifacts:

The Run Record is the evidence record for one execution. Findings may guide the next attempt or support a later Mission proposal, but they cannot rewrite the active Mission. A changed objective, writable scope, budget, check plan, or handoff rule requires a new Mission version and a new Activation decision.

The same separation applies to outputs. A workspace output, such as the edited README, is part of the candidate. An evidence output, such as the protected Map-alignment report, is retained because the Mission or policy declares it necessary for reconstruction or decision. A workflow should not copy every generated file into its evidence store. Declared output checks must finish before proposal closure, but retaining an artifact does not admit it into Terrain or adopt it as a Map or policy.

The Mission Lifecycle

A human, planner, Sensor, or model may draft a Mission Object. Drafting is assistive, not authoritative.

Intent Compilation

Ordinary-language intent cannot authorize a structured run by itself. A drafter must translate it into a Mission Object proposal that references the adopted sources. That proposal-producing translation is Intent Compilation. It ends with the structured draft, which may still contain symbolic references. Binding, semantic and policy review, and Activation are subsequent stages.

The path from request to execution follows one order:

1. Draft. A human or assistive system proposes the objective, authority, effects, checks, budgets, routing, and declared handoff. References may remain symbolic at this stage.
2. Structural parsing. A parser checks the required fields, types, and reference syntax. A well-formed object may still misstate the intent or exceed policy.
3. Binding. A read-only mechanism that neither the drafter nor the future runner may modify resolves immutable identifiers for every element that materially defines execution: each authority source, the baseline, required checks or check-validation protocols, the policy bundle, the workflow or template, and the runtime. It replaces the symbolic references and computes the content-addressed identity of the fully bound proposal. A missing or ambiguous binding rejects the proposal.
4. Semantic review. An authorized reviewer or adopted mechanism evaluates the fully bound proposal against adopted intent and rejects material omissions, conflicts, or invented assumptions.
5. Policy review. An authorized reviewer or adopted mechanism evaluates whether the fully bound authority, effects, checks, budgets, routing, and handoff comply with adopted policy.
6. Activation. An authorized identity or adopted policy authorizes that exact content-addressed Mission identity to run and records the approval basis.
7. Preflight. A mechanism outside candidate authority verifies that the already-authorized Mission identity and its bound dependencies remain present, intact, and executable. It may not select, replace, change, or rebind them, repeat semantic or policy review, or decide current-state Admission eligibility.

Any edit after Binding creates a new proposal identity that must be parsed, bound, and reviewed again.

For example, a model can turn “document the payments service’s /v2/charges endpoint without changing code” into proposed contract fields with symbolic references. Binding resolves an OpenAPI digest, a Git base commit, the check or protocol identity, the adopted policy bundle, and the workflow, template, and runtime versions. Semantic and policy review then evaluate that exact proposal. Activation authorizes its content-addressed Mission identity. Preflight confirms that the authorized identity and its bound artifacts remain present, intact, and executable; it fails rather than substitute a newer source, check, policy, or runtime.

Once activated, the Mission remains fixed for the run. The workflow may choose only among its declared transitions. It cannot widen scope, change the declared acceptance basis, promote a new check to decisive status outside an authorized protocol, change a budget, reinterpret missing evidence as success, or authorize Admission or Adoption. Those are changes to authority, not refinements of a candidate.

A later Mission version may supersede the contract for future runs. Existing Run Records continue to refer to the version under which they ran.

Checks Bind to the Candidate

Chapter 3 defined structured findings, and Chapter 5 defined finite routing under one Mission. The Mission Object binds those mechanisms to one run. It names the required checks or check-validation protocols, whose acceptance meaning remains outside candidate authority, while each report records the candidate and configuration identities it evaluated.

Only complete, internally consistent evidence from the declared check set or check-validation protocol may support a transition. A finding may enter the next attempt as tagged evidence. It cannot become a new instruction, expand authority, or substitute for a check that did not run.

Recorded candidate-proposed tests and results are evidence, but their shared origin means they do not provide independent corroboration by themselves. A declared protected protocol may validate them, and the active Mission and protected policy decide how they count.

Reuse Without Self-Authorization

Templates can declare the shape of recurring work: default budgets, permitted check identities, routing, and output classes. Specialization still supplies the objective, authority, effects, and evidence requirements, then follows binding, semantic and policy review, and separate Activation.

A rejected candidate may contain a useful fragment. That fragment remains untrusted. A later run may reuse it with provenance, but it must re-enter as part of a new candidate inside declared scope, pass the ordinary checks, and follow its declared handoff. Salvage does not promote failed work.

The same rule governs recursively proposed work. A maintenance scan may produce a draft Mission, and run history may suggest a better template policy. The draft Mission must be bound and reviewed before separate Activation; the proposed template policy requires separate Adoption before it can govern future work.

The Mission Object is therefore not a detailed ticket and not a prompt wrapper. It is the stable boundary between requested work and executable authority. Together, the two records make the change process inspectable and reusable as structured data. The Mission Object states what may happen; the Run Record preserves what did happen. The system can then reuse the workflow without asking a model to infer permission on every run.

The organizational consequence is repeatable delegation. An organization may adopt a delegation policy or template for a stable class of work once; that Adoption does not activate its instances. Every invocation still requires a fully bound Mission whose exact identity receives policy-authorized Activation against current authority and state. Reusable policy and evidence contracts remove repeated negotiation, not the authority decision for each run.