● WORKING THOUGHT EXPERIMENT / NOVEMBER 2026

Creating reliable systems
with imperfect models.

What should an agent establish before its work is allowed to run? This thought experiment asks how requirements, evidence, and authority can travel together across software tools.

RICK LOPEZ / SOFTWARE ENGINEERING

Read the paper →Download PDF ↓

Markdown source

SPECIFICATION WALKTHROUGH

Follow a change to release.

See how an agent turns a request into an obligation, discovers a change, and checks whether the evidence supports release.

Identifier key · D1, K3, E3…

Read the prefix as the record type. The suffix identifies a particular record or revision in this example. Uppercase R denotes a report and lowercase r denotes a code revision.

D1 Definition: What the retrieval operation is intended to do.
O-account Obligation: The accepted requirement to isolate records by account.
K3 Execution package: The candidate submitted for admission.
r2, r3 Implementation revisions: The code before and after the repair.
E3 Evidence: The check results bound to K3 and revision r3.
P1 Policy: The rules the gate applies when deciding admission.
R2 Discovery report: The observed change to the retrieval path.
M2 Impact assertion: The claim that R2 may affect O-account.
C-account Check: The test that exercises the account-isolation requirement.

A definition records the intended behavior. A change opens an assessment. The gate admits a candidate when its evidence applies to that revision.

02 / THE ARGUMENT

What survives the handoff?

A test can pass against one revision while a different revision goes to production. The paper proposes four relationships that make that mistake visible. An obligation has an authority. An implementation claims to satisfy it. Evidence identifies what was examined. A decision determines which transition that evidence supports.

03 / SPECIMENS

Inspect the samples

Follow one account-isolation obligation from definition to admission. These files illustrate candidate syntax for the proposed specification.

finalized-reports.prompt

definition_id: D1
operation: finalized_service_reports
contract_version: 1
profile: bounded-read-operation/proposed-1

intent:
  source: requester_statement
  text: "Get the latest service reports from our provider."

commitments:
  account_scope:
    obligation_id: O-account
    value: designated_account
    origin: requester_confirmed
  selection:
    obligation_id: O-selection
    status: finalized
    order: publication_timestamp_descending
    maximum_count: 10
    origin: accepted_interpretation
  excluded_effects:
    - publish_record
    - edit_record
    - delete_record

output:
  required_fields:
    - source_id
    - title
    - publication_timestamp
    - source_link
    - retrieved_at
  completeness:
    modes: [bounded_latest_set, partial]
    partial_requires: missing_scope_and_reason

execution:
  required_capabilities:
    - scoped_browser_session
    - durable_run_state
    - account_identity_check
    - result_provenance
  authentication:
    challenge: await_authorized_account_owner
    reuse: permitted_while_session_valid
  unexpected_page: stop_and_report
  repair: create_new_candidate

acceptance:
  requires:
    - account_matches_contract
    - records_are_finalized
    - required_fields_present
    - source_links_match_collected_records
    - ordering_matches_contract
    - completeness_mode_supported_by_evidence

Download sample ↓

SKILL.md

---
name: finalized-report-reader
description: Retrieve finalized reports within one account.
---
# Finalized report reader

Resolve definition D1 and the run's granted capabilities before acting.
Confirm the designated account before reading each page.
Collect finalized reports in publication order, preserving source links.
If account identity or finalization is uncertain, report the unresolved
condition. Do not infer permission to edit provider records.
Return observations and provenance; do not declare release acceptance.

Download sample ↓

package.yaml

package_id: K3
implementation: r3
definition: D1
entrypoint: SKILL.md
profile: bounded-read-operation/proposed-1
requires:
  - scoped_browser_session
  - account_identity_check
  - result_provenance
requested_effects: [read_report_listing]
checks: [C-account, C-selection]
execution_assumptions:
  model: reader-model@1
  harness: reader-harness@1
admission_policy: P1

Download sample ↓

selection.check.yaml

check_id: C-selection
definition: D1
obligation: O-selection
method: decision_model
evaluator: review-model@1
rubric_version: finalization-rubric@1
inputs: [record_snapshot, source_status, source_link]
question: >
  Does the supplied source evidence establish that this
  record is finalized under D1's accepted selection rule?
result:
  verdict: [satisfies, violates, unresolved]
  required: [verdict, reason, evidence_refs]
scope: supplied_record_snapshot_only
on_missing_evidence: unresolved

Download sample ↓

selection.fixtures.yaml

suite: selection-check-fixtures@1
check: C-selection
oracle_authority: evaluation-policy-owner
cases:
  - id: explicit-draft
    source_status: "Draft - pending review"
    expected: violates
  - id: absent-status
    source_status: null
    expected: unresolved
# Expected labels are approved independently of model outputs.

Download sample ↓

discovery-and-evidence.yaml

report: R2
baseline: r1
candidate: r2
method: dependency_analysis
impact:
  id: M2
  obligation: O-account
  basis: [retrieval-to-paginate, retrieval-to-O-account]
  unresolved: [runtime-adapter-target]

evidence:
  id: E3
  package: K3
  implementation: r3
  definition: D1
  context: X1
  checks: [C-account, C-selection]
  result_refs: [account-check-run-3, selection-check-run-3]

Download sample ↓

admission.yaml

policy: P1
candidate: K3
definition: D1
context: X1
requires:
  - bindings_match_candidate
  - required_capabilities_granted
  - deterministic_account_check_satisfied
  - required_obligation_assessments_accepted
  - consequential_mappings_resolved_or_fallback_completed
on_unresolved: block_admission
model_verdict_alone_authorizes_release: false

Download sample ↓

04 / RESEARCH LOG

Work in progress

March 2026

LLMs Are the Runtime

The original paper treated the model as a runtime and the prompt as source code. It proposed compiling a .prompt file into an intermediate representation and an execution plan for a particular model.

November 2026