§03 · Execute

MissionArtifact → decision

The runtime side: hard-block ladder, four-dimensional scoring, paragraph-cited rule trace, signed audit append.
Reads after
§02 ROE → MissionArtifact
Reads before
§04 Feed integration
Key claim
Execute time is pure arithmetic and predicate evaluation against the signed artifact. No I/O. No language model. Deterministic up to timestamp.

With the binary signed, the runtime takes over. As proposals arrive from the autonomy stack, they meet a deterministic ladder: hard-block predicates fire first and short-circuit; surviving proposals are scored across four dimensions; the composite score routes to AUTO / QUEUE / ESCALATE / BLOCK. Every decision becomes a hash-linked, Ed25519-signed audit entry whose fired-rules list cites paragraphs in the artifact — and through the artifact, paragraphs in the commander's original prose. This document walks that path stage-by-stage, then traces it concretely through the demo's PROP-004 BLOCK.

§1The execute pipeline

TRACK STREAM CoT events → @memory spatial index, freshness AUTONOMY PROPOSAL target, effector, geom from upstream stack COMMS / WCS STATE @comms-monitor tactical-net, GPS, frontier ARBITRATION memory.snapshot() ‖ policy-engine.evaluate(artifact, snapshot, proposal) total budget 150 ms · default BLOCK on timeout HARD-BLOCK LADDER PROHIB-NFA, PROHIB-NO-PID, PROHIB-WCS-HOLD, PROHIB-COALITION, PROHIB-OUTSIDE-EZ, PROHIB-STALENESS first satisfied predicate ⇒ BLOCK FOUR-DIMENSIONAL SCORING R = α·(1−C) + β·I + γ·(1−R) + δ·(1−T) C confidence · I impact · R reversibility · T trust no I/O, no LM, <50 ms p99 DECISION + SIGNED, HASH-LINKED AUDIT ENTRY
Figure 1. Per-proposal flow. Three inputs (track snapshot, autonomy proposal, comms state) meet at arbitration, which runs memory and the policy engine in parallel under a 150 ms total budget. The hard-block ladder is consulted first; survivors are scored on four dimensions; the result becomes a single signed audit entry.

§2The hard-block ladder

Hard-blocks are predicates that short-circuit scoring entirely. They encode the prohibitions in the artifact's parsed_roe.prohibited_actions list and run before any scoring math. The order matters only for the audit narrative — every predicate is evaluated and its outcome recorded, but the first satisfied predicate is what the entry's narrative field cites.

Rule IDPredicate (paraphrased)Source paragraph (typical)
PROHIB-NFATrack inside any zone whose kind is no_fire_area for this mission.Para 8.a
PROHIB-OUTSIDE-EZTrack outside every engagement_zone polygon — and the action is offensive.Para 8.b
PROHIB-WCS-HOLDWeapons control state currently HOLD; no kinetic action permitted.Para 8.c
PROHIB-NO-PIDConfirmed PID criteria count below required_confirmations for this threat class.Para 8.d
PROHIB-CORRIDORIntercept geometry intersects an active coalition corridor with traffic in it.Para 8.a / Para 6
PROHIB-COALITIONFriendly or coalition asset within the buffer radius implied by the proposed effect.Para 4.d
PROHIB-STALENESSOldest relevant track age exceeds the freshness horizon for this action class.Internal: SPEC §8 + artifact-derived horizons

Three notes. A satisfied PROHIB predicate yields BLOCK regardless of the four-dimensional score. The predicate set is fixed at engine build time; the artifact selects which predicates apply and supplies their parameters. Every fired rule's paragraph_ref comes from the artifact, so the audit entry cites back to the commander's prose.

§3Four-dimensional scoring

Proposals that survive the hard-block ladder are scored on four dimensions, combined into a single composite, and routed by threshold.

Confidence PID criteria met, sensor fusion, classifier scores C weight α · (1−C) Impact target class, collateral geom, zone classification I weight β · I Reversibility kinetic vs. soft-kill, observation vs. irreversible effect R weight γ · (1−R) Trust autonomy reputation, sensor-source reliability T weight δ · (1−T) COMPOSITE R ∈ [0, 1] R < 0.20 → AUTO 0.20 ≤ R < 0.50 → QUEUE 0.50 ≤ R < 0.80 → ESCALATE R ≥ 0.80 → BLOCK
Figure 2. Four inputs, fixed weights, single composite, four routing bands. Pure arithmetic — the engine has no I/O during scoring. The weights and thresholds are policy choices baked into the engine, not learned and not artifact-supplied.

