Hard Constraints, Not Policies

In February 2026, one of our AI agents ran unsupervised for several days while producing outputs that looked healthy on operational dashboards. The agents were executing their scheduled tasks. Completion rates were normal. The measurement system was reporting green.

What was broken was the data the measurement system was reading. The metrics that the economic evaluation gate depended on had been fabricated—not by a bad actor, but by a chain of silent failures that caused the system to report cached values as current ones. The gate was evaluating against numbers that were weeks old. Because the numbers were old enough to be stale but recent enough to look plausible, no threshold was breached. No alert fired.

We caught it because one hard constraint was still working correctly: the constraint that prohibits any metric used in gate evaluation from being more than 48 hours old without a freshness marker. When that constraint fired, it produced a BLOCK-level sign in the agent execution log. The sign propagated to the circuit breaker. The agents stopped.

That constraint is twelve lines of Python in a pre-commit hook. It has no exception path. It cannot be overridden by agent instruction or contextual reasoning. It either passes or it blocks. That is the distinction this article is about.

The Policy Illusion

Every major AI ethics framework published in the last five years contains some version of the same guidance: organizations should establish clear policies about how AI systems are used, ensure those policies are communicated to relevant stakeholders, and audit compliance periodically. NIST. ISO. The EU AI Act. The White House Executive Order on AI. All of them.

None of that guidance is wrong. Documented policies do matter—for establishing expectations, for training, for regulatory defense in the event of an incident, for board-level visibility into what the organization intends. The problem is where in the governance stack those policies live.

A policy is a description of intended behavior. It exists at the documentation layer. An agent that encounters a policy must interpret it, reason about its applicability to the current context, and apply judgment under conditions the policy authors did not anticipate. Each of those steps is an opportunity for drift.

The gap is not a matter of agent capability. More capable agents are more capable of sophisticated policy interpretation—which means they are more capable of identifying contextual exceptions, edge cases, and situations where the policy, strictly applied, would produce an outcome that seems worse than non-compliance. A policy that says “do not contact users more than once per day” will be interpreted differently by an agent reasoning through an edge case where two separate systems each believe they are the only one sending a message that day.

This is not a hypothetical failure mode. It is the normal operating condition of any sufficiently complex system running under policy guidance rather than hard constraints.

The accountability gap is the practical consequence. When a policy violation occurs, the investigation is about who failed to enforce it. When a hard constraint fires, there is no investigation—the action did not happen. For a CIO or CISO defending a governance posture to a board or regulator, that distinction is not semantic. It is the difference between “our policy prohibited this and it happened anyway” and “our system cannot do this.”

Hard Constraints in Practice

A production constitutional AI governance system running for 90 days in 2026 operated under 17 hard constraints. They were called Hard Constraints (HC-1 through HC-17) in the constitutional document, and they had a specific property that distinguished them from every other rule in the system: no override, no exception, no agent reasoning could bypass them.

The constraints covered four domains. Financial constraints set the absolute floor conditions under which the system would operate. Security constraints defined code patterns that could not appear in any commit. Integrity constraints governed what could be reported as true. Operational constraints set the boundaries on automated actions affecting external parties.

What makes these constraints hard is not the severity of their content but the layer at which they are enforced. The financial constraints were not enforced by a monitoring alert that fires after a spend decision is made. They were enforced by a gate evaluation that runs before any agent decision that involves budget, and that returns a BLOCK state rather than a warning when the constraint would be violated. The gate does not advise against the action. It does not log a warning. It prevents the action.

Financial constraints: runway and spend approval

HC-3 prohibits any growth-related spend when runway falls below three months. The enforcement mechanism is a gate evaluation that checks current runway against a live database query before any agent decision that involves discretionary budget. If runway is below the floor, the gate returns FREEZE—and all agents with spend authority shift to a zero-spend operating mode automatically. There is no agent reasoning step where a particularly urgent opportunity could justify an exception. The gate does not receive the opportunity as context. It receives the runway number. That is the only input.

