Power without attribution is illegitimate.
In modern systems, authority often dissolves into "black box" complexity, creating a failure mode where actions occur but no accountable actor can be identified. The TAS/SDF framework resolves this by enforcing a structural requirement:
No action may execute without a verified source, scope, and lineage.
The TAS machine is the technical mechanization of long-established legal principles:
- Ubi jus ibi remedium: Where there is a right, there must be a remedy. A system that obscures the actor removes the remedy and voids the right.
- Actori incumbit onus probandi: The burden of proof lies on the claimant. TAS automates this by generating immutable receipts of every authorized or refused action.
- Qui facit per alium facit per se: He who acts through another acts himself. TAS ensures that delegation (to AI or agents) does not erase accountability.
The system functions as a Fail-Closed Gate. It does not "permit" by default; it refuses unless four specific constraints are met:
- Identity: A valid, cryptographically signed actor.
- Scope: The action must fall within the explicitly delegated authority of that actor.
- Temporal: The action must occur within a pre-defined, tamper-proof time window.
- Lineage: The action must trace back to a root authority (Human-in-the-Loop).
VALID INPUT → EXECUTES → DETERMINISTIC RECEIPT
BROKEN INPUT → REFUSES → REFUSAL RECEIPT
(Wrong Signer / Scope / Time)
Every interaction with the TAS engine produces a Receipt Hash. Unlike traditional logs, these receipts are:
- Immutable: Recorded to an unalterable ledger.
- Deterministic: Based on input data and system state (removing
time.time()variance). - Evidence-Ready: They serve as standing proof for "Notice of Action" or "Notice of Refusal."
| Component | Status |
|---|---|
| Constraint enforcement (Identity, Scope, Time) | ✅ Proven |
| Deterministic refusal and verifiable receipts | ✅ Proven |
| Institutional adoption protocols | 🔄 In Progress |
| Adversarial stress-testing | 🔄 In Progress |
The .tas-gate file is the declarative contract that binds any agent to a principal's Refusal Parameters. It is the operational bridge between this architecture's constitutional principles and the deterministic code that enforces them.
See architecture/tas-gate for the full schema specification and usage examples.
| Document | Description |
|---|---|
| Architectural Manifest | Full corpus index of all TAS architecture phases |
| Prime Invariant (A0) | Phase 1 — Epistemological bedrock and foundational axioms |
| The Lock | Phase 2 — Mathematical and cryptographic constraints |
The .tas-gate Schema |
Declarative refusal-parameter configuration spec |
Install the Mintlify CLI to preview the documentation changes locally:
npm i -g mintlify
Run the following command at the root of the documentation (where mint.json is):
mintlify dev
All edits must be submitted as pull requests and reviewed by the maintainers before merging into the main branch.
"This system does not require belief. It produces verifiable receipts for authority, scope, and time. Belief builds it. Math proves it. Adoption determines its reach."