Governance as Architecture
Merkle chains, eight human checkpoints, and the case for treating governance as a first-class component of the build system.
Enterprise software change is governed by artefacts: pull request descriptions, Jira tickets, audit dashboards, Slack threads, the occasional screenshot in a quarterly board deck. None of those artefacts are deterministic, and every one of them lives in a different system. The reconciliation cost is the audit budget.
We built Shakti on a single premise: governance belongs inside the build system, not adjacent to it. That sentence sounds simple, but it rules out most of the existing tooling market. Governance-as-architecture means every decision an agent (or a human) makes is captured as a typed, signed, chained artefact at the moment it’s made. Not later. Not in a retro. Not in a weekly compliance huddle.
The Merkle trail
Every phase of the Shakti pipeline ends with a hash. That hash binds the phase’s inputs
(intent + prior state), its outputs (generated artefacts), and its approver (agent or human)
into a single SHA-256 commitment. Each new phase’s entry references the previous entry’s hash
as prev_hash, the same discipline git objects use. Tamper with any historical entry and the
chain breaks in under a second during verification.
The chain isn’t a log. It’s the evidence. The GET /v1/audit/trail endpoint exposes it; the
GET /v1/audit/export/{packet_id} endpoint bundles a packet’s entries into a single signed
JSON document that a SOC 2 auditor can consume with one curl.
Eight human checkpoints
Agents propose; humans approve. Shakti has exactly eight human checkpoints in the 12-phase pipeline — one at every irreversible boundary. The checkpoints aren’t there because LLMs are untrustworthy; they’re there because your audit framework almost certainly says “a human must review high-risk changes.” We give you a defensible artefact for every one of them.
Each checkpoint writes an approval row: reviewer, decision, comment, timestamp, and the artefact hashes under review. The row enters the chain; any downstream auditor who wants to confirm who signed off on the prod-database migration on 2026-03-11 can verify it without opening a ticket.
RBAC vs. capability gates
Classical RBAC assigns roles to users. Capability gates assign permissions to phases. Shakti does both: RBAC governs who can open a pipeline or approve a checkpoint; capability gates govern what an agent can actually do inside a phase. The distinction matters because your most sensitive actions (write to prod database, invoke the LLM provider, push to a branch) need a policy decision independent of the user’s role. The capability gates fire before the agent is even instantiated.
What this buys you
Audit prep collapses from an eleven-week scramble into an export. Your compliance officer can generate evidence on demand; your SREs get a signed attestation that the change they pushed matches the change that was approved; your engineering leaders can trust that a production incident has a deterministic answer to “who changed what, when, and why.”
Governance stops being a tax. It becomes a layer of the build system that accelerates everyone who touches the pipeline. That’s the architectural move Shakti bets on.