AUTHORITY BEFORE ACTION SOVEREIGN MISSION INTELLIGENCE AND AUTHORIZED ACTION DENY by default EVIDENCE before effect
Tunnel Sovereign symbolVERITY COMMAND
Public Technical Note

Trust, Authority and Evidence Architecture

How Verity Command establishes who may act, on what basis and within which boundary — and what it does when that basis cannot be established.

Document
VC-PUB-001
Version
1.1
Published
16 September 2026
Edition
Public
PDF
Download (616 KB)
PDF SHA-256
d601b28861a41dea74ec8a72ee36db706831cbe3b7f690fb3b75f32b58650bd7
PUBLIC EDITION

1About this note

This note describes the trust, authority and evidence architecture of Verity Command, the sovereign mission intelligence and authorized action platform of Sovereign Inc. It is a public edition: it explains the architecture and its reasoning and omits implementation detail, configuration values and deployment-specific bounds.

It describes how the architecture behaves by definition. It is not a report of operational use, measured performance or independent assessment. Section 12 lists what the note does not claim; the Public Threat Model (VC-PUB-002) sets out what the architecture protects, detects and cannot guarantee, and the Hormuz Reference Scenario (VC-PUB-003) walks through it with synthetic data.

Verity Command does not make intelligence inherently true. It makes the basis, authority and consequences of acting on intelligence inspectable and enforceable.

2Platform and chain

Verity Command governs how intelligence becomes authorized, distributed, executed and evidenced action. Every capability belongs to one stage of a single chain — observe, understand, simulate, recommend, authorize or refuse, distribute, enforce, execute, evidence — and the component that recommends never authorizes, while the component that authorizes never executes.

ModuleRole
Reality FabricGoverned ingestion; provenance, label and lineage fixed at entry
Reality GraphTemporal and geospatial model of entities, events and decisions, with typed statements
AtlasCommon operational picture; entity and evidence inspection; digest-bound approval
IntelligenceEvidence-linked analysis; governed AI with classification-aware model routing
SimulationCourse-of-action comparison under recorded assumptions; never an observation
Authority KernelThe single policy decision point; deny precedence; fail closed
Evidence LedgerSigned, hash-chained records admitted before effect
Tunnel SovereignSecure mission distribution bound to authority envelopes
QECNet Trust FabricIdentity, key lifecycle, policy, revocation and signing on customer-held roots
Verity EdgeLocal enforcement of envelope, scope, lease, time and revocation
Verity ForgeSigned releases; configuration and policy as data; sovereign rollout
SDK and Integration FrameworkThe controlled integration surface; integrations are principals

Deliberate non-goals: autonomous selection or engagement of targets and any weapon-control function; replacement of formally approved force-level command-and-control systems; new cryptographic primitives or proprietary encryption; data brokerage; and mass surveillance. Biometric processing is excluded unless a customer's documented legal authority and a separate product decision exist.

3Trust boundaries

A deployment is one authority domain: one set of roots of trust and one evidence namespace. Instances interact by federation, never through shared internals. Thirteen boundaries are defined inside the domain; each names the controls a crossing must satisfy and the behavior when they cannot be satisfied.

