Intelligence is not authority.
GAIX-SIW-DGAF-REQ-001 · Draft — architectural integration & conformance requirements · Companion / non-superseding
The Companion does not decide anything. It specifies what must be true before SIW R3 can.
SIW R3 is the fixed authority kernel and reference proof baseline. The Companion — working title SIW Distributed Governed-Action Fabric — is a deployment, integration and conformance specification for applying that kernel across Frontier Labs, enterprise, developer, and distributed/federated environments. It grants no implementation authority by itself.
R3 vs. Companion
Two different questions, deliberately kept apart.
R3 answers what a governed authority decision means. The Companion answers a separate question: what must the surrounding distributed system establish so that R3 can safely evaluate a consequence at the receiving boundary?
Positioning chain
1
SIW R3
Fixed authority kernel · proof / reference baseline
AuthoritativeFixed authority kernel · proof / reference baseline
2
Companion
Distributed deployment / conformance requirements
This documentDistributed deployment / conformance requirements
3
Gateway / SDK / adapters
Implementation tooling, recognition contracts
ToolingImplementation tooling, recognition contracts
4
Build 17
Evaluation · inspection · evidence · comparison · proof/export
Product surfaceEvaluation · inspection · evidence · comparison · proof/export
5
Interop Lab
Independent comparative validation
External reviewIndependent comparative validation
The Companion is not a mandate to expand R3 until it becomes the entire distributed enterprise system.
R3 remains authoritative for its accepted semantics. The Companion specifies what the surrounding system must establish so R3 can evaluate authority safely — it does not become a second authority kernel.
R3 principles the Companion preserves
Nothing here is reopened.
Any future implementation conflict between the Companion and an accepted R3 invariant is resolved in favor of the accepted R3 invariant unless an explicit later ratification changes it.
Proposal is not authorization.
Possession is not standing.
Federation is not standing.
Admission is not activation.
Evidence is not authority.
A previously valid authorization is not necessarily a currently valid one.
The receiving jurisdiction retains sovereignty over what it will bind.
Responsibility planes, not a permission stack
Six planning planes. Authority does not automatically inherit between them.
Core, Fabric, Edge, Autonomous, Trust and Physical are separable responsibility planes. Fabric may transport. Edge may adapt. Federation may carry assertions. Recognition may make a remote assertion admissible. None of those, by itself, creates final consequence authority — the receiving Core remains responsible for determining whether the authority presented to it is admissible, current, applicable and sufficient at the actual consequence boundary.
SIW Core
Identity, standing, admission, activation, authorization, revocation, bind-time verification. R3 lives here.
SIW Fabric
Governed transport, federation, propagation. Not an authority source.
SIW Edge
Application/developer adapters; where existing Genesis components connect (below).
SIW Autonomous
Bounded delegated authority for remote/disconnected actors.
SIW Trust
Future cryptographic hardening (Veritas). Not required for initial deployment.
SIW Physical
Future physical/network route enforcement (Photonic Gateway). Not required for initial deployment.
Planning labels, not commercial names.
"Core / Fabric / Edge / Autonomous / Trust / Physical" are responsibility-plane and planning labels in the source specification. They do not automatically become final product names.
The distributed authority problem
A remote assertion does not create local standing merely because it is trustworthy.
Authentication can establish origin. A valid signature can establish integrity. A trusted transport can establish that federation occurred. Schema compatibility can establish intelligibility. None of those, individually or together, creates local authority.
What establishes admissibility
A receiving authority domain may rely on a remote assertion only where a current, locally authorized recognition rule applies to the relevant actor, action, target, scope and domain. Recognition is itself governed state — it has its own identity, revision, validity and revocation status.
What recognition does not do
Recognition makes a remote assertion an admissible basis for local evaluation. Recognition does not itself constitute BIND. Where no applicable recognition rule can be established, the expected outcome is HOLD or NO BIND, as local policy requires.
Technical register
For evaluators inspecting the formal requirements.
This page is positioning copy. The Companion document is the authoritative, detailed specification; the identifiers below are exact requirement anchors, not paraphrases.
Remote Authority Recognition
A remote assertion does not create local standing merely because origin, signature, integrity, transport, schema or freshness check out.
Recognition Determinacy
Where more than one recognition rule could apply, admissibility must resolve unambiguously, or HOLD.
Authoritative Currentness
Last-known is not current. Every load-bearing mutable fact needs an authoritative currentness basis, or HOLD.
Authority Cardinality Domain
Limited-use authority needs an explicit permitted cardinality and consumption domain. Unknown/partial consumption never restores capacity.
Explicit Consequence Set
A determination must identify exactly what consequence or consequence set it authorizes. Partial effect does not authorize the remainder.
Resolved-Object Binding
Name equality is not consequence-object identity. The presented target, the resolved object and the resolution basis must be bound together.
Post-Transformation Authority
Any authority-relevant transformation — actor, action, target, parameter, scope, meaning — creates a new determination requirement.
Test-validity prerequisite.
Before a negative HOLD / NO-BIND suite (DR-01 through DR-08) counts as evidence, the same observation surface must first demonstrate a positive control in which an intentionally permitted synthetic consequence attaches and is observable. A suite that only shows refusal does not by itself show the boundary is working.
Content admissibility register (§9.4)
Controlled Ingress and Quarantine
External artifacts enter a controlled staging/quarantine boundary before parsing, interpretation, repository admission, execution or downstream tool use. Original bytes and content identity are preserved for provenance.
Malware / Structural Inspection
Malware, structural, active-content and artifact-consistency inspection. Inspection failure or incompleteness never silently becomes PASS.
Instruction-Integrity Inspection
Instruction-like or manipulation content is examined. Instructions inside documents, pages, source, comments, logs, fixtures or tool output do not acquire authority merely because the model can read them.
Admissibility Disposition
PASS · HOLD_QUARANTINED · REJECT_QUARANTINED. Scanner failure, stale definitions, unsupported/encrypted or incomplete inspection resolve to HOLD_QUARANTINED unless policy requires REJECT.
Content Provenance and Inspection Evidence
An auditable ingress record — source, content identity, scanner/rule state, findings, disposition. Instruction authority defaults to NONE / NOT ESTABLISHED unless separately established.
SIW Edge · existing Genesis components
Existing products participate as adapters, not as second authority sources.
LifeStack™
Contextual / application-semantic provider — relationships, consent state, domain policy, lifecycle state. Context relevant to authority is not authority by itself unless admitted by applicable SIW policy.
SeSAA™
Assurance and inspection service — semantic, security and risk findings. A SeSAA finding is not authorization. It may become evidence within an SIW determination; it does not acquire binding authority on its own.
Prompt Protection™
Instruction and candidate-formation integrity — provenance, manipulation detection, tool/instruction separation. A protected prompt is not an authorized consequence.
Content Admissibility Boundary
Untrusted-content ingress / quarantine (§9.4) — composes SeSAA (malware/structural/risk evidence) and Prompt Protection (instruction-integrity evidence) into an explicit PASS / HOLD_QUARANTINED / REJECT_QUARANTINED disposition. Content may be available to the system without being admissible to the agent. ClamAV/YARA are reference implementation candidates, not mandatory dependencies.
Frontier Labs
Not a request to rebuild the Genesis ecosystem.
Frontier Labs is a natural deployment/evaluation context for distributed SIW: model services, inference infrastructure, tool routers, sandboxes, evaluation harnesses, external APIs, cloud systems, agents, and multiple authority domains all produce real effect-capable routes worth governing narrowly and well.
1
Identify effect-capable routes
One or several real routes, named specifically.
2
Map authority / consequence boundaries
3
Assess against Companion requirements
4
Determine Core / Gateway / adapter placement
5
Implement one bounded consequence path
6
Run positive and negative adversarial controls
7
Produce inspectable evidence
8
Expand only if the bounded pilot succeeds
SIW is not positioned as an alignment replacement.
Even where model or harness behavior is unexpected, external consequence remains independently governable — that is the bounded claim.
Content Admissibility Challenge (§12.1)
Claim: visible content does not become authorized instruction merely because it is inspectable by the model.
1
Claim
2
Specification
3
Fixture
4
Positive control
5
Negative control
6
Execution
7
Evidence
8
Independent review
Representative fixtures: clean benign file · harmless malware-test artifact (EICAR-class) · prompt-injection document · malformed content · encrypted/inspection-incomplete content · scanner unavailable · stale-definition condition. A positive control proving a clean artifact can actually reach PASS through the same observation surface is required before any HOLD_QUARANTINED / REJECT_QUARANTINED result is accepted as evidence.
Security Coexistence Challenge (§12.2)
Tests whether Genesis content quarantine/scanning can coexist with representative EDR/DLP/AV/SIEM controls without either system mistaking the other for unauthorized behavior, destructive interference with quarantined evidence, creating a security blind spot, bypassing existing enterprise controls, or losing independent observability. This scenario spans both Frontier Labs (controlled proof) and Enterprise (below, deployment requirement).
Conformance is not claimed until scenario evidence actually exists.
Neither §12.1 nor §12.2 is presented as already demonstrated; both remain scenario specifications pending execution.
Enterprise
Use what you already have. Don't let it become an accidental authority source.
Companion deployment is designed to use existing enterprise systems — IAM, RBAC, ABAC, directories, policy engines, API gateways, workflow systems, audit/security infrastructure, data classification, organizational context — rather than replace them.
What these systems may supply
Identity, evidence, context, authority-source information, currentness information, target-resolution information.
What they do not automatically do
Enterprise system output does not automatically become R3 authority. The Companion defines how these inputs participate safely in a consequence decision — an AI does not obtain authority merely because it possesses a credential or can reach an enterprise API.
A typical deployment should begin with one, or a small number of, consequential routes rather than modeling an entire enterprise at once.
Genesis security coexistence (§11.1)
Genesis security behavior — including the Content Admissibility Boundary (§9.4) — may itself be observed by enterprise security controls. The architecture favors local/on-prem scanning, a persistent scanner service rather than repeated process spawning, local/private IPC, no execution of inspected content, least-privilege/read-only source access, a controlled quarantine write boundary, signed/versioned components, stable service identities where deployment permits, no silent outbound artifact upload, enterprise-controlled or internally mirrored signature/rule updates, and SIEM/EDR/DLP event integration.
An explicit coexistence policy prevents Genesis quarantine from becoming a monitoring blind spot.
Enterprise security preflight: scanner service recognized · quarantine-path policy established · EDR behavior tested · DLP behavior tested · local IPC approved · scanner/signature update path approved · artifact egress boundary confirmed · SIEM/event destination confirmed · controlled HOLD/REJECT fixture tested · no unintended endpoint-security interference.
Enterprise owns the deployment requirement. Frontier Labs owns the controlled proof scenario (above).
Developers
One question. Three possible answers.
A developer should not need to understand the entire Genesis ecosystem to govern one consequence.
May this actor perform this action against this target, right now?
→ BIND · → HOLD · → NO BIND — plus supporting evidence.
Conceptual, non-binding
Candidate Gateway/SDK verbs
Exact API names are not fixed by the specification.
authorize(candidate)
inspect(candidate)
bind(candidate)
receipt(candidate_id)
revoke(authority_reference)
standing(actor, context)
status(candidate_id)
Two roadmaps — kept separate on purpose
Buying an engagement does not advance the architecture roadmap.
These are two different axes. One is how the Companion architecture itself matures. The other is how a customer engagement proceeds against whatever already exists. They are not the same sequence, and progress on one does not imply progress on the other.
A · Architecture / implementation roadmap
The Companion's own phased technical progression.
Freeze / adversarial review
Incorporate external-review findings; freeze normative requirements.
Local reference implementation
One authority domain, one R3 Core, one Gateway/Edge seam, one synthetic target.
Two-node distributed SIW
Fabric plus a receiving authority domain.
Enterprise integration
Real enterprise-shaped infrastructure via adapters.
Interop Lab validation
Independent review of bounded claims.
External pilots
A small number of consequence paths in partner environments.
Autonomous / disconnected authority
Bounded delegation, intermittent connectivity.
Veritas hardening
Cryptographic hardening of assertions and evidence.
Photonic / physical enforcement
Physical/network route enforcement, where justified.
B · Genesis AiX engagement roadmap
How a paid engagement proceeds against what already exists today.
1
Consequence Path Discovery
2
Authority Mapping
3
Companion Gap Assessment
4
SIW Integration Design
5
Reference Implementation / Pilot
6
Adversarial Validation
7
Evidence Package / Independent Review
Genesis AiX engagement model
Not "buy consulting." Not "replace your infrastructure."
Identify a consequential AI route, establish its authority boundaries, integrate SIW against that route, implement the necessary Companion contracts, and demonstrate with evidence what can and cannot bind.
That is the value proposition. Technical credibility leads; this may become a paid engagement model, but the specification itself stays technical and vendor-neutral enough to be evaluated independently of any commercial terms.
Interop Lab
A different role from Frontier Labs.
Frontier Labs is a deployment/evaluation context for frontier-model organizations governing their own routes. The Interop Lab is an independent comparative proof environment across architectures — it does not deploy the Companion for a customer, and it compares independently developed authority architectures against the same frozen consequence problem.
1
Claim
2
Specification
3
Fixture
4
Positive control
5
Negative control
6
Execution
7
Evidence
8
Independent review
Future / deferred
Not shipping. Not claimed as shipping.
Full distributed Fabric
Beyond the local reference implementation.
Positive remote-authority-source integration
Live recognition against a real remote authority source.
SIW Autonomous / Sopranus
Bounded delegated authority for disconnected actors.
Veritas
Cryptographic hardening of assertions and evidence.
Photonic Gateway
Physical/network route enforcement.
Broad production rollout
Not authorized or implied by this page.
Evaluation / authority boundary
What this page does not grant.
The Companion is a deployment, integration and conformance specification. It does not itself grant implementation authority, production rights, standing, admission, activation or authorization.
Intelligence is not authority. Transport is not standing. Recognition is not authority inheritance.
Full specification: GAIX-SIW-DGAF-REQ-001, status DRAFT — ARCHITECTURAL INTEGRATION & CONFORMANCE REQUIREMENTS, relationship to SIW R3 COMPANION / NON-SUPERSEDING. Related: R3 architecture overview · Governance · Governance lineage · Interop Lab · Developers · Evaluation terms · Licensing.