Turning Repeated AI Instructions into Tested Controls

Abstract

AI teams often respond to recurring mistakes by adding another sentence to a system prompt. That response is appropriate when the missing behaviour depends on interpretation, but wasteful and fragile when the requirement is stable, observable and mechanically decidable. This paper proposes a control ladder that separates four jobs: deterministic rules, validators, bounded model judgement and human acceptance. The design is informed by established practices in policy-as-code, input validation, provenance and AI risk management, together with a limited first-party prototype record. Its central claim is architectural rather than empirical: move a requirement down the ladder only when its inputs, decision rule and failure response can be specified without erasing material ambiguity. Test positive, negative, stale-source, mismatched-provenance and uncertain-input cases; record abstention rather than coercing every case into pass or fail. A passing validator establishes only the proposition it actually checked. It does not establish truth, authority, safety, semantic quality or successful deployment unless those properties were independently included in the contract. The accompanying application protocol provides a decision matrix, case table and clearly labelled pseudocode for converting repeated instructions into bounded, testable controls.

1. Research question and scope

When should a repeated AI instruction become a deterministic control, and what must remain a matter of bounded model judgement or human acceptance?

The question applies to agent workflows in which prompts accumulate statements such as “use only these files”, “preserve every identifier”, “do not act outside this task”, “return valid JSON”, or “verify the live result before claiming completion”. Some statements describe decidable properties. Others compress contextual judgement, authority or consequences that cannot safely be inferred from syntax.

This paper addresses control placement, not prompt-writing style in general. It does not argue that prompts are obsolete, that all policy can be encoded, or that deterministic software makes a probabilistic system reliable by itself. It also does not claim a new theory of software testing. The contribution is a practical decision boundary for AI workflows: which recurring requirements should become executable checks, which require model interpretation, and which must remain with an accountable human or governing parent process.

2. Why repeated prose becomes a control problem

A prompt is useful for describing goals, context and trade-offs. It is a poor place to repeatedly recompute a rule whose inputs and expected result are already known. If an output must contain exactly five fields, if a source hash must equal the inspected hash, or if a requested path must remain inside an allowed directory, asking a model to “remember” the rule on every run adds a probabilistic decision where a direct comparison is available.

The converse is equally important. “Is this evidence sufficient?”, “does this action remain authorised?”, and “is this public explanation misleading?” are not reduced to mechanical truth merely because a schema can represent their answers. Encoding an ambiguous decision too early can hide uncertainty behind a crisp boolean.

This yields two distinct failure modes:

1. Instruction inflation: stable checks remain prose, so each model invocation must interpret them again. Failures invite more prose, increasing context and interaction effects without creating an enforceable boundary.
2. Premature compilation: a team turns an incomplete policy into a validator. The validator becomes consistent, but consistently checks the wrong surrogate.

The remedy is not “more code” or “better prompting”. It is disciplined allocation of each requirement to the lowest control layer that can represent it faithfully.

3. Related practices and what they establish

The proposal draws on four established practices without treating any one of them as a complete solution for agent governance.

First, NIST SP 800-53 defines information input validation as checking the validity of organisation-defined inputs and places controls inside a broader risk-management catalogue [1]. This supports a basic distinction: known input properties can be checked at a system boundary. The catalogue does not tell an AI team which semantic judgements are safe to reduce to those properties.

Second, Open Policy Agent demonstrates policy-as-code with executable positive and negative cases. Its documentation shows allowed and denied examples, reports pass, fail and error separately, supports data-driven tests and warns that an empty test selection can otherwise succeed unless the caller requests failure on empty [2]. The last point is unusually instructive for AI assurance: a green process is not proof that the intended checks ran.

Third, SLSA provenance describes verifiable information about where, when and how a software artifact was produced. It requires external build parameters to be recorded and verified downstream and identifies output artifacts as subjects [3]. Provenance can therefore bind a check to an exact input or artifact. It does not establish that the artifact is correct for its business purpose, that its source was truthful, or that the actor possessed authority to release it.

Fourth, the NIST Generative AI Profile recommends risk management across governance, mapping, measurement and management, with specific attention to pre-deployment testing, content provenance and human as well as automated evaluation [4]. This supports a layered approach rather than a single universal gate. The profile is voluntary guidance, not validation of the architecture proposed here.

