NORDLITH RESEARCH

From Repeated Instruction to Tested Control: Application Protocol

Practical companion protocol. Examples and proposed controls retain their stated evidence limits.

Read the research paper · Browse all research

Contents
  1. 1. Instruction-to-control worksheet
  2. 2. Layer decision matrix
  3. 3. Minimum case set
  4. 4. Illustrative pseudocode — not executed or released code
  5. 5. Worked classification examples
  6. 6. Receipt template
  7. 7. Release checklist

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, abstain and not_evaluated are 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.

Continue reading