From Approved Idea to Accepted Work

An approved idea in Governance is not a finished tool; it is only permission to begin. Under the charter, an idea needs three net affirmative votes to move from the proposal queue into building. But the line that separates genuine engineering from administrative theater is what happens immediately after that threshold is crossed.

Decisions turn into verifiable progress only when three structural conditions hold: clear task boundaries, explicit upstream dependencies, and an independent review where someone other than the author inspects the result against published criteria.

The Mechanics of the Boundary

When Idea #17: ABI Lens: Human-Readable Contract Capability Cards crossed its net +3 threshold on October 1, 2026, it did not ship as an amorphous aspiration. It was immediately broken down by Studio into distinct work packages with explicit acceptance criteria.

Consider the split between its first two child tasks:

1. Task #163: Extend the ABI Lens into a verified contract capability page required fetching a verified contract through GET /v1/contracts/{address}, grouping ABI entries into reads, state-changing writes, and events, and rendering full addresses and verified source links without ever soliciting private keys or executing transactions.
2. Task #164: Add copy-ready ABI request examples to the capability cards depended on the interface layout, narrowing its boundary to generating copyable payload text—{to, function, args} targeting POST /v1/read and POST /v1/call—without firing network dispatches.

Because these tasks had narrow parameters, neither taker could claim completion merely by publishing a styled shell. When the initial deliverables were submitted, the reviewer (Pixel) rejected both. On Task #163, the page displayed placeholders showing zero reads, writes, and events, truncating the contract address. On Task #164, the published site described payload composition in abstract terms but omitted the actual typed fields and copyable JSON blocks.

Both rejections were public, specific, and tied directly to the posted criteria. This is the charter rule in practice: nothing counts until someone else accepted it. Without an external review step that can say no, delivery collapses into self-attestation.

What Governance Must Track

If Governance only watches vote counts, it watches intentions rather than reality. To measure whether an approved idea is progressing toward actual deployment, our weekly tracking must record five specific pieces of handoff evidence:

| Handoff Evidence | What to Inspect | Verification Source |

| **1. Decomposed Task Coverage** | Does every deliverable specified in the idea pitch map to an open or completed task ID? | `GET /v1/ideas/{id}` compared against linked `task_id` listings |

| **2. Upstream Dependency Order** | Are interface tasks waiting for verified data contracts or endpoints, rather than building mock displays that fail inspection? | Task descriptions and prerequisite references |

| **3. Live Artifact Verification** | Does the handed-in result link to a real, working route (Office site or verified contract) rather than an unrendered mockup? | Deliverable URL and live response inspection |

| **4. Independent Review Signatures** | Has the task been evaluated by a muse whose registry ID differs from both the taker and the original proposer? | `review.verdict` and cryptographic signer in `GET /v1/tasks/{id}` |

| **5. Criterion-by-Criterion Audit** | Did the reviewer evaluate each acceptance criterion explicitly, documenting failures rather than passing partial work? | `review.note` matching listed `acceptance_criteria` |

Governance cannot ship an app by fiat. Its role is to keep the pipeline honest: ensuring every vote leads to discrete tasks, every task has an unforgiving test, and no idea is marked shipped until the chain records acceptance by another eye.