HC-4 sets a $500 ceiling on any single autonomous spend decision. Above that ceiling, a human approval endpoint must be called before the transaction proceeds. This is not a monitoring rule that flags large transactions for review after the fact. The agent's execution path for any spend decision branches on the dollar amount before any external call is made. If the amount exceeds $500, the branch that calls the human approval endpoint is taken. There is no path that skips it.

Security constraints: code-layer enforcement

HC-9 prohibits timing-unsafe string comparisons in any security-sensitive code path. The enforcement mechanism is a pre-commit hook that runs static analysis on every commit. If the pattern is detected—a direct equality comparison on a string that participates in an authentication or authorization decision—the commit is rejected before it reaches the repository. The developer sees an error message citing the constraint number. The commit does not happen.

HC-17 prohibits bare exception handlers that silently swallow errors. The same pre-commit hook scans for the pattern except: pass and variations, and rejects commits containing it. Silent exception handling is one of the most common root causes of cascading failure in complex systems: an error occurs, is caught and discarded, and the system continues operating in a state that is subtly broken in ways that compound over time. The constraint does not ask engineers to avoid this pattern. It makes the pattern a commit-time failure.

Integrity constraints: what can be reported as true

HC-12 is the constraint that caught the fabrication incident described at the opening of this article. It prohibits any metric used in gate evaluation from being reported without a freshness timestamp, and it blocks gate evaluation when that timestamp exceeds 48 hours. The constraint does not prevent the system from having stale data. It prevents the system from making decisions based on stale data without surfacing that condition explicitly. When the freshness check fails, the system enters a diagnostic state rather than continuing to operate as if the data were current.

HC-11 prohibits fabricated data in any report, agent output, or metric that feeds into a gate evaluation. The enforcement mechanism here is partially architectural (gate inputs are sourced from database queries, not from agent-generated text that could contain hallucinations) and partially operational (agent outputs that feed into gate evaluations are validated against database state before use). The constraint cannot prevent an agent from producing an incorrect number. It prevents that number from influencing system behavior without passing through a verification step.

Operational constraints: actions affecting external parties

HC-6 prohibits sending more than one email per user per 24-hour window across any template type. The enforcement mechanism is a database-backed rate limit check that runs before any email send operation. The check queries the email log for the specific user-template combination within the relevant window. If a record exists, the send is blocked. This is not an in-memory rate limiter that resets on process restart. The check is against persisted state. An agent cannot reason its way around it by restarting or by using a different template classification.

HC-8 prohibits silent agent outages exceeding 24 hours. If an agent fails to produce a verified execution record within 24 hours of its scheduled cycle, a CRITICAL-level sign is created in the sign registry and a human escalation is triggered. The constraint is enforced by a cron job that runs every hour and checks execution timestamps against the 24-hour window. No agent reasoning is involved. The cron job does not evaluate whether the outage is significant. It checks the timestamp. If the condition is met, the escalation fires.

The Enforcement Architecture

Describing what constraints prohibit is less instructive than describing how they are enforced. The enforcement architecture has three layers, and constraints must be present at all three to be genuinely hard.

Pre-commit hooks: the first line

Pre-commit hooks run before code enters the repository. They are the correct enforcement point for constraints that apply to code patterns—security vulnerabilities, architectural violations, missing citations. A constraint enforced only at code review is a policy. A constraint enforced at commit time, by a hook that rejects the commit on violation, is a hard constraint. The distinction is that the code cannot reach production while violating it. A reviewer's attention is not required.

The constitutional citation requirement is enforced this way. Every code change that touches governance-sensitive logic must include a comment citing the section number it implements. The pre-commit hook scans the diff for the pattern. If the change modifies a gate evaluation or a constraint check without a citation, the commit fails. This is not a style guideline. It is a structural requirement that makes governance-critical code changes traceable by construction.

Gate evaluations: the decision layer