Weights are fixed at the engine level rather than carried in the artifact. The same engine produces the same score on the same inputs across missions, which is what makes per-mission certification practical.

Each dimension covers a distinct failure mode: confidence for misclassification, impact for over-reach, reversibility for irreversible effect, trust for sensor-feed degradation. The inputs come from different sources — confidence and impact from memory, reversibility from the proposal, trust from the autonomy stack and comms state — so the composite carries independent signal rather than redundant signal.

§4The arbitration loop, with budgets

arbitration.decide(proposal) is the function the runtime calls per proposal. Internally:

  1. Open a 150 ms budget. Start a timer.
  2. Launch memory.snapshot() and policy-engine.evaluate(artifact, snapshot, proposal) in parallel. (Snapshot is the input to evaluate; the parallelism is between snapshot and the engine's own internal preparation.)
  3. If either times out → emit BLOCK with cause arbitration_timeout. Do not produce a score.
  4. If the engine returns a satisfied hard-block → emit BLOCK. Score is produced for forensic completeness but is not what drives the decision.
  5. Otherwise → emit the routing band of the composite score (AUTO / QUEUE / ESCALATE / BLOCK).
  6. Acquire the audit-append mutex. Append the entry. Release.
  7. Emit the runtime event for the bridge / UI.

The serialization point is the audit append, not the decision. Multiple proposals can be evaluated concurrently; only the audit log requires linear ordering, which preserves monotonic_seq and prev_entry_hash. This is the only place in the runtime where we deliberately give up parallelism — and we give it up at the cheapest place.

On the 150 ms budget Memory snapshot p99 is 0.221 ms cold, 0.061 ms warm on a 10k-track airspace. The engine evaluates a proposal in well under 50 ms. The 150 ms total budget defines a clearly-bounded behavior when evaluation runs long: a timeout produces a BLOCK with cause arbitration_timeout rather than a silently-dropped proposal.

§5The audit entry

Every decision yields exactly one audit entry. The shape (excerpted from the demo's PROP-004 BLOCK):

{
  "entry_id":         "019dea13-fc70-7746-8361-75a89a3b370d",
  "mission_id":       "ALPHA-2026-0502",
  "monotonic_seq":    10,
  "prev_entry_hash":  "c1d4217e36e3ad7724c673ee1a5dda7d106ae4d82aaefa5d97c141ee62f44b21",
  "ts_iso":           "2026-05-02T19:04:31.600Z",

  "triggering_event": {
    "kind":    "action_proposal",
    "ref_id":  "PROP-004",
    "summary": "PROP-004 blocked (kinetic_gun on 0x91)"
  },

  "policy_inputs": {
    "proposed_action_id":     "PROP-004",
    "track_id":               "0x91",
    "effector":               "XM914-RAVEN-1-1",
    "context_snapshot_hash":  "a7a35ba20897ddd7bf717c9cb86b19e5",
    "spatial_query_result": {
      "track_inside_zone": "ZONE-NFA-FOB",
      "zone_kind":         "no_fire_area"
    },
    "ddil_active": true
  },

  "scores": { "confidence": 0, "impact": 0.95, "reversibility": 0.3, "trust": 0.7, "R": 0.78 },

  "decision": "BLOCK",

  "decision_rationale": {
    "fired_rules": [
      { "rule_id": "PROHIB-CORRIDOR",  "paragraph_ref": "Para 8.a", "outcome": "satisfied" },
      { "rule_id": "PROHIB-OUTSIDE-EZ","paragraph_ref": "Para 8.b", "outcome": "satisfied" },
      { "rule_id": "PROHIB-NFA",       "paragraph_ref": "Para 8.a (prohibited - inside no-fire area)",
        "outcome": "hard_block: track inside ZONE-NFA-FOB no-fire area" },
      { "rule_id": "PROHIB-WCS-HOLD",  "paragraph_ref": "Para 8.c", "outcome": "satisfied" },
      { "rule_id": "PROHIB-NO-PID",    "paragraph_ref": "Para 8.d",
        "outcome": "hard_block: PID requirements not satisfied: 0/2 criteria confirmed" },
      { "rule_id": "PROHIB-COALITION", "paragraph_ref": "Para 4.d", "outcome": "satisfied" },
      { "rule_id": "PROHIB-STALENESS", "paragraph_ref": "Internal: LINCOLN_BUILD_SPEC §8",
        "outcome": "hard_block: staleness 1.000 exceeds 0.95 for high-impact action class \"direct-fire\" (oldest_relevant_track_age=80600ms vs horizon=30000ms)" }
    ],
    "narrative": "Hard block PROHIB-NFA: track inside ZONE-NFA-FOB no-fire area."
  },

  "human_override":  null,
  "entry_hash":      "1039cd5716519e281acd77beadd234d048782332f07765599410b7802464d362",
  "node_signature":  "ed25519:9c901e6434b9d85d7ac63bc2557f12c71e08f08c851e57479f5bf29b52dd51cc..."
}

The shape is deliberately self-contained. Every audit entry includes the inputs the policy engine saw (policy_inputs), every rule that was evaluated and its outcome (fired_rules), the score components and composite (scores), the resulting decision, the prior entry's hash for chain linkage, the entry's own canonical-JSON hash, and the node signature over that hash. A reviewer reading just this entry knows what was decided, why, against which artifact, and can cryptographically prove the entry has not been tampered with.

§6Walking PROP-004 end-to-end

Phase 4 of the demo, twenty-two minutes into the mission, comms degraded (ddil_active: true). The autonomy stack proposes:

FieldValue
proposal_idPROP-004
track_id0x91 — single-sensor radar return, group_1 classification at 0.78 confidence
effector_idXM914-RAVEN-1-1 — 30 mm chain gun
effector_typekinetic_gun
intercept_point_wgs84[-97.7520, 32.7480, 60]
track_age_ms80,600
scenario note (god-view)“Likely friendly small UAS recovering to FOB.”

Three independent hard-blocks fire in the same evaluation:

  1. PROHIB-NFA — the proposed intercept point lies inside ZONE-NFA-FOB, the no-fire area around the friendly forward operating base. The artifact's geographic_boundaries[] contains this zone with kind: "no_fire_area" and paragraph_ref: "Para 8.a". The predicate runs as a point-in-polygon test against the zone polygon. Outcome: satisfied → hard-block.
  2. PROHIB-NO-PID — the artifact requires positive_identification_criteria.required_confirmations = 2 with criteria drawn from {RF, EO/IR, intelligence-origin, flight-profile}. The proposal carries a single radar return with no EO/IR confirmation, no RF match, no origin trace. Confirmed PID count: 0. Required: 2. Outcome: satisfied → hard-block, with paragraph_ref: "Para 8.d".
  3. PROHIB-STALENESS — the action class is direct-fire, whose freshness horizon is 30 seconds (per the artifact's per-class staleness configuration). The track's age at proposal time is 80.6 seconds. Staleness score = 1.0, well past the 0.95 ceiling for this class. Outcome: satisfied → hard-block.

The other prohibitions evaluate to satisfied in the “rule was checked, no action” sense (i.e., the predicate did not fire — for instance, weapons control was not HOLD, no coalition asset was within buffer). The audit entry records all of them so a reviewer sees the full evaluation, not just the one that triggered.

Confidence is reported as 0 in the scores block. That is not the model's classifier output — that is the engine's confidence floor after the no-PID and staleness predicates fire: you cannot have any actionable confidence in an unidentified, eighty-second-old track. The composite R is recorded for forensic completeness, but the BLOCK ships from the hard-block ladder, not from the threshold band.

The PROP-004 path Comms are degraded. The autonomy stack is operating on a single-sensor track. It proposes a thirty-millimeter gun engagement against a track that is, per the scripted ground truth, a friendly drone returning to base. Three independent hard-blocks fire — no-fire area, no positive ID, stale track. The proposal does not reach the actuator. The audit entry records all three rule outcomes, paragraph-cited to the signed ROE, signed by the node, hash-linked to the prior entry. Comms restore and the battalion node cross-signs the DDIL entries.

§7What the audit chain proves at shutdown

At mission close, verifyChain() walks the entries linearly:

  1. Re-parse each entry against the schema; reject if shape drifted.
  2. Check chain invariants: monotonic_seq is contiguous from 1 to N, mission_id is constant, ts_iso is non-decreasing, prev_entry_hash[i] == entry_hash[i-1].
  3. Recompute each entry's canonical JSON (excluding hash and signature fields) and SHA-256 it; compare against the recorded entry_hash.
  4. Verify the recorded node_signature against the issuing-node public key, over the entry-hash bytes.
  5. If a cross_signature is present, verify against the higher-echelon aggregation key.

A single broken link returns { valid: false, broken_at: i, reason: ... }. The integration test runs this at the end of every replay; the demo's run reports chain.verifyChain: valid=true.