--- id: c9-execution-accountability title: Execution Accountability module: GROW-S9 module_slug: grow-s9-dao-governance cluster: Coordination type: playbook version: v0.1.0 status: Gate-reviewed tier: membership contract_role: Produces C11 → Provenance canonical_url: "https://grow.goodcombinator.ai/library/registry/c9-execution-accountability" download_url: "https://grow.goodcombinator.ai/library/registry/c9-execution-accountability.md" license: CC-BY-4.0 (proposed — owner confirmation required) source: GROW by Good Combinator retrieved_at: 2026-05-29 --- # Execution Accountability Playbook The Execution Accountability Playbook closes the gap between a passed proposal and a verified outcome. Governance systems that vote reliably but execute unreliably produce the same result as governance systems that do not vote at all: decisions without consequences. This playbook defines the step-by-step procedure for converting a passed proposal into authorized action, recording that action in the provenance store via the C11 contract, tracking milestone delivery, reporting outcomes to the full DAO, and retiring governance processes that have stopped delivering value. It is the C11 producer: every executed governance decision emits a provenance record to `s3-provenance-metadata-schema` with `decision_origin: governance-vote`. The meta-governance rule is stated here for enforcement clarity: a passed `contract-change` proposal is the only authorized mechanism for amending any substrate file or interface contract at a MAJOR version — no other action, role, or circumstance authorizes a MAJOR amendment, and tooling will not emit a compliant C11 record for a MAJOR amendment that lacks a corresponding passed `contract-change` proposal. --- ## 1. Phase 1 — Post-Pass Authorization When a proposal's voting window closes and the outcome is `passed`: 1. **Tally verification.** The Steward responsible for vote administration publishes the final tally within 4 hours of window close. Tally includes: total eligible weight, votes cast, abstentions, yes/no breakdown, quorum met/failed, approval ratio, and outcome. The tally is signed by the administering Steward and stored as evidence. 2. **Veto window opens.** The Executor is notified of the passed outcome. The Vetoer (if any, per `c9-decision-rights-matrix`) is formally notified that the veto window is running. The Executor must not act until the veto window closes without exercise. 3. **Veto exercise (if applicable).** If the Vetoer exercises the veto within the window, the Vetoer submits a written rationale. The outcome changes to `vetoed`. A C11 record is emitted with `outcome: vetoed`. The proposal may be revised and resubmitted; the revision clock restarts. 4. **Execution authorization.** When the veto window closes without exercise (or if the decision class has no Veto right), the Executor is authorized to proceed. The Executor must emit the C11 provenance record **before** beginning irreversible actions. Pre-emission is mandatory for financial disbursements, contract commitments, and on-chain transactions. --- ## 2. Provenance Emission (C11) This section implements the C11 contract. Every executed governance decision emits exactly one C11 record to `s3-provenance-metadata-schema`. ### 2a. C11 Payload Schema | Field | Type | Allowed Values | Notes | |---|---|---|---| | `proposal_id` | string | kebab-case | Must resolve to a `c9-proposal-design-template` instance in the proposal registry | | `decision_class` | string | per `c9-decision-rights-matrix` | E.g., `treasury-allocation`, `contract-change`, `retroactive-reward` | | `outcome` | enum | `passed` \| `rejected` \| `vetoed` \| `quorum-failed` | As determined by `c9-governance-mechanisms-spec` tally rules | | `decision_rights_ref` | string | pointer to decision-rights matrix row | E.g., `c9-decision-rights-matrix#treasury-allocation` | | `evidence_pointer` | string | URI resolving to vote tally and proposal evidence pack | Must resolve at write time; dangling pointer fails the eval gate | | `decision_origin` | enum | `governance-vote` | Locked; no other value is valid for governance decisions | **Emission rule:** Every governance outcome — pass, reject, veto, quorum-fail — produces exactly one C11 record. A governance event with no C11 record is a provenance violation and triggers an evidence-drift alert in `s3-provenance-metadata-schema`. **Heavy-payload handling:** The vote tally, proposal body, and evidence pack are stored in full in the `s2-audit-trail-schema` audit record. The C11 record holds a `{ref, hash, field}` pointer into that audit record per the C3 split-storage model — it does not inline the tally or evidence body. ### 2b. C11 Emission Procedure ```yaml c11_record: record_id: audit_record_ref: ref: hash: proposal_id: decision_class: outcome: decision_rights_ref: evidence_pointer: decision_origin: governance-vote timestamp: owner: retention_class: ``` Sign-offs are recorded in `s2-audit-trail-schema` via the `decision_trace[]` mechanism: ```json { "event_id": "", "timestamp": "", "agent_id": "", "decision_origin": "governance-vote", "evidence_pointer": "", "rationale": "" } ``` ### 2c. Meta-Governance Rule A `decision_class: contract-change` proposal with `outcome: passed` is the **only** mechanism authorized to amend a C1–C12 contract or a substrate file (`glossary.md`, `interface-contracts.md`, or any `s1-*`/`s2-*`/`s3-*` artifact) at a MAJOR version. This rule is enforced in two ways: 1. **Procedurally:** The Executor of a `contract-change` proposal must emit the C11 record before committing the amendment. Any amendment committed without a C11 record is a governance violation. The Accountable Steward must reverse the amendment or submit a retroactive `contract-change` proposal. 2. **By lineage check:** The `s3-provenance-metadata-schema` lineage chain for any MAJOR-version artifact must contain a `decision_trace[]` entry with `decision_origin: governance-vote` and a resolvable `evidence_pointer` pointing to a passed `contract-change` C11 record. A MAJOR-version artifact whose lineage chain lacks this entry fails the integration gate in `builders-evaluation-gate`. No role, no emergency power, and no unilateral steward decision authorizes a MAJOR contract or substrate amendment outside this path. --- ## 3. Phase 2 — Execution Tracking After the C11 record is emitted and execution begins: 1. **Milestone tracking.** For milestone-gated proposals, the Executor maintains a milestone log. Each milestone is updated as the deliverable is completed and the milestone reviewer signs off. The reviewer's sign-off is recorded as a `decision_trace[]` entry in the `s2-audit-trail-schema` record for that milestone tranche. 2. **Disbursement sequencing.** The Treasurer releases each tranche only after the milestone reviewer's sign-off is logged. The Treasurer does not disburse on verbal confirmation alone; the written sign-off and its timestamp in the audit trail are the authorization. 3. **Deadline monitoring.** The governance operations working group (or equivalent role) monitors active milestone deadlines weekly. Milestones at risk of missing their deadline are flagged at the monthly proposal pipeline review per `c9-governance-mechanisms-spec §7`. 4. **Budget reconciliation.** After each disbursement, the Treasurer reconciles the treasury balance and reports the updated reserve ratio. Any disbursement that would push the reserve below the floor defined in `c9-resource-allocation-framework §1` is blocked and escalated to the Steward Council. --- ## 4. Phase 3 — Outcome Reporting Execution accountability is not complete at disbursement; it is complete when the outcome is verified and reported. ### 4a. Outcome Evidence Requirements When execution is complete (all milestones delivered or the proposal's execution deadline reached), the Accountable role submits an outcome report including: - Completion status: `delivered-in-full`, `partial-delivery`, `not-delivered` - Evidence of delivery for each milestone: links to the same evidence types required at proposal time - Actual spend vs. proposed spend, with variance explanation - Impacts observed vs. impacts claimed in the proposal summary The outcome report is attached to the C11 provenance record as an additional `evidence_pointer` (appended, not replacing the original pointer). ### 4b. Outcome Reporting Cadence | Proposal Scale | Reporting Cadence | Report Format | |---|---|---| | Single disbursement, ≤ 30 days | One outcome report within 30 days of execution | Brief (≤ 1 page) | | Milestone-gated, 31–90 days | One report per milestone + final outcome report | Milestone log + summary | | Milestone-gated, > 90 days | Monthly progress report + milestone reports + final | Dashboard update + log | Progress reports are shared with the full DAO at the monthly governance review defined in `c9-governance-mechanisms-spec §7`. --- ## 5. Phase 4 — Process Retirement Governance processes that consistently fail to deliver are more expensive than their value. This phase identifies and retires them. ### 5a. Retirement Triggers A governance process (recurring working group, standing policy, or proposal template) is flagged for retirement review when any of the following conditions hold for two consecutive governance-review periods: - Quorum-fail rate on proposals in this class exceeds 40% - Outcome "not-delivered" or "partial-delivery" rate for executed proposals in this class exceeds 30% - The working group operating under the process has not reported at its stated cadence for two consecutive periods - The decision class produces no proposals in two consecutive periods (dormancy) ### 5b. Retirement Process 1. The Steward Council flags the process at the governance-review meeting and publishes the trigger condition with supporting data. 2. A 30-day remediation window opens. The process owners may submit a remediation plan addressing the trigger condition. 3. If no remediation plan is submitted, or the plan is rejected by the Steward Council, a `working-group-charter` dissolution proposal is submitted (or the decision class is deprecated via `contract-change`). 4. On dissolution: all in-progress proposals under the class complete their current cycle. No new proposals of that class are accepted after the dissolution date. Unspent funds revert to `unallocated`. --- ## 6. Worked Example — PP DAO Infrastructure Proposal Full Execution Cycle **Proposal:** `pp-dao-prop-2026-003` — AI inference hardware refresh `(illustrative)` ### Pass → C11 Emission → M1 Execution After the voting window closes on 2026-02-15 at 23:59 UTC `(illustrative)` with the tally showing quorum met and 77% approval, the Steward publishes the tally within 4 hours. The 48-hour veto window opens at 2026-02-16 00:00 UTC. At 2026-02-18 00:01 UTC, the veto window closes with no veto exercised. The Executor (Treasurer) emits the C11 record: ```json { "record_id": "0191bc4a-9d3e-7f22-ae11-5c41d9e0b823", "audit_record_ref": { "ref": "0191bc4a-8c2d-7a11-9f00-4b30c8d0a712", "hash": "sha256:4f8a1c..." }, "proposal_id": "pp-dao-prop-2026-003", "decision_class": "treasury-allocation", "outcome": "passed", "decision_rights_ref": "c9-decision-rights-matrix#treasury-allocation", "evidence_pointer": "s3://pp-dao/prov/prop-2026-003/vote-tally.json", "decision_origin": "governance-vote", "timestamp": "2026-02-18T00:15:32.000-06:00", "owner": "Treasurer", "retention_class": "dao-5yr" } ``` After the C11 record is confirmed written (hash verified against `s3-provenance-metadata-schema`), the Treasurer initiates the M1 hardware order. ### M1 Sign-Off → M2 On 2026-03-20, the hardware is delivered. The Site Manager inspects, logs the delivery receipt and asset tag, and signs off: ```json { "event_id": "0191cc5b-0e4f-7a33-bf22-6d52eaf1c934", "timestamp": "2026-03-20T14:42:00.000-05:00", "agent_id": "site-manager", "decision_origin": "governance-vote", "evidence_pointer": "s3://pp-dao/prov/prop-2026-003/m1-delivery-receipt.pdf", "rationale": "M1 delivered: hardware at 725 J D Miller Rd, asset tag PP-INF-2026-01" } ``` The Treasurer disburses M1 tranche ($18,000 `(illustrative)`) only after this event is written to `s2-audit-trail-schema`. ### Outcome Report On 2026-08-16, the Technical Lead submits the M3 completion report: uptime 99.7% over the 90-day window. Cloud costs dropped to $7,800/yr (illustrative) vs. the projected $8,000. The outcome report is attached to the C11 record as an additional `evidence_pointer`. The Accountable (Treasurer) marks the proposal `delivered-in-full` in the governance dashboard. --- ## 7. Execution Accountability Failure Modes | Failure Mode | Signal | Correct Behavior | |---|---|---| | Execution before C11 emission | No C11 record exists for an executed action | Halt execution; emit C11 retroactively if reversible; accountability review for Executor | | MAJOR amendment without `contract-change` pass | Lineage chain lacks `governance-vote` / `contract-change` entry | Reverse amendment; require `contract-change` proposal; Accountable Steward liable | | Disbursement before milestone sign-off | Tranche released without reviewer log entry | Recover funds if possible; governance-violation record; accountability review | | Outcome report not submitted | Proposal status remains "executing" past deadline | Steward Council flags; Accountable role notified; process-retirement trigger starts | | Evidence pointer does not resolve | `evidence_pointer` in C11 record returns 404 | Block the C11 record from passing eval gate; Executor must supply a resolving pointer before execution proceeds | --- ## 8. Cross-Reference Summary | Artifact | Relationship | |---|---| | `c9-decision-rights-matrix` | Executor, Accountable, and Vetoer columns drive this playbook's role assignments | | `c9-resource-allocation-framework` | Reserve floor check and milestone rules are enforced at disbursement time | | `c9-proposal-design-template` | `proposal_id` in C11 record resolves to a proposal instance from this template | | `c9-governance-mechanisms-spec` | Quorum and tally rules determine the `outcome` value in the C11 record | | `s2-audit-trail-schema` | Sign-offs, milestone log entries, and tally records are written here | | `s3-provenance-metadata-schema` | C11 records are written here; MAJOR-amendment lineage checks run here | ## Usage Notes The single most common accountability failure is executing before emitting the C11 record. Build the tooling to enforce pre-emission: the disbursement step in your treasury tool should require a C11 record ID before it will execute a transfer. If your tooling cannot enforce this, make the Treasurer's checklist explicit: "C11 emitted: YES/NO" is the first item before any disbursement action. Review the retirement triggers annually; a dormant governance class left in place produces confusion and governance-theater overhead.