Official protocol document

THE KNIGHT SHIELD PROTOCOL

v0.2 · Working draft

Status

Draft v0.2 + v0.2.1 execution-slot amendments (1–8) applied. The protocol is not locked overall.

Owner: Knight Shield Digital Inc.
Dated: 2026-07-31
Lock condition: Founder approval after full canon review.

Source of truth: KSD Notion canon.

This is an official working document, not marketing copy. The public product page describes what The Pentagon offers; this page carries the current protocol text as written.

Section 0

What this document is

The fixed operating protocol for the Pentagon — KSD's branch-controlled mission execution system. It defines what the system guarantees to do identically on every mission (the rails), and deliberately does not script the intelligent work (the cargo).

Section 1

Core principle — deterministic rails, intelligent cargo

Process is deterministic. Same gates, proof requirements, state transitions and return-to-step behaviour on every mission.
Work is not scripted. Solution, research, content and judgment adapt to the mission.
Determinism lives in the harness — Temporal workflow, Supabase constraints and the proof rule — not in reasoning.

Section 2

Guarantees G1–G15

Execution slot

At most one mission may hold the execution slot. The slot begins at opening and is released only after close_pending → complete with reset proof. Drafts, confirmations and queued missions may coexist.

Proof before progress

No step advances without proof. Proof is a frozen contract: expected claim, target, verification method, readback result, scope version, timestamp, actor. Generated text is not proof.

Branch classification

Every material issue becomes a Blocking or Non-Blocking branch. Parking Lot is a disposition, not a classification. Duplicates attach to the existing branch.

One active branch

Only one branch is active at a time. Branches require proof to close. Nested branches maintain a durable return stack; only the deepest executes. Force-Unblock is a founder signal for unresolved blockers.

Durable return

Closing a branch returns to the exact durable checkpoint after reconciliation. External retries require idempotency keys.

No close over an open blocker

Successful mission close is impossible while a blocking branch is open. Failed or cancelled terminal disposition may close with founder approval and logging.

Reset at close

Mission close resets temporary state, permissions, tokens, locks, timers, caches and working memory while retaining immutable mission, proof, audit and close history plus approved carry-forward items.

Scope freeze

Scope freezes at confirmation. Material changes require new intake and confirmation; implementation choices inside scope may proceed if logged and proof-gated.

Approval authority

Founder approves founder gates. The Pentagon executes. External approval contacts confirm scope and acceptance only where applicable and cannot activate a KSD mission.

G10

No forced manual technical work

Manual technical work forced onto the founder is a system failure and triggers tool evaluation. Non-delegable human consent (OAuth, MFA, legal, identity, authorized spend) is a valid founder gate.

G11

Systems of record

Notion is human canon. Supabase is the machine ledger. Temporal holds execution position. Runtime status shown to the founder comes from Supabase, not Notion. Human completion requires a Notion record; system completion requires the Supabase ledger.

G12

Privacy by default

The Midnight Lens privacy standard runs by default on every mission: minimum disclosure, no silent collection, no undisclosed logging, privacy receipt at close.

G13

Credit control

Credit control is mandatory before paid actions unless the confirmed mission budget already authorizes them.

G14

Regulated-money boundary

Protocol language cannot bypass FINTRAC or regulated-money boundaries. No live wallet, money movement, custody, escrow or settlement without required registration, scope and written approval.

G15

Lock requires approval

Nothing becomes LOCKED without explicit founder approval.

Section 3

Additional architectural rules

Intelligent cargo isolation. All LLM reasoning, research and specialist work is wrapped in Temporal Activities, never in the Workflow Definition.

Outbox pattern. Activities do not write proof directly to the main ledger; proof moves through a pending/outbox-style idempotent commit path.

Database lock. A fail-closed constant-expression partial unique index enforces the single execution slot.

CREATE UNIQUE INDEX missions_one_execution_slot_uidx
ON public.missions ((true))
WHERE status NOT IN ('draft', 'confirmation_pending', 'queued', 'complete');

Service-role acquisition, atomic confirm/queue/acquire and proof-gated complete are part of v0.2.1.

Proposed — requires founder approval before lock

Proposed amendment — Independent Intelligence + Mission Readiness

This block is a proposed protocol expansion under validation. It does not renumber, replace or amend G1–G15, and it is not locked or represented as implemented runtime behaviour.

Independent Intelligence Council

Multiple independent AI systems may be assigned to the same material decision. Where practical, each system must reason independently before seeing peer outputs, so that no model anchors the others. No agent simulates another. Each independent output becomes attributable decision evidence and is retained before synthesis. The orchestrator then compares routes against outcome, evidence, risk, cost, permissions, technical feasibility, reliability and proofability before selecting or synthesizing the route that advances. Specialist seats (strategy, research, engineering, design, verification) are defined by capability, and a single system must not simultaneously hold planner, critic, builder and verifier for the same decision.

