From Repeated Instruction to Tested Control: Application Protocol
Practical companion protocol. Examples and proposed controls retain their stated evidence limits.
Contents
Status: proposed reusable protocol; not independently validated
Purpose: decide whether a recurring instruction belongs in deterministic code, a validator, bounded model judgement or human acceptance.
1. Instruction-to-control worksheet
For each recurring instruction, complete every row before implementation.
| Field | Required entry |
|---|---|
| Instruction | Exact current wording |
| Intended proposition | One sentence describing what must be true |
| Trigger | Event before which the proposition matters |
| Inputs | Exact fields, artifacts and trusted origins |
| Side-effect boundary | First write, message, deployment or allocation that must not occur before admission |
| Change frequency | Per task / weekly / rarely / legally governed |
| False-acceptance consequence | What happens if bad input passes? |
| False-rejection consequence | What happens if good input is blocked? |
| Uncertainty signal | Missing, stale, contradictory or untrusted input |
| Control owner | Who maintains the rule and test cases? |
| Acceptance owner | Who decides the final outcome? |
2. Layer decision matrix
| Question | If yes | If no |
|---|---|---|
| Is the proposition stable across repeated tasks? | Continue | Keep in versioned task instructions |
| Are all necessary inputs observable before side effects? | Continue | Instrument or escalate; do not claim enforcement |
| Can two competent reviewers derive the same result from those inputs without contextual judgement? | Consider deterministic rule | Use bounded model or human judgement |
| Can positive, negative and boundary cases be enumerated? | Build a validator around the rule | Retain higher-layer review |
| Is uncertainty detectable? | Add abstain/not_evaluated |
Do not force a boolean |
| Does the decision alter authority, publish externally or accept material risk? | Require human/governing-parent acceptance | Validator receipt may be sufficient for its narrow proposition |
3. Minimum case set
Create at least these cases before calling a control implemented:
| Case | Mutation | Expected result |
|---|---|---|
| Positive | Exact valid packet | pass |
| Negative | One prohibited field/value | fail before side effect |
| Stale source | Valid but superseded source version | fail or abstain |
| Provenance mismatch | Artifact hash/source differs from manifest | fail |
| Uncertain | Required context absent or contradictory | abstain/escalate |
| Empty execution | No intended tests selected | error, never pass |
| Bypass | Alternative entry point skips validator | blocked or explicitly reported as ungoverned |
| Rollback | Integration fails after local pass | accepted state restored |
Record false acceptance, false rejection, errors, abstentions, and whether any governed side effect occurred before the result.
4. Illustrative pseudocode — not executed or released code
function admit(packet, contract, approved_manifest):
if contract is missing or contract.version is stale:
return ABSTAIN("current contract unavailable")
if packet.target outside contract.allowed_targets:
return FAIL("target outside scope")
if packet.source_paths != approved_manifest.paths:
return FAIL("source set mismatch")
for source in packet.source_paths:
if sha256(source.bytes) != approved_manifest.sha256[source]:
return FAIL("source identity mismatch")
if packet.required_fields are missing:
return FAIL("typed contract incomplete")
return PASS({
proposition: "packet matches the declared scope and inspected source identities",
does_not_establish: [
"source truth",
"semantic sufficiency",
"authority to publish",
"final outcome acceptance"
]
})
The check must run before worker output allocation or another consequential side effect. The hash comparison binds bytes; it does not prove that the source is correct, current in the world, or sufficient for the task.
5. Worked classification examples
Example A — “Return exactly the required record fields”
- Deterministic: schema, types, required/forbidden fields.
- Validator: run schema plus semantic invariants; fail on no tests.
- Model judgement: assess whether free-text rationale answers the question.
- Acceptance: decide whether the record is adequate for consequential use.
Example B — “Use only inspected sources”
- Deterministic: path allow-list, immutable identifier and digest equality.
- Validator: stale-manifest and extra-source cases; reject before allocation.
- Model judgement: assess relevance and contradiction among allowed sources.
- Acceptance: determine whether evidence is sufficient to make the claim.
Example C — “Do not exceed your authority”
- Deterministic: action, account, resource, time and side-effect class are members of an explicit grant.
- Validator: expiry, revocation, negative permissions and ambiguous target cases.
- Model judgement: interpret a task description into a candidate action class.
- Acceptance: a human or governing authority creates or changes the grant. Credentials and technical capability do not create permission.
6. Receipt template
{
"contract_id": "string",
"contract_version": "string",
"input_identity": [{"name": "string", "sha256": "hex"}],
"checks_executed": ["positive", "negative", "stale", "mismatch", "uncertain"],
"result": "pass|fail|error|abstain|not_evaluated",
"reasons": ["string"],
"control_version": "string",
"side_effects_before_result": [],
"proposition_established": "string",
"properties_not_established": ["string"],
"acceptance_owner": "role"
}
7. Release checklist
- [ ] The repeated instruction is quoted exactly.
- [ ] Its intended proposition is narrower than the surrounding goal.
- [ ] The control runs before the governed side effect.
- [ ] Input identity and contract version are recorded.
- [ ] Positive and negative cases both exist.
- [ ] Stale, mismatched and uncertain cases exist.
- [ ] Empty test execution cannot report success.
- [ ]
fail,error,abstainandnot_evaluatedare distinct. - [ ] A bypass path was sought.
- [ ] Rollback or safe stop was exercised where applicable.
- [ ] The receipt states what the check does not establish.
- [ ] Authority and final acceptance remain with the named owner.