Trust boundaries of a Verity Command deployment The customer authority domain sits at the centre, containing the platform services, the Authority Kernel and the Evidence Ledger. Boundaries cross to external networks and user devices on the left, to data providers and model providers at the top, to Tunnel Sovereign, the Distribution Endpoint and the Tunnel relay on the right, and to edge nodes, air-gapped media and coalition partners at the bottom. Each crossing is labelled with its boundary identifier. CUSTOMER AUTHORITY DOMAIN Authority Kernel single decision point Reality Graph typed records Evidence Ledger append-only Platform services — each embedding a thin enforcement point Roots of trust held by the customer · QECNet Trust Fabric External network TB-01 User device TB-02 Data providers TB-06 Model providers TB-07 Build pipeline TB-12 Tunnel Sovereign TB-04 Tunnel relay ciphertext only TB-05 Coalition partner TB-08 Verity Edge TB-09 Air gap — media TB-10 Vendor support TB-11
Figure 1 Trust boundaries. Every labeled crossing has its own controls and its own defined behavior on failure. Service-to-service calls and the processing sandbox are internal to the domain.
BoundaryCrossing controlsOn failure
TB-01External network to gateway: strong client authentication, policy decision, rate limits, input validationFail closed
TB-02User device: device-bound session, phishing-resistant authentication, posture checksSession refused
TB-03Service to service: workload identity, mutual authentication, per-call decisionsCall denied
TB-04Platform to Tunnel Sovereign control: signed requests, verification of authority envelopesDistribution refused
TB-05Distribution Endpoint to relay: end-to-end encryption to recipientsNo content exposure
TB-06Data provider to Reality Fabric: source authentication, schema validation, scanning, labelingQuarantine
TB-07Intelligence to model endpoint: classification-aware routing, egress allowlistRequest denied
TB-08Graph to coalition partner: release decision, projection, label binding, acceptanceWithhold
TB-09Authority domain to Verity Edge: signed authority state and leases, conflict preservationLease, then fail closed
TB-10Air gap: signature, provenance and malware checks, import authorizationImport refused
TB-11Vendor to customer environment: no standing access; approved, time-bound, evidencedNo access
TB-12Build pipeline to release: signed builds, bill of materials, attestation, customer approvalDeployment blocked
TB-13Processing sandbox: restricted profile, no default egress, resource limitsSandbox terminated

Across every boundary: no component outside a Tunnel Sovereign endpoint holds payload keys; content not releasable to a recipient never crosses a distribution, model, federation or export boundary; the vendor holds no key that can authorize, decrypt or sign inside a sovereign customer domain; every crossing produces a decision record; and untrusted content never becomes instruction.

4Principals and authority

A principal is any actor that can be authenticated and authorized. People, services, AI agents, devices, sensors, guests and partner domains are distinct principal types with distinct trust anchors in QECNet Trust Fabric. The customer's identity provider remains authoritative for whether a person exists; deactivation there propagates as revocation, and AI agents delegating from that person lose their permissions with them.

ElementDefinition
GrantSigned conferral of named capabilities within scope, direction and validity window
ScopeMission, compartment, geography, object set, label ceiling, purpose
DirectionSource to destination; the reverse leg requires its own grant
DelegationA subset of one's own capabilities, never a superset
QuorumNumber and composition of approvers, set by policy for the action class
ApprovalSigned human consent bound to an exact content digest
EpochMonotonic version of an authority domain; a grant below the floor is refused

The mission named in an authorization is always the mission of the authorizing grant, never one supplied by the caller; a request naming a different mission is refused. Mission identities use key material that differs per mission, which does not make mission activity unlinkable: connection identity, timing and volume remain observable to infrastructure.

5The Authority Kernel

There is one policy decision point. No service implements its own authorization; each embeds a thin enforcement point that obtains a decision and applies it. Policy is data — signed, versioned and testable — and the policy engine is a dependency of the Kernel rather than the Kernel itself.

The authority decision path A request arrives at an enforcement point. Context is assembled, then preconditions are checked. Four precondition failures lead directly to denial: unknown identity, unavailable policy, time uncertainty beyond bound, and unavailable evidence. If preconditions hold, policy models are evaluated and combined with deny precedence, producing denial, permission, or a requirement for human approval. Approval returns to evaluation. Every outcome writes to the evidence ledger before the enforcement point acts. Request at an enforcement point Assemble context principal · device · mission labels · purpose · digest · time Pre- conditions DENY no_identity DENY policy_unavailable DENY time_uncertainty_exceeded DENY evidence_unavailable Evaluate policy role ∧ attribute ∧ relationship ∧ capability ∧ classification ∧ releasability ∧ epoch ok Deny precedence DENY with reasons REQUIRE_APPROVAL PERMIT with obligations Signed authorization bound to the content digest Evidence every path writes here
Figure 2 The authority decision path. Four precondition failures produce a denial before any policy is evaluated. Unavailable evidence is one of them: if a decision cannot be recorded, it is not made.

Deny precedence. A decision is permit only if every model permits and no explicit deny matches, so evaluation order cannot change the result. An unrecognized label, category or policy identifier is treated as maximally restrictive.

Fail closed. When identity, policy, evidence, time or cryptographic validation cannot be established, the request is refused and the refusal evidenced. The cost is stated: the Kernel is a single point of denial, and an outage of the decision path stops action rather than permitting it.