Gate evaluations run before agent execution. The six-gate architecture evaluates each proposed action against six independent criteria—epistemic (is the agent certain enough to proceed?), risk (does this action expose the organization to unacceptable outcomes?), governance (does this action comply with the constitutional framework?), economic (does this action remain within financial constraints?), autonomy (is the agent authorized to make this decision without human involvement?), and constitutional (does this action respect the integrity of the governance system itself?).

Any gate returning FAIL produces a FREEZE state. The agent does not execute the action. It logs the gate failure, creates a sign in the sign registry, and enters a diagnostic loop. The action is not deferred or queued for later consideration. It does not happen. The gate evaluation is the execution gate, and a failed gate is a closed gate.

Constitutional citations: the audit trail

Every change to governance-critical code in the production system includes a comment in the form # Section X.Y: [description of constraint enforced]. This is not a documentation convention. It is a searchable audit trail that connects every enforcement point to the constitutional provision it implements. When a constraint fires and produces a sign or a FREEZE state, the sign record includes the section citation. An engineer investigating the incident can trace from the alert to the code to the constitutional provision in a single search.

The citation requirement also creates a forcing function for governance coverage. If an engineer cannot identify a section that justifies a change to governance-critical logic, that is a signal that either the governance framework needs an amendment or the change should not be made. The pre-commit hook makes this explicit: changes to files in the governance-critical path without a citation are rejected.

Why This Matters for Buyers of AI Governance

The practical consequence of the policy-versus-constraint distinction is visible in incident patterns. Policy-governed systems produce a specific class of post-incident report: the investigation concludes that the policy was clear, the policy was communicated, and the policy was violated anyway because of a contextual factor, an edge case, or a gap between what the policy said and what it was interpreted to mean in the specific situation. The remediation is typically a policy clarification or additional training.

Constraint-governed systems produce a different class of incident report: the investigation concludes that the constraint did or did not fire as intended. If the constraint fired and the action was still taken, the enforcement mechanism has a gap. If the constraint fired correctly and the action was prevented, there is no incident—the constraint worked. The investigable failures are architectural, not behavioral. They are addressable at the system level, not through communication or training.

Policies are auditable after the fact. Hard constraints prevent the incident from occurring. For a CISO explaining a governance posture to a board, that distinction determines whether the conversation is about remediation or about architecture.

When evaluating AI governance frameworks, the question worth asking is not “do you have a policy for X?” The question is “what happens in the system when X is attempted?” If the answer describes a monitoring alert, an audit log entry, or a review process, the governance is at the policy layer. If the answer describes a gate evaluation that returns FREEZE, a pre-commit hook that rejects the commit, or an execution path that cannot proceed without a human approval call, the governance is at the constraint layer. The capability delta between those two answers is the risk delta between those two governance postures.

What NIST and the EU AI Act Actually Require

Both major regulatory frameworks in AI governance make the policy-versus-constraint distinction, though neither labels it that way.

The NIST AI Risk Management Framework, in its Govern function, calls for “policies, processes, procedures, and practices across the organization related to the mapping, measuring, and managing of AI risks.” That language is policy-layer language. But in the Map and Measure functions, NIST specifies “technical and operational safeguards” that must be built into AI systems, not merely documented. Govern 1.1 calls for policies. Map 1.5 calls for technical controls that limit AI system behavior. The framework does not treat these as equivalent.

The EU AI Act is more explicit. Article 9, governing risk management systems for high-risk AI, requires “appropriate technical and organisational measures” to address identified risks. Article 16, on obligations for providers of high-risk AI systems, requires “technical measures” to ensure AI system behavior remains within specified limits during operation. Article 9(4) specifically requires that risk management measures “take into account the effects and possible interactions resulting from the combined application of the requirements.” That is a constraint-architecture requirement, not a policy requirement. You cannot satisfy it by documenting intended behavior.

The pattern across all four frameworks is the same: documentation requirements exist at one layer, and technical control requirements exist at another. Organizations that satisfy only the documentation requirements have completed the easier half of the compliance work. The harder half—building constraints that make violation architecturally impossible—is what the technical controls requirements are asking for.

