Who decided this action could happen?
When a human acts, someone authorized it: a manager approved, a policy permitted, a law allowed. When software acts, the answer is often nobody in particular: a configuration permitted a class of behavior months ago, under assumptions nobody recorded, against rules nobody versioned. The decision dissolves into the system.
We think consequential automation deserves the same standard as consequential human action: an explicit decision, by an identifiable authority, against rules in force at that moment.
The ActionSpecs Protocol requires every governed operation to be declared before execution and evaluated against versioned, signed policy, producing one of six explicit verdicts. The verdict names the policy version and the clause that fired. Under a conforming implementation, a governed operation must receive an explicit verdict before execution; an operation without a verdict must not proceed.
Published draft · protocol §4 to §7Can anyone prove what actually happened?
Most systems can show you a log. Logs are written by the system being questioned, kept by the operator being audited, and reconcilable with the original authorization only through effort and trust. When the stakes are real (a security incident, a regulatory inquiry, a dispute), "our logs show" is an assertion, not a proof.
A consequential operation must not occur without a policy verdict, and no verdict or outcome may exist without a receipt.
The protocol pairs every operation with two cryptographically linked records: a Proof of Authorization at verdict time, and a Proof of Operation and Delivery after execution, committed to an append-only, hash-linked ledger. Under a conforming implementation, the difference between the recorded authorization and the captured operation becomes an explicit, inspectable artifact rather than something reconstructed solely from separate logs.
The evidence-bundle design is intended to support verification by reviewers with no access to, and no trust in, the operator or the live system.
Published draft · protocol §8 · verifier tooling in developmentWho governs the rules themselves?
Every governance system faces the same recursion: the rules constrain the system, but who constrains changes to the rules? If policy can be edited quietly, whether by an administrator, an attacker, or the operator under pressure, then every downstream guarantee inherits that weakness. Most compliance regimes answer this with procedure. Procedure is exactly what fails under pressure.
In ActionSpecs, changing the rules is itself a governed action: proposed as a declaration, verdicted, signed, and receipted like any other operation. The audit chain therefore covers not only what the system did, but the entire history of the rules it did it under. We call this governance of the governor, and we consider it non-negotiable.
Published draft · protocol §7Can a human still intervene, and is the intervention accountable?
Two failure modes bracket this question. In one, automation cannot be overridden, and humans watch helplessly as a system does the wrong thing correctly. In the other, override is easy and anonymous, and accountability evaporates precisely when it matters most. Most systems pick a side. We think the choice is false.
The protocol treats override as a first-class governed action. A conforming override must be attributed to an authenticated actor, include a stated justification, receive a verdict under the applicable policy, and generate linked evidence permanently associated with the decision it overrides. Intervention is preserved; unattributed override is non-conforming. Accountability by construction, not by procedure.
Published draft · protocol §9When something goes wrong, can it be found, and undone?
Incidents happen: a compromised credential, poisoned data, a bad deployment. Today's honest answer to "what did it touch?" is weeks of forensics with no completeness guarantee, and the answer to "was it fixed?" is a statement of belief. We think remediation should be as provable as the original act, including honesty about what cannot be reversed.
Because every governed operation is receipted and linked, the record forms a graph: walked backward, it supports audit and provenance; walked forward from a tainted operation, it is intended to identify affected downstream operations represented in the governed lineage record. Our roadmap extends the protocol so that each remediation step is itself a governed, receipted action, with operations honestly classified by reversibility, what was undone, what was contained, and what could not be reversed.
Roadmap · future protocol versionWhy should anyone trust the company building this?
A fair question, trust infrastructure from an opaque vendor is a contradiction. Our answer is structural rather than rhetorical, and it comes in three commitments we have already begun keeping.
The foundation is open. The ActionSpecs Protocol is published under CC BY 4.0 with defined conformance requirements. Anyone may inspect it, implement it independently, and evaluate NUBAS against it. We chose to publish the protocol draft before shipping the platform, so our implementation can be evaluated against public requirements.
The authoritative decision path is deterministic. No probabilistic model or language model determines a verdict. Policy evaluation and authoritative rationales must remain deterministic, reproducible, and attributable to the rules in force.
Published releases are not silently rewritten. Protocol changes are introduced through versioned releases and documented changelogs. Built capabilities are described as built; intended capabilities remain labelled as intended. It is the same discipline this page practices.
In effect · verifiable at github.com/adekka-canadaWhere this is going
We do not think accountability is a feature to be added to automation later, the way security was bolted onto the early internet, at enormous and permanent cost. We think it is a property of architecture, decided at the foundation, and that the window to set that foundation is now, while autonomous systems are still earning their place in consequential roles.
Adekka's work is one bet on that view: formalize the architecture, publish it openly, build the reference platform, and let every claim be checked against the record. If we are right, the systems that act on our behalf will carry their own accountability with them, and trusting automation will stop being an act of faith.