The Governance Spine
Every state-changing operation in Infrix flows through one canonical pipeline — one enforced path from what you want to a proof anyone can check:
- Intent — What you want, described — in plain or typed terms.
- Plan — Infrix compiles your intent into an ordered set of steps.
- Approval — The right approvers sign off before anything runs — enforced, not optional.
- Execution — Each step runs through the best-fit execution for that step.
- Outcome — Results are gathered into one record as finality settles.
- Evidence — A portable receipt is assembled — verifiable offline, no node required.
- Anchor — A digest is anchored to Accumulate, sealing the outcome as final.
intent → plan → approval → execution → outcome → evidence → anchorThis is the governance spinegovernance spineOne enforced pipeline every change must travel: intent → plan → approval → execution → outcome → evidence → anchor. There is no path that mutates state without traversing it.. Each stage has a typed object, a policy hook, and an evidence contribution. There is no path that mutates state without traversing it.
Stage by stage
1. Intent
A user (or operator) submits an Intent describing a desired outcome: "transfer 100 tokens from A to B", "deploy this contract", "register this plugin", etc. Intents are typed (canonical IntentGoalType enum) and carry custom params.
The mediator parses the intent, validates the typed parameters, and compiles it to an ExecutionPlan.
2. Plan
An ExecutionPlan is a deterministic sequence of steps. Each step has:
- A canonical
PlanStepType(PlanStepContractCall,PlanStepSettlement,PlanStepAnchor, ...). - Typed parameters (
UnifiedStepParams). - A
PluginSelectionrecording which plugin will handle the step + scoring rationale (Reason, ConfidentialityImplications, CostImplications). - Approval requirements (
PlanApprovalReq) sized by the step's risk class.
3. Approval
ApprovalsapprovalA signed go-ahead from the actors a step requires. Until the needed approvals land, the step does not run — governance is enforced, not just described. are gathered from the actors named on each `PlanApprovalReq`. The pipeline supports separation-of-dutiesseparation of dutiesA safeguard where the person who requests an action cannot be the person who approves it. Infrix enforces this in code, so a single party can't push a change through alone. (the actor that approves cannot be the actor that submitted), threshold-based multi-party approval, and freshness invalidation (an approval bound to a plan-hash is invalidated when the plan re-compiles).4. Execution
The plan executor walks the topologically-sorted steps, dispatching each through pluginRegistry.DispatchWithCriteria. Infrix's selector picks the best plugin per step from the criteria (confidentiality, cost cap, capabilities, trust domains, operator preference, historical reliability).
Plugins fire universal policy hooks (plugin:admit, plugin:execute, plugin:finalize) and category hooks (settlement:reserve, external:send, etc.) at canonical lifecycle points.
5. Outcome
Each step produces a StepResult; the executor aggregates them into an OutcomeRecord with finalityfinalityHow settled a result is. A result moves from provisional, to locally final, to anchored-final as its anchor is confirmed — at which point it can no longer change. state, gas usage, and policy decisions. The outcome is a managed object — readers consult it via GetWithActor with a DisclosureContext.
6. Evidence
Every plugin contributes to an EvidenceBundle: trace digests, trust snapshots, plan-hash binding, capability proofs, anchor references. The evidence bundleevidence bundleA portable receipt you can verify offline. It packages the proof of what ran so a regulator or auditor can check it without running a node or trusting the network. is portable — a regulator or auditor can verify it offline via evidence.VerifyPortablePackage without running an Infrix node.
7. Anchor
The AnchorOrchestrator writes a digest of the outcome + evidence to Accumulate L0 (or stays in bookkeeping mode per --anchor-mode). AnchoranchorA compact digest of the outcome and its evidence written to Accumulate, which moves a result from provisional to final. The anchor is what lets anyone confirm the result later. confirmation drives the outcome's finality from provisional → locally_final → l0_anchored_final.
What is not on the spine
The traditional contract surface (storage, function calls, events) lives inside an execute step — it is what the spine schedules under the hood. Smart contracts call host functions to read/write storage, but every storage write is a StateChange recorded in the step result and propagated through the dual-state finality window (handled by the runtime's pkg/rewind).
There is no API for "raw transactions" — every write originates from an intent.
Why this matters
The governance spine makes the difference between describing governance (in prose) and enforcing it (in code). Every claim a community-facing pitch makes about Infrix being "governance-first" must be traceable to a hook on the spine. If you can find a state-mutating path that doesn't traverse it, that's a bug worth filing.