Refusal with reasons. A refusal names every unmet condition and the policy version evaluated, so the requester knows what would have to change and a reviewer can reproduce the decision later.

StageWhoMust not
RecommendationIntelligence, Simulation, analysts, AI agentsAuthorize; execute
DecisionAccountable human commanderBe delegated to an AI agent
AuthorizationAuthority Kernel with approval and quorumExecute
ExecutionOne execution path behind Verity EdgeAct without a verified envelope

A permit produces a signed authority envelope carrying the content digest, mission, principal, scope, direction, validity window and policy version. It is the only object Tunnel Sovereign distributes and the only object Verity Edge accepts, and it cannot be widened or extended by its holder.

6Evidence before effect

Evidence for a material act is admitted before the act's external effect is committed. If the record cannot be admitted, the action does not proceed.

Evidence admitted before external effect An authorized action first writes an evidence record, which is validated, labelled and chained to its predecessor. Only after admission succeeds does the execution path commit the external effect. If admission fails, the action is blocked and that block is itself recorded. Authorized action Evidence admission schema validation label computation hash-chained to predecessor admitted External effect committed not admitted → action blocked Ledger properties append-only no update or delete API signed checkpoints external anchoring
Figure 3 Evidence before effect. The blocked path is not an error to be engineered away; it is the defined behavior when the record of an action cannot be made.

The Evidence Ledger is append-only and tamper-evident. It is not a blockchain: records are hash-chained, periodic checkpoints are signed, and checkpoints can be exported to write-once storage or exchanged with a federation partner so that neither party can rewrite shared history alone. There is no update or delete interface; retention expiry and legal hold are the only removal paths, and both are evidenced. Continuous verification raises a critical incident and freezes writes on any break.

What evidence is not. A complete, verifiable record does not prove that the recorded facts were true, or that a person acted in good faith. It proves what was asserted, by whom, on what basis and when.

7Time, leases and revocation

Trusted time. Authority is time-bounded, so time sources are a trust boundary. Every record carries its time uncertainty, and unknown uncertainty is recorded as unknown, never as zero. Within bound, leases use the conservative end of the interval; beyond bound, authority decisions fail closed while data collection continues; a detected clock rollback is refused and monotonic counters are relied upon. Specific bounds are deployment configuration.

Leases. A Verity Edge node that loses connectivity continues within a signed lease — capabilities, scope, epoch floors, validity window and policy version — and records its decisions as offline decisions.

Limit while disconnectedReason
No new grantsAuthority originates with the issuer, not the holder
No quorum with absent approversAn approval that cannot be given cannot be assumed
No lease extension or policy changeA disconnected endpoint cannot grant itself authority
Fail closed at expiryProlonged isolation ends in loss of capability

Reconnection applies authority state first — revocations, epochs, policy — and then re-authorizes queued work item by item. Work whose grant was withdrawn is not released; offline evidence is appended with its local sequence and uncertainty; data conflicts are preserved as contradictions.

Revocation takes effect at an enforcement point when that point receives the signed revocation state, and in every case no later than the expiry of the grant or lease. Connected points honor it promptly. A disconnected point cannot be reached, so its residual authority is bounded by its lease, and the maximum residual window is shown to the commander at the moment of revocation. Revocation is never described as instantaneous everywhere.

8Provenance in the Reality Graph

The Reality Graph records what kind of statement each belief is. The type is assigned at creation and cannot change.

TypeQuestion it answersWritten by AI
ObservationWhat did a sensor, system or person directly detect?No
Source claimWhat does a source state, without having observed it?No
Machine extractionWhat does this content say, as parsed?Yes
InferenceWhat follows from these records, by this method?Yes
AssessmentWhat does an accountable person judge this to mean?Drafts only
PredictionWhat may happen, under these assumptions?Yes

Fact is not a type: a statement can be treated as established for a purpose when it meets a corroboration policy, and that treatment is itself a revisable assessment. An inference without inputs is refused at the write path; generated language never promotes a type; confidence is never shown without its method; absence of evidence is shown as absence; contradictions are preserved; and five reports derived from one original are one source, which the lineage shows. Synthetic and exercise data are flagged at creation and can never become observations.

9Distribution and enforcement