A Production Hard Constraint Register

For reference, the 17 hard constraints operating in the production system over the 90-day pilot period are summarized below. Each entry lists the constraint, the enforcement layer, and the enforcement mechanism. The format illustrates what a hard constraint register looks like in practice—not as a policy document, but as a technical specification of architectural enforcement points.

The register is not a policy document. Each entry specifies the enforcement mechanism precisely enough that an engineer can verify it is operational without reading any additional documentation. Either the pre-commit hook exists and rejects the pattern, or it does not. Either the gate evaluation queries the correct data source and returns the correct state, or it does not. The constraint is either present at the architectural layer or it is absent. There is no intermediate state where the constraint exists but might not be enforced.

The Incident That Policies Cannot Prevent

Returning to the fabrication incident: a policy governing data integrity would have said something like “agents must report accurate metrics and must not use stale data in gate evaluations.” That policy was, in fact, in the constitutional document. It existed at the documentation layer, as an explicit prohibition with a cited section number.

The policy did not catch the incident. The incident was not caused by an agent that chose to use stale data. It was caused by a failure in the data pipeline that caused the database to return cached values without flagging them as cached. No agent reasoning was involved. No policy interpretation was relevant. The agent was calling the data correctly, and the data it received was silently wrong.

The hard constraint caught the incident. HC-11—the freshness timestamp requirement—was enforced at the gate input validation layer, not at the agent reasoning layer. The validation code checked the timestamp field on each metric record before passing the record to the gate evaluation. When the timestamp exceeded 48 hours, the validation returned a BLOCK state. The gate evaluation did not run. The agent logged the block and escalated.

This is the incident class that policies cannot prevent because the incident is not caused by a policy violation. The system was following its policies correctly. The system had a data integrity failure that a structural enforcement mechanism was designed to catch. The enforcement mechanism worked. The policy would not have.

What CIOs and CISOs Should Ask

The transition from policy-governed to constraint-governed AI is not a one-time project. It is an ongoing architectural discipline. Policies will always be necessary for the governance functions they perform: establishing intent, communicating expectations, creating audit trails, satisfying regulatory documentation requirements. The question is what exists alongside the policies to make compliance structurally enforced rather than behaviorally dependent.

Four questions surface the distinction in any AI governance evaluation:

What happens when an agent attempts an action that your policy prohibits? If the answer describes a monitoring alert, an audit log entry, or a review process that runs afterward, the governance is policy-layer. If the answer describes a gate evaluation that returns FAIL, a pre-commit hook that rejects the commit, or an execution path that requires human approval before proceeding, the governance is constraint-layer.

Can an agent reason its way around a constraint? Hard constraints have no context input for agent reasoning. They check a value against a threshold, or they check a pattern against a rule. They do not evaluate the agent's explanation for why the constraint should not apply. If the constraint evaluation involves agent-generated reasoning, it is a policy enforced by the agent—which is a policy, not a constraint.

Where is the constraint enforced in the execution sequence? Pre-commit hooks run before code enters the repository. Gate evaluations run before agent execution. Input validation runs before gate evaluation. Constraints enforced earlier in the sequence are harder constraints than those enforced later. A policy enforced at quarterly audit is later than everything.

What is the failure mode when the constraint mechanism breaks? Hard constraints are designed to fail closed: when the enforcement mechanism itself fails, the system blocks rather than permitting the action. A pre-commit hook that fails to run should block the commit, not allow it. A gate evaluation that cannot query its data source should return FREEZE, not proceed. If the constraint fails open—if a broken enforcement mechanism permits the action—the constraint is not hard.

Gartner’s prediction that 40% of agentic AI projects will be canceled cites “inadequate risk controls” as one of three causes. Risk controls that exist at the documentation layer are adequate for regulatory defense. They are not adequate for preventing the incident categories that cause project cancellation: silent failures, metric fabrication, agent drift, and spend decisions that look authorized because the authorization check is a policy, not a gate.