From 7e0d252671c82459aa872303555bb3b87ec3c43a Mon Sep 17 00:00:00 2001 From: Ricky Jones Date: Wed, 4 Mar 2026 23:40:56 +0000 Subject: [PATCH 1/2] docs: add MOSA adapter boundary note (interface-only) This document outlines the MOSA Adapter Boundary, detailing integration points, inputs, outputs, and architecture position for the Autonomy Governance & Control Kit. --- docs/reference/mosa_adapter_boundary.md | 84 +++++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 docs/reference/mosa_adapter_boundary.md diff --git a/docs/reference/mosa_adapter_boundary.md b/docs/reference/mosa_adapter_boundary.md new file mode 100644 index 0000000..d802f1a --- /dev/null +++ b/docs/reference/mosa_adapter_boundary.md @@ -0,0 +1,84 @@ +# MOSA Adapter Boundary Note + +**Version:** 0.1 +**Status:** DRAFT +**Normativity:** INFORMATIVE +**Scope:** Interface-only boundary description — no implementation details. + +## Purpose + +This document describes the integration points where the Autonomy Governance & Control Kit interfaces with GFI (Government Furnished Information) ICD/API patterns via MOSA (Modular Open Systems Approach) adapters. It covers inputs, outputs, and the position of the admissibility gate in the call chain. + +No implementation details, internal algorithms, or proprietary wiring are included. + +## Architecture Position + +The governance kit operates as a **wrapper/augmenter** around existing autonomy stacks. It does not replace platform autonomy software but interposes at defined boundary points to enforce admissibility decisions before high-impact actions execute. + +``` +[Platform Autonomy Stack] + | + v +[MOSA Adapter Interface] + | + v +[Admissibility Gate] <-- fail-closed: ALLOW / REFUSE + | + v +[Receipt Emitter] --> audit log + crypto posture receipt + | + v +[Platform Execution / Command Bus] +``` + +## Inputs (from GFI ICD/API patterns) + +The adapter receives the following from upstream platform systems: + +| Input | Description | +|---|---| +| Command intents | Structured action requests from mission planning or operator consoles | +| Mission plans | Waypoints, objectives, rules of engagement references | +| Crypto configuration | Algorithm suite selections, key rotation schedules | +| Key/rotation metadata | Key origin, lifecycle epoch, HSM/KMS identifiers | +| Policy hashes | SHA-256 hashes of governing policy documents at decision time | +| Authority chain | Delegation chain from ground authority through operational levels | + +## Outputs (from the governance kit) + +The adapter produces the following at its boundary: + +| Output | Description | +|---|---| +| Admissibility decision | `ALLOW`, `REFUSE`, or `ESCALATE` with deterministic verdict | +| Reason codes | Single primary enumerated reason code per decision (no free-text) | +| Decision receipt | `commit_decision_.json` — canonical, replayable CI artifact | +| Crypto posture receipt | Optional `crypto_posture` section within receipt (see PQC schema) | +| Authority graph | `authority_graph_.json` — supporting evidence (not primary) | +| Audit log entries | Structured log records for platform-level audit trail integration | + +## Integration Points + +### 1. Admissibility Gate Position + +The gate sits **between** the platform command pipeline and execution. All high-impact actions pass through the gate before reaching the command bus. The gate is fail-closed: if evaluation cannot complete or encounters unknown inputs, the default verdict is `REFUSE`. + +### 2. Receipt Emission Point + +Receipts are emitted **after** each admissibility decision. They are written to the local audit store and can be forwarded to platform logging infrastructure. Receipt format follows the canonical decision schema (RFC 8785 JCS when canonicalization is selected). + +### 3. Mapping to Platform Logs + +Receipt `decision_hash` and `request_hash` fields provide deterministic identifiers that platform logging systems can cross-reference. The adapter does not modify platform log formats — it emits its own receipts alongside existing log streams. + +### 4. Delegation and Revocation Interface + +The adapter accepts delegation/revocation signals from the authority chain. These modify the active authority scope for subsequent decisions. Revocation is immediate and auditable. + +## Constraints + +- This document describes **boundary-level interfaces only** +- No internal algorithms, proprietary protocols, or configuration grammars are included +- The adapter is platform-agnostic and hull-vendor independent +- All integration points are described at the input/output level +- No specific GFI ICD version is assumed — adapter pattern is generic From f8606a7d735bfeadcdc4bffae32f2d3cc2c3d240 Mon Sep 17 00:00:00 2001 From: Ricky Jones Date: Wed, 4 Mar 2026 23:50:56 +0000 Subject: [PATCH 2/2] docs: add interface-only constraint per Trinity review Clarify that the adapter defines interface structures without implementing policy evaluation or decision logic. --- docs/reference/mosa_adapter_boundary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/reference/mosa_adapter_boundary.md b/docs/reference/mosa_adapter_boundary.md index d802f1a..68e362e 100644 --- a/docs/reference/mosa_adapter_boundary.md +++ b/docs/reference/mosa_adapter_boundary.md @@ -82,3 +82,4 @@ The adapter accepts delegation/revocation signals from the authority chain. Thes - The adapter is platform-agnostic and hull-vendor independent - All integration points are described at the input/output level - No specific GFI ICD version is assumed — adapter pattern is generic +- This adapter defines interface structures only and does not implement policy evaluation or decision logic