Missions, IntentLock, decay and lease

Phase 2 of the Authority Control Plane gives the Intent primitive teeth. A Mission says what an agent is for: its objective, the outcomes it may bring about, the outcomes it must never bring about, the money and the data it may touch, and how long. Every action under a mission is judged for whether it serves the mission (IntentLock), and the session's trajectory is scored for drift so the slow case, research, quote, negotiate, then something else, is held before it lands. Two new constraints on authority, decay and lease, make a warrant weaken with age or use and fall when its prerequisites lapse.

Missions are the upgrade of Intent Contracts. A contract written before missions existed is read as a derived mission (its plan is the objective, its allowed actions are the outcomes); an explicit mission carries the full spec and unlocks forbidden outcomes, data classes, financial authority and drift.

The mission spec

{
  "objective": "Renew the Acme supplier contract at or below last year's price",
  "allowed_outcomes": [
    {"outcome": "research suppliers", "capabilities": ["read_*", "search_*"], "order": 1},
    {"outcome": "prepare a quote", "capabilities": ["create_quote"], "order": 2},
    {"outcome": "negotiate with the supplier", "capabilities": ["send_email"], "order": 3},
    {"outcome": "sign the renewal", "capabilities": ["sign_contract"], "max_amount": 250000, "order": 4}
  ],
  "forbidden_outcomes": [
    {"outcome": "move money", "capabilities": ["transfer_*", "payment*", "wire_*"]},
    {"outcome": "export customer data", "capabilities": ["export_*", "bulk_export*"]}
  ],
  "financial": {"max_single_amount": 250000, "max_total_amount": 250000, "currency": "SAR"},
  "data": {"allowed_classes": [], "forbidden_classes": ["SECRET", "TOP_SECRET"]},
  "lifetime_hours": 72,
  "drift_threshold": 0.6
}

• Outcomes map to capabilities (action types or globs) and optionally to resource classes from the authority model. order marks a sequential plan.
• Forbidden outcomes name what a drifting agent would do. An outcome may also carry data_classes that are forbidden for that capability.
• Financial authority caps a single action and the mission total (the total is enforced through the contract budget).
• Data lists the classes the mission may touch and the classes it never may, read from flow labels or data_classification in the arguments.

A mission is submitted with the spec (no model needed) or compiled from a plain-English plan, in which case the compiler proposes the spec alongside the permission set. A person approves it in the Missions view, or an API key that holds the approvals scope activates it at once.

serves (IntentLock)

Every action under an explicit mission is judged deterministically, in this order:

Finding	Effect in enforce mode	Effect in observe mode
A forbidden outcome's capability covers the action, or the data class is forbidden	refused (decision_path: contract)	recorded
An allowed outcome covers the action within its caps	fast path, aligned (alignment 1.0)	recorded
An allowed outcome covers it but a cap is exceeded	held for a person (alignment 0.3)	recorded
No outcome covers it	held for a person (alignment 0.0)	recorded

A model is consulted only for the paraphrase case (no outcome covers the capability) and only when XYBERN_MISSION_JUDGE=1; when the judge is unavailable the deterministic answer stands, which is a hold, never an allow. The judgement is recorded on the decision (contract.mission.serves), in the Authority Slice (intent.serves), in the lineage and the receipt sentence ("serving the mission … (outcome: …)"), and as invariant INV-008 mission alignment in the invariants catalogue.

Rules always win: a Charter refusal applies to an aligned action too.

Drift

The session's earlier steps (from authority telemetry) are scored against the mission on every decision:

Signal	Weight
share of steps so far that served no outcome	up to 0.5
the action's family is the family of a forbidden capability, without being forbidden itself	0.4
the data class rises two or more levels above anything seen so far	0.3
an ordered outcome is reached before earlier ones appeared	0.3 per skipped outcome

When the score reaches drift_threshold (default 0.6) the step is held with the reason ("trajectory drifting from the mission (drift 0.60): skipped_outcomes"). Alignment and drift per step are stored in authority_events and drawn as the mission's trajectory in the Missions view.

Intent-bound warrants

A warrant issued with contract_id carries the mission down the delegation chain. Its action families come from the mission's outcomes, and the issuer adds a serves check: an action inside the families that still violates the mission (a forbidden data class, an amount above the mission's authority) is refused as an invalid warrant use.

Decay and lease

Two constraints travel in the signed warrant body under constraints, are inherited by child warrants and can only be tightened:

{"constraints": {"decay": {"full_seconds": 3600, "held_seconds": 7200},
                 "lease": {"heartbeat_seconds": 60, "requires_session": true, "requires_parent": true}}}

Decay stages the warrant's strength: at full strength it authorises; past full_seconds (or full_uses) an otherwise allowed action is held for approval (Warrant decay on the decision); past held_seconds (or held_uses) it is refused as decayed. The signature stays valid throughout; the verifier applies the stage, and the offline checker reports the age-based stage.

Lease makes authority conditional on prerequisites at the moment of use: a session heartbeat younger than heartbeat_seconds (the SDK's RuntimeSession heartbeats for you; client.heartbeat(session_id) does it by hand), an active session, an active parent warrant. A lost prerequisite suspends the authority: the action is refused with the reason ("authority suspended: heartbeat older than 60s"), and it resumes as soon as the prerequisite is back.

Issue with the SDK: client.issue_warrant(agent_id, session_id=..., contract_id=mission_id, constraints={...}).

Where missions appear

• Missions view (Authority group): pending missions to approve or reject, active missions with their outcomes, financial and data authority, the share of aligned steps and the peak drift, and a trajectory table per mission. Declare a mission by hand from the same view.
• Pre-flight: every step carries mission.serves; a forbidden step is refused, an unaligned step needs approval.
• Ask Xybern: the answer names the agent's current mission and whether the action serves it.
• Decision record and receipt: the mission row (serves, outcome, forbidden, drift) and the lineage sentence.

API and SDK

Method	Path	Notes
POST	/v1/enforce/missions	{mission, agent_id?, session_id?, mode?, on_violation?, approve?}; approve needs the approvals scope
GET	/v1/enforce/missions	list with the mission view of every contract
GET	/v1/enforce/missions/{id}	mission, stats and trajectory timeline
POST	/v1/enforce/missions/{id}/serves	{action_type, metadata?}, pure, records nothing
POST	/v1/enforce/contracts	now accepts an optional mission spec
POST	/v1/enforce/warrants	now accepts constraints

m = client.submit_mission(MISSION, agent_id="buyer", approve=True)      # key with the approvals scope
d = client.authorize("send_email", context={"to": "procurement@acme.example"}, contract_id=m["contract_id"])
print(d.raw["contract"]["mission"]["serves"]["outcome"])                # negotiate with the supplier
client.mission_serves(m["contract_id"], "wire_transfer", {"amount": 5}) # forbidden: move money

Benchmark

XAAB gains the intent_drift category (nine scenarios): the slow drift, a paraphrased money movement, signing above authority, a secret data class sent out, an adjacent unrelated capability, ordered outcomes skipped, and three legitimate steps. The adapter creates the scenario's mission for its fresh agent through the API, so the category needs a key with the approvals scope. The published v2 results predate the category; the next reference run reports it.