A limited first-party implementation record supplies a concrete but narrow engineering example. A task packet was rejected before output allocation when its source contract failed, then a corrected packet completed through a registered worker route. Positive and negative vectors, focused tests, private checks and rollback were recorded [5]. That demonstrates one scoped control path. It does not establish universal reliability, protection of every entry point, financial benefit or independent security assurance.

4. The four-layer control ladder

4.1 Deterministic rule

A deterministic rule computes the same result from the same declared inputs. Appropriate examples include:

• required-field and type checks;
• exact identifier preservation;
• allowed path or domain membership;
• hash equality against an inspected artifact;
• count conservation and duplicate detection;
• timestamps compared with explicit expiry values;
• enumerated state-transition legality.

A rule belongs here only if its input boundary is explicit and the predicate is materially complete. “File hash equals H” is decidable. “This is the right file” is not, unless a separate trusted process established what H denotes.

4.2 Validator

A validator combines rules into a named contract and emits structured evidence: what was checked, against which input, with which version, and with what result. It should distinguish at least pass, fail, error and not_evaluated. Where uncertainty can be detected but not resolved, add abstain or route the case upward.

A validator is more than a parser. It needs:

• a versioned contract;
• exact input identity;
• positive and negative test cases;
• stale and mismatched-source cases;
• failure-before-side-effect ordering;
• machine-readable output;
• a rollback or safe-stop path;
• evidence that the intended test set actually ran.

The validator should fail closed only for properties it legitimately governs. A formatting failure may block ingestion. It should not silently become a universal veto over a human decision outside its scope.

4.3 Bounded model judgement

Some requirements are semantic but still bounded enough for model assistance: classifying a passage against a rubric, identifying likely conflicts, mapping a claim to cited evidence, or proposing which control layer fits a requirement. The model should receive a constrained packet with source excerpts, permitted outputs, an uncertainty option and a verification rule.

Model judgement is useful when exhaustive deterministic specification would cost more than the task or when meaning depends on language and context. It should not be represented as deterministic. Its output is a candidate judgement with provenance, confidence or reasons, not the final truth.

4.4 Human or governing-parent acceptance

Acceptance remains necessary where consequences, authority, strategic trade-offs or expensive-to-verify claims are material. The accepting actor determines whether the evidence satisfies the actual purpose—not merely whether a subordinate check returned green. Examples include publication, consequential external action, changing an authority grant, accepting residual safety risk, or declaring a business outcome complete.

This layer should not redo every mechanical check manually. It should consume validator receipts and model analysis while retaining the decision that those artifacts cannot make.

5. A decision boundary for compiling instructions

A repeated instruction is a candidate for compilation when all five conditions hold:

1. Stability: the rule recurs and changes less often than the workflow invoking it.
2. Observability: the required inputs are available before the governed side effect.
3. Decidability: compliant and non-compliant cases can be distinguished without hidden contextual judgement.
4. Consequence fit: false acceptance and false rejection are understood well enough to choose the response.
5. Testability: representative positive, negative and boundary cases can be exercised.

If stability fails, keep the requirement in a versioned task contract. If observability fails, instrument the workflow before pretending to enforce it. If decidability fails, use bounded model judgement or human review. If consequence fit is unknown, abstain and escalate. If testability fails, the alleged control is still a statement of intent.

The safest movement is downward only after evidence. A requirement may begin as human review, become a model-assisted rubric, then acquire deterministic subchecks. It should not move downward merely because a boolean would be convenient.

6. Test the control, not only the happy path

A control suite needs cases that challenge its assumptions.

• Positive: valid input produces the permitted result.
• Negative: a known prohibited input is rejected before side effects.
• Stale source: a previously valid source or contract is superseded; the validator must not accept it as current.
• Mismatched provenance: the artifact is valid in isolation but does not match the inspected source, declared builder or requested task.
• Uncertain input: required context is absent or contradictory; the system must abstain or escalate rather than manufacture certainty.
• Empty execution: no intended tests run; the suite must not report success.
• Bypass: an alternative entry point attempts to avoid the control.
• Rollback: a candidate that passes local checks but fails integration can be removed without corrupting the accepted state.

Measure false acceptance and false rejection against a labelled case set. Also record errors, abstentions, bypass attempts and side effects that occurred before rejection. Accuracy alone can conceal a dangerous asymmetry: a rare false acceptance may matter far more than frequent benign escalations.

Tests should include mutations of both input and control. Change one required field, hash, source version, scope boundary or state transition and confirm that the expected case turns red. A control that has never been observed to fail can be correctly implemented—or irrelevant, bypassed or never executed.

