Lincoln — Architecture Series

The compile-and-execute path for command intent

A five-part architectural brief. Read in order; each builds on the prior.
Status
Draft for hackathon judging — Army xTech NSH 2026
Date
2026-05-03
Audience
Hackathon judges, integration partners, defense procurement readers
Reading time
~25 minutes end-to-end

Lincoln is a compiler-and-runtime model for command intent. The commander's signed Rules of Engagement are the source program. The mission artifact is the compiled binary. The policy engine is the runtime that executes the binary against fresh tactical inputs at platform speed. The audit chain is the trace of which source paragraph drove each decision. This series walks the compile-and-execute path, identifies what is deterministic and what is language-model-assisted, and states the limitations.

The compiler model A compiler transforms its input, preserving meaning while changing representation for a different consumer. ROE prose is the input form, written for human staff. The mission artifact is the output form, structured for a deterministic evaluator. Human judgment is exercised at compile time, with full operational picture; execute time enforces what was authorized.

§The five docs

§01 · Frame
The compile-and-execute model
Three timescales: compile, execute, audit. What is deterministic, what is signed, what is language-model-assisted, and why those choices are non-negotiable.
§02 · Compile
ROE → MissionArtifact
The compile path. How free-form ROE prose becomes a Zod-typed, paragraph-traced, commander-signed binary. The allowlist, the operator validation step, and the Ed25519 signature.
§03 · Execute
MissionArtifact → decision
The execute path. Hard-block ladder, four-dimensional scoring, paragraph-cited rule trace, signed audit append. Walked end-to-end on the demo's PROP-004 BLOCK.
§04 · Inputs
Feed integration
How heterogeneous tactical feeds — TAK CoT, sensor fusion, replay — land at the schema boundary. The transport-agnostic consumer architecture, and the honest gap between “CoT parser” and “TAK client.”
§05 · Perimeter
The language-model perimeter
Where models live (interpretation, narration, on-device UX), where they don't (the entire decision path), and how the build enforces it via per-package architecture tests.

§The one-paragraph version

A commander writes Rules of Engagement in human language — paragraph-numbered prose, ROE cards, annexes, sometimes hand-drawn overlays. At compile time, an interpretation pipeline (LLM-assisted, allowlist-filtered, operator-validated, commander-signed) turns that prose into a Zod-typed MissionArtifact — the compiled binary. Every rule in the artifact carries a paragraph_ref back to its source. At execute time, the runtime verifies the artifact's Ed25519 signature and refuses to start on mismatch. As proposals arrive from the autonomy stack, a deterministic policy engine evaluates them against the artifact: hard-block predicates fire first; surviving proposals are scored on four dimensions; the result routes to AUTO / QUEUE / ESCALATE / BLOCK. At audit time, every decision is appended to a hash-chained, Ed25519-signed log with the full paragraph-cited rule trace. No language model touches the execute path. The build enforces this via per-package architecture tests that fail on a forbidden import.

§Scope

Claim
Compile-and-execute path for command intent
A signed mission artifact, a deterministic evaluator, a paragraph-cited audit chain. Demonstrated end-to-end on a scripted scenario.
Claim
No language model in the engagement decision
Enforced by spec and by per-package architecture tests. Models are confined to compile-time interpretation and post-hoc explanation.
Claim
Transport-agnostic feed integration
A TAK CoT XML parser ships today. The same typed schema boundary accepts any other track feed — sensor fusion, ADS-B, Link 16, replay — through its own adapter.