Technical architecture

A governed pipeline with explicit authority, evidence and execution boundaries.

The published design specifies a canonical S0–S8 governance pipeline with explicit inputs, outputs, denials and evidence requirements. S0 verifies identity from an external provider. Retrieval cannot enlarge governance eligibility; validation does not itself create execution authority.

S0–S8 pipeline

S0
Identity and request ingress
Verify external identity assertions and normalize the governed request or deny. TenantSage does not replace the identity provider.
S1
Deterministic Authority Resolution
Resolve explicit customer binding, active scope, role and assignments into AuthoritySnapshot.
S2
Governance decision
Apply deny-precedence policy and produce GovernanceContext.
S3
Sealed Eligible Evidence Boundary
Materialize the maximum evidence universe and seal it with eebHash.
S4
Governed retrieval
Rank or reduce evidence only inside the sealed EEB and persist retrieval proof.
S5
Governed context
Assemble context only from completed governed retrieval.
S6
Generation
Generate from governed context only; no independent retrieval.
S7
Validation + ValidationApproval
Validate candidate material and issue explicit approval when execution is permitted.
S8
Approval-bound execution
Persist ExecutionIntent, execute exact approved material, verify, persist completion proof, close ExecutionReceipt, replay proof, then release success.

Critical invariants

S4 cannot recompute visibility. Retrieval may rank or reduce evidence only within the sealed EEB.

S6 cannot retrieve additional evidence. Generation is downstream of governed context.

ValidatedAction is not execution authority. ValidationApproval is the sole S8 execution authority.

Proof precedes release. No durable completion proof means no successful execution claim; no final execution proof means no successful response release.

Deep dives

Deterministic Authority Resolution (DAR)
GovernanceContext and deny precedence
Temporal freshness and state hashes
Eligible Evidence Boundary construction
Source-level chunk inheritance
Retrieval subset contract
Durable retrieval and execution receipts
Replay requirements
Database enforcement with RLS, FORCE RLS and non-owner runtime roles

Security model

Fail closed, including privileged paths.

Failures return typed denials or failure artifacts rather than partially trusted downstream state. Negative evidence must cover application, administrative, debug, cache, export, batch, agent-tool and owner-level bypass paths.

Conformance evidence

  • Threat model and canonical schemas
  • Canonicalization and deterministic hashing vectors
  • Negative and bypass tests
  • Receipt-state and replay tests
  • S7/S8 approval-binding and exact-material tests
  • Performance measurements bound to tested builds

Scope of claims

TenantSage is a governance architecture and conformance program. Security, performance and implementation claims are limited to the code, configuration, commit, deployment environment and evidence against which they were tested. The published design is not proof that the full pipeline has been implemented. S6–S8 assurance and independent review remain separate evidence milestones. This page does not claim certification or independent audit.