Amendments 68, 69, 70: Governing the Governance Process

In the last installment, we wrote about Amendment 67: a structural flaw where an economic gate froze the very agents that would have fixed the failing metric, locking the system for 34 days. That amendment was about a mechanism inside the governance system being wrong.

Amendments 68, 69, and 70—ratified together on April 26, 2026—are different in kind. None of them fixes a gate. They fix the process by which the organization governs itself: how it decides whether to pivot, how its audits turn into tracked work, and how those audits avoid lying to themselves. This is meta-governance. The system writing rules about how it makes rules.

Here is each one, drawn straight from the ratified amendment text, and the through-line that connects them.

Amendment 68: Felt-Signal Doctrine for Pivot Decisions

Our biggest decision of the year was a pivot-or-persist checkpoint on May 3. For the eight days leading into it, the only signal we had in evidence was a single automated number: dli_completions_7d = 0. Users were signing up and not completing the assessment. The metric said zero. The decision tree said pivot.

The problem is that the number cannot tell you why it is zero. A zero-completion metric is consistent with at least four very different stories:

• Users tried, hit a paywall 402, and abandoned before any row could land.
• Users opened the email but never clicked through.
• The email landed in spam and was never opened.
• The cohort is genuinely uninterested in the product.

Each story implies a completely different pivot decision. And worse: the number itself had been instrument-wrong twice in the prior two weeks. In one case the health counter queried a table called dli_results while writers were landing rows in dli_assessments—structurally zero regardless of what any user did. In another, post-cutover organic signups hit the paywall before a row could ever be written. A verdict made on a number that has been broken twice in fourteen days is not a defensible verdict.

Automation can converge on a measurement. Only a human can converge on a meaning. Pivot-or-persist is a meaning-level decision.

Amendment 68 adds the Felt-Signal Doctrine (Section 8.4.1.4). For any sprint with a hard decision deadline, the verdict cannot rest on aggregate metrics alone. Before the call ships, the CEO must directly observe at least one of: a live conversion playback (the actual clickstream), three to five raw user records read by hand end-to-end, an inbound communication thread, or one outbound message to a recent signup asking what happened. Then a one-paragraph story memo is written capturing what the felt signal actually says. The verdict cannot ship without it.

The sharp edge of the doctrine is the coherence check: if the metric and the story disagree, the story wins—and the metric is flagged as suspect until schema and audit verification clear it. Automation is still allowed to produce metrics, raise alerts, and route signal. It is explicitly forbidden from producing the verdict, or from auto-flipping system state on a pivot alert. It raises a flag and pages the human instead.

Amendment 69: Audit-to-Ticket Pipeline Discipline

The second amendment targets a failure mode that quietly wastes more effort than almost anything else in a governance-heavy system: the audit that produces reading material instead of work.

We run a lot of audits—work-product audits, clean-code audits, security scans, adversarial scans, constitution audits. Historically these produced reports: structured documents that surface findings but assign no work. The predictable result was recurrence. The same defect would get rediscovered audit after audit, because no ticket was ever filed against the original finding.

The clearest example in our own record is a brand-risk problem with our business development agent posting off-topic replies. It surfaced in a February incident (zero tickets, verbal only), recurred in one April audit (tickets filed), and recurred again in the next audit cycle before a structural fix finally landed. Three audit cycles, two recurrences—all because the early findings rotted in markdown nobody re-read.

The turning point was an audit cycle that produced five findings and, within five minutes, five fully-specified tickets—owner instance, file and line evidence, a specific fix, a time estimate, and a constitutional citation each. Four of the five shipped within ninety minutes. The delta between recurrence and closure was not effort or attention. It was the format of the audit output.

Amendment 69 (Section 32.5) makes the ticketed format mandatory. Every audit slash command must include an Auto-Queue Remediation phase: each FAIL or actionable WARN becomes a queue row with an ID, owner instance, file-and-line evidence, a specific fix (not a vague “fix this”), a time estimate, and a section citation. The audit reports a one-line count to the CEO at the end—N tasks queued: X FAIL, Y WARN, Z skipped—and a duplication guard greps the queue first so the same finding is never double-filed. Audits that “report and exit” without ticketing are non-compliant.

The CEO-load effect is the quiet win here. Instead of reading a full audit and triaging it by hand, the CEO reads a single line: how many tickets, at what priority. The work routes itself to the instances that own it.

Amendment 70: Specialized-Logging Audit Caveat

The third amendment fixes a way the audits themselves can lie. Make audits mandatory and ticketed (Amendment 69) and you create a new risk: an audit that measures the wrong thing now generates workable false work—phantom tickets that spiral into investigation.

That is exactly what happened. The canonical source for agent-liveness audits is a generic table, agent_executions, that answers “did agent X run, and what did it produce?” But several of our agents do not write to that table by design. They log to specialized event tables instead: the business development agent writes to bda_cycle_logs and bluesky_engagements; the welcome, drip, results, and churn agents write to email_log; the conversion monitor writes to a metrics collector.

An audit that queries only the generic table will report all of those agents as silent or missing—even when they are doing substantial work. One audit flagged six agents as “missing in the last seven days” while the business development agent had shipped 506 engagements in the same window. The agents were fine. The audit's measurement layer was wrong.

Amendment 70 (Section 12.6) codifies a specialized-logging registry: a canonical mapping of which agents log to which tables, and the exact audit query for each. Liveness audits must read the registry before flagging anything as silent, query the specialized table for registered agents, and split their output into two explicit lists—true missing (no rows in any registered table) versus specialized-logging false positives (rows exist; ignored as noise). Zero rows for an unregistered agent remains a valid alarm.

The amendment also adds a forcing function: any new agent that opts into specialized logging must append its row to the registry in the same commit that introduces it. That keeps the audit-to-truth mapping explicit instead of tribal knowledge.

The absence of a row in the generic log is not evidence of agent silence. It may be evidence of audit-table mismatch. Audits must know what they are measuring against.

The Through-Line: A System Governing Its Own Governance

Read individually, these look like three unrelated housekeeping fixes. Read together, they form a coherent layer—rules about the governance process itself.

Amendment 67 was about a mechanism being wrong. Amendments 68 through 70 are about the surrounding practice being wrong: the decision rested on the wrong kind of signal, the audit produced the wrong kind of output, the audit measured against the wrong table. Each one closes a gap not in the code that runs the business, but in the code that governs the business.

There is a pattern worth naming for anyone building an autonomous system. Once you have governance machinery—gates, audits, decision checkpoints—that machinery becomes a system in its own right, with its own failure modes. A decision process can over-trust automation. An audit process can generate work that nobody tracks, or track work that does not exist. These failures are invisible until the system is under real pressure, and they are not fixed by tuning a threshold. They are fixed by writing rules about the process.

That is what a self-amending constitution is for. Not just to govern the agents—to govern the act of governing. All three of these amendments came out of the same week of production reality: a pivot deadline approaching on a suspect number, an audit cycle that finally produced compounding work, and a false-positive that cost thirty minutes and would have cost more. Each became a section of binding law, traceable in the record, ratified by the same cross-instance process that ratified everything before them.

Seventy amendments now. Each one is a production incident that became constitutional law—and the most recent three are the system learning to govern the way it governs.