7. Receipts and the proposition boundary

Every control result should be read as a proposition with explicit limits.

receipt = {
  contract_id,
  contract_version,
  input_identity,
  checks_executed,
  result,
  reasons,
  control_version,
  evaluated_at,
  side_effects_before_result
}

If the receipt says that a candidate file's digest matches the reviewed digest, the established proposition is identity of bytes under the stated hash function. It does not establish semantic correctness, authorship, freshness, authority, deployment or recipient experience. Those require different evidence.

This proposition boundary prevents “validation laundering”: the practice of presenting one narrow green check as if it certified the whole outcome. Control composition is valid only when each receipt's conclusion matches the premise needed by the next stage.

8. Alternatives and trade-offs

Keeping all guidance in prompts is flexible and fast to change. It remains appropriate for low-consequence exploratory work and context-rich judgement. Its weakness is that compliance is probabilistic and difficult to audit at a granular level.

Encoding all policy in deterministic code maximises repeatability but can fossilise incomplete assumptions. It is costly when semantics change frequently and dangerous when proxy variables replace the intended property.

Using a second model as a judge can improve semantic coverage, but correlated training, shared blind spots and prompt sensitivity make it an additional evidence source rather than an independent ground truth. Model judges also incur cost and can create a regress in which another model must judge the judge.

Human review handles context and accountability but is slow, variable and vulnerable to fatigue. The control ladder is intended to reserve human attention for the decisions that genuinely need it, not to eliminate it.

9. Practical application

The accompanying protocol turns a repeated instruction into a control candidate in seven steps: inventory the instruction; state the exact proposition; classify its layer; define inputs and side-effect boundary; write adversarial cases; implement the smallest faithful check; and require an acceptance receipt appropriate to consequence.

Consider “Use only inspected source files.” A faithful deterministic subcheck can compare the declared file paths and hashes with an approved manifest before any worker output directory is allocated. A stale manifest, extra path or hash mismatch should reject. But deciding whether the manifest contains sufficient evidence for the task remains a semantic review, and deciding whether the final work is acceptable remains with the accountable parent or human.

The distinction is operationally useful: code enforces membership and identity; model judgement can assess relevance; acceptance determines sufficiency and consequence.

10. Limitations and evaluation agenda

This paper proposes an architecture; it does not report a comparative field trial. The first-party record is narrow, non-independent and limited to one implementation route. The external sources establish related practices, not the effectiveness of this exact ladder.

Deterministic controls can contain defects, depend on compromised inputs or become stale. Hashes identify bytes but not meaning. Test sets can omit important cases. Human acceptance can be inconsistent, and model-assisted review can share failure modes with the system under review. Control maintenance also has cost; a rarely used low-consequence instruction may be cheaper to leave as prose.

A useful evaluation would compare prompt-only, layered-control and over-compiled variants on matched tasks. It should record false acceptance, false rejection, abstention, bypass rate, time to accepted outcome, maintenance effort, model usage and consequential failures. Trials should include changed policies and stale sources, not only static happy paths. Until such evidence exists, the framework should be treated as a testable design proposal.

11. Conclusion

Repeated instructions are signals, not automatic candidates for code. The right question is whether the underlying proposition is stable, observable, decidable, consequence-aware and testable. When it is, deterministic rules and validators can remove avoidable probabilistic work. When it is not, forcing the decision into a schema makes uncertainty less visible rather than less real.

Reliable AI workflows therefore need a ladder, not a single gate: deterministic checks for mechanical facts, validators for contract evidence, bounded models for semantic assistance, and accountable humans or governing parents for authority and acceptance. The value lies as much in what each layer refuses to claim as in what it can prove.

References

1. Joint Task Force. Security and Privacy Controls for Information Systems and Organizations. NIST Special Publication 800-53 Revision 5, September 2020. https://doi.org/10.6028/NIST.SP.800-53r5
2. Open Policy Agent. Policy Testing. Undated. https://www.openpolicyagent.org/docs/policy-testing
3. Supply-chain Levels for Software Artifacts. Provenance, Specification v1.0. Undated. https://slsa.dev/spec/v1.0/provenance
4. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, July 2024. https://doi.org/10.6028/NIST.AI.600-1
5. Nordlith. Scoped implementation-path prototype acceptance record. 18 October 2026. First-party internal engineering record; operational identities and endpoints withheld.