Authorized instructions have to travel and must be checked again where they take effect. The division is strict: the Authority Kernel authorizes; Tunnel Sovereign delivers; authorized endpoints read; Verity Edge enforces.

The distribution boundary An authorized package passes from the platform to the Distribution Endpoint, which is an enrolled endpoint holding only its own key material. It encrypts end to end to the recipient endpoints. The relay carries ciphertext and metadata only and cannot read content. Recipient endpoints are the only place where payload keys exist and where plaintext is available. Authorized package bound to a digest Distribution Endpoint an enrolled endpoint, accountable principal holds only its own keys ciphertext Relay ciphertext and metadata only Recipient endpoints the only place where payload keys exist and plaintext is read Relay cannot read content — structurally Residual risk, disclosed: compromise exposes what it distributes
Figure 4 The distribution boundary. The platform cannot encrypt to recipients without being an endpoint, and no central component may hold recipients' keys. The Distribution Endpoint resolves that tension explicitly.

The Distribution Endpoint acts only on a verified envelope, holds plaintext transiently, and runs in a restricted profile without access to the graph, Kernel internals or other evidence. Its residual risk is disclosed: a compromise would expose the packages it is distributing at that time. Mitigations are minimal retention, isolation, separate enrollment, quorum for bulk distribution and volume anomaly detection.

Verity Edge validates the envelope signature and digest, mission scope, its lease, trusted time and local revocation state before releasing an instruction to an operational system, and records acceptance before release and the system's result after it.

Federation is an exchange between two authority domains that each keep their own roots: a release decision by the originating domain and an acceptance by the receiving one. Caveats cannot be stripped, withdrawal is honored, and derived records carry labels at least as restrictive as their most restrictive input unless a downgrade decision is recorded. QECNet Trust Fabric enrolls every endpoint and signs every envelope and record; Verity Forge delivers releases, configuration and policy under the same approval and evidence rules.

10Failure behavior

ConditionBehaviorWhat remains
Identity cannot be establishedDeny; evidence the denialNothing that needs a principal
Policy unavailableDenyNo extension of existing reads
Evidence cannot be admittedDeny; action does not proceedCollection, marked with its state
Time uncertainty beyond boundAuthority fails closedCollection with recorded uncertainty
Distribution unavailableRefuse; hold as pending authorityDecision-making; nothing sent silently later
Edge connectivity lostEnforce within lease; fail closed at expiryLease-scoped capabilities, then nothing
Model route denied or unavailableDeny rather than rerouteNon-AI analysis
Evidence chain verification failsCritical incident; freeze writesRead access to verified history

11Security invariants

Security properties are written as invariants that hold in every posture, including during failure, and are release preconditions. A representative selection:

  • No request is processed without an authenticated principal verified at the enforcement point.
  • Every access and action results from an Authority Kernel decision, with deny precedence.
  • An AI agent's effective permissions never exceed the intersection of its grant, its delegator's current authority and the mission; no AI agent performs, approves or triggers a high-consequence action.
  • Approvals and authorizations are valid only for the exact content digest they bound.
  • Leases and validity windows can be renewed only by the issuing authority.
  • External and retrieved content is treated as data, never as instruction.
Deliberately not an invariantWhy
Revocation reaches every endpoint at onceFalse for disconnected endpoints; the lease is the bound
The relay learns nothingConnection metadata, timing and volume are observable
A captured unlocked device is protectedIt is not; mitigations reduce scope only
AI cannot produce a wrong answerGovernance constrains use, not correctness

12What this note does not claim

  • No certification, accreditation, authorization to operate or approval for classified information.
  • No compliance with, or assessment against, any control catalogue, standard, or national or alliance interoperability requirement.
  • No independent assessment, audit, penetration test or cryptographic review.
  • No measured performance, scale, availability or AI accuracy figure.
  • No customer, deployment, endorsement or past performance.
  • No comparative superiority over any other system.

An architecture note that cannot state its limits is not an architecture note. It is an advertisement.

13Related documents and revisions

VersionDateChange
1.02026-09-16First public edition.
1.12026-09-16Aligned to the canonical platform architecture of twelve modules; condensed; related documents linked.

Document VC-PUB-001 · Version 1.1 · Published 16 September 2026 · PUBLIC EDITION
© 2026 Sovereign Inc. All rights reserved.