Capability-based provider seats

Mission roles are defined by capability. Provider or vendor identity is runtime configuration, not part of the mission contract. Replacement must not reset mission state.

Provider health / crossover trigger

Crossover may trigger on capacity threshold, provider or rate-limit error, repeated failed calls, missed heartbeat, or no material progress within the permitted step heartbeat. If provider telemetry is unavailable, a configurable elapsed time may be used as a fallback. No universal seven-minute rule is hard-coded in protocol copy.

Mission Readiness Gate

Before execution opens, determine required tools, accounts, connectors, permissions, environment, cost and proof plan; verify existing access; auto-configure delegable setup; ask the human only for non-delegable consent; block opening if a required dependency remains unresolved unless explicitly waived or deferred under protocol.

Readiness Receipt

Before opening, persist a machine-readable readiness record: required systems, verified access, missing consents, approved cost envelope, assigned capabilities and providers, fallback providers and routes, proof contract and readiness result.

Section 4

State machine — v0.2

draft → confirmation_pending → queued → opening → active → (blocked ⇄ active)* → close_pending → complete

Terminal outcomes are success/complete, cancelled, failed and superseded. All of them require a Close Packet. Only a successful complete means success.

Section 5

Proof rule — v0.2

1Expected claim
2Target
3Verification method
4Readback result
5Scope version
6Timestamp
7Actor

A generated sentence is not proof. A URL alone is not proof. The URL plus a readback confirming the expected claim is proof.

Section 6

Gates

Intake gate

A mission cannot begin without a complete, accepted brief.

Confirmation gate

Scope is read back and confirmed before the mission opens.

Proof gate

A step cannot advance until its proof contract is satisfied.

Founder gate

Founder-only decisions stop execution until answered.

Quality gate

Work must meet the stated acceptance standard before close.

Close gate

Close requires reset proof and a Close Packet.

Section 7

Branch rules

Blocking

Execution stops. The mission cannot advance or close until the branch is resolved with proof.

Non-blocking

Recorded and tracked alongside execution. It must still be dispositioned before close.

Parking Lot

A disposition applied to a branch that is deliberately deferred — not a separate classification.

All branches are quality controls, not extra charges.

Section 8

Roles and system responsibilities

Founder / Approver

Holds approval authority for founder gates and lock decisions.

Orchestrator role

Sequences the mission, enforces gates and holds the return stack.

Specialist executors

Perform the intelligent work inside the rails.

Temporal execution engine

Holds durable execution position and retries.

Supabase machine ledger

Immutable machine record of mission, proof and audit state.

Notion human canon

Human-readable source of truth for approved canon.

Separation rule

No agent simulates or speaks for another.

Specific provider assignments are runtime configuration and remain subject to protocol approval and crossover rules.

Section 9

What the protocol does not fix

The protocol does not fix the mission solution, the research approach, branch-classification judgment, content or wording, tool choice, or how done is demonstrated. It governs how work is controlled, not what the answer must be.

Section 10

Open review items

Status model — is the current status set complete and correctly bounded?

Confirmation timing — when exactly does scope freeze take effect?

Auth model — how are actors authenticated across systems of record?

Confirmation channel — which channel is authoritative for confirmation?

Non-blocking branch cap — is there a maximum before a mission must stop?

Automation / Temporal overlap — where does automation end and execution begin?

Reset scope — exactly what is reset and what legitimately carries forward?

Over-constraint check — does any rule block legitimate work?

Proposed review items — independent intelligence + readiness

What decisions require multi-provider independent review versus single-specialist execution?
Default heartbeat / stall policy by task class.
Minimum fallback-provider requirements before a mission may open.
Customer-facing authentication and connector ownership model.
Whether confirmation occurs before or after readiness.

Recommended target sequence: intake → readiness/preflight → customer confirms final scope, access and cost → opening.

Section 11

Implementation reconciliation — not all complete

Execution-slot amendments applied (v0.2.1).
Outbox write-path follow-on work.
Proof contract expansion.
Nested branch return stack.
Idempotency, heartbeat and Force-Unblock handling.
Remaining Temporal and runtime reconciliation.

These items are reconciliation work in progress. They are not represented as production complete.

Section 12

v0.2.1 execution-slot amendments — verified

Migration 20260731222546 (ksp_v02_execution_slot).
queued state added.
Broken per-status uniqueness removed.
Fail-closed execution-slot index in place.
Service-role acquisition of the execution slot.
Atomic confirmation + queuing + acquisition + Temporal-start outbox.
Proof-gated mission completion.
Terminal disposition stored separately while status ends at complete.
Verified concurrency behaviour: only one mission acquires the slot; the slot releases after proof-gated complete; the next queued mission can then acquire it; empty reset or shutdown proof is rejected.

End of document

Knight Shield Protocol v0.2 — working draft. Not locked. Source of truth: KSD Notion canon.

← Back to Pentagon