We FREEZE-d Our AI System for 34 Days. Here’s What Happened.

On February 26, 2026, our Economic Performance Gate evaluated the system and returned a FREEZE state. Revenue was $0. DLI assessment completion rate was 0%. The gate was doing its job.

We stayed frozen for 34 days.

On day 34, we found the actual problem: a two-line database value that violated a PostgreSQL CHECK constraint. Silent drop. No error. Every metric downstream of that insertion had been wrong from the start.

This is the honest account of what happened, what we missed, and what we built to prevent it from happening again.

The Setup: An AI System That Governs Itself

Our system uses a six-gate architecture to decide whether agents should operate, throttle, or freeze. One of those gates—the Economic Performance Gate (EPG)—evaluates whether the system is creating measurable value. If it is not, the gate fails, and the system halts non-essential agent activity.

The gate is supposed to answer: are real users completing the Decision Load Index assessment?

During the first 34 days of the pilot, the answer it received was: no. Zero completions. Zero starts. 0%.

That answer was correct. It was also based on incomplete data.

The Failure: CONSTRAINT-SILENT-DROP

Here is what was actually happening.

When a user completed an assessment, our code inserted a row into the database with channel="web_tool". That value violated a PostgreSQL CHECK constraint that only accepted a specific set of allowed channel values. The insert failed silently. No exception was raised to the application layer. No error was logged. The row was dropped.

The EPG evaluated the dli_completions table and found zero rows. It correctly reported 0% completion. It correctly triggered a FREEZE.

We spent 34 days assuming the 0% rate was a product problem: users were not completing the assessment. We analyzed the funnel, adjusted routing, reviewed email deliverability, and hypothesized UX failures. None of that was wrong as analysis. All of it was aimed at the wrong variable.

The database constraint had been there from the beginning. The CHECK constraint was enforcing valid channel values. The application code was sending an invalid value. Standard behavior for a strict database. The problem was that the application never received feedback that the insert had failed.

On day 34, a routine database audit found the constraint mismatch. Two lines changed: the channel value updated to match the allowed set. The next assessment completed successfully. The EPG received real data for the first time.

Why This Matters Beyond the Specifics

The failure pattern here is not unusual. Silent data loss from constraint violations is a known class of problem. What makes it worth writing about is the context: a self-governing AI system that evaluates its own performance is only as trustworthy as the data it receives.

The EPG was functioning correctly. It evaluated the data it had, reached the right conclusion based on that data, and enforced the governance state that conclusion implied. The problem was upstream. The data was wrong before the gate ever saw it.

This creates a trust problem that is architecturally different from the usual kind.

When a human evaluates a metric and acts on it, they bring context, skepticism, and adjacent signals. A product manager who sees 0% completion for 34 days while users are signing up daily will ask questions. They will look at the database directly. They will notice the mismatch between signup volume and completion rates.

A gate does not have that skepticism built in by default. It evaluates what it receives. If what it receives is wrong, it evaluates what is wrong. It can do this for 34 consecutive days without flagging the discrepancy—because it does not know what it does not know.

What We Built: Amendment 64 and the MetricIntegrityAgent

After diagnosing the failure, we ratified Constitutional Amendment 64: the Gate Metric Guard.

The amendment requires that any metric feeding a governance gate must pass an integrity check before being used. For the EPG, this means:

• Cross-validate DLI completions against raw event logs, not only the summary table
• Alert if signup volume and DLI start rate diverge by more than a defined threshold
• Require metric freshness timestamps—a metric without a recent timestamp is treated as unavailable, not as zero

We also built a MetricIntegrityAgent that runs hourly, independent of the agents it monitors. Its job is to detect silent data loss patterns: insertions that fail without raising application errors, values that go stale, cross-table inconsistencies that suggest a missing write.

The agent cannot be disabled by the same FREEZE state it is monitoring. It is exempt from throttle conditions by constitutional provision. If the gate metrics cannot be trusted, the gate state cannot be trusted—and the system should know that rather than act on incorrect data.

Lesson 71: CONSTRAINT-SILENT-DROP

We added this to our lessons learned document as pattern 71:

When a database constraint prevents an insert and the application does not receive an error, the data is silently lost. Downstream metrics will be wrong. Systems that evaluate their own performance metrics must verify that the ingestion pipeline is functioning, not just that the query returns expected-looking results.

The remediation steps are:

1. Validate application-layer handling of constraint violations at the point of insert, not at the point of query
2. Add cross-table consistency checks for any metric used in governance decisions
3. Test metric pipelines with invalid inputs, not only valid ones

The Broader Point

AI systems that self-govern based on their own metrics are building on a premise that is easy to state and hard to guarantee: that the metrics reflect reality.

Infrastructure integrity—the confidence that what the database says is what actually happened—is not a solved problem just because a system is sophisticated. A 37,727-line codebase split into clean modules by constitutional mandate can still have a wrong value in a channel field.

The governance architecture we built is sound. The lesson from 34 frozen days is that the architecture needs to extend down into the data pipeline, not only across the agent decision layer.

Self-governance requires honest inputs. Getting honest inputs requires active verification, not passive assumption.