Purpose
What this record standardizes.
Compares two decision branches from the same mission, starting state, evidence packet, authority, role allocation, and visible seed.
The operations design system requires portable, inspectable, recoverable records so mission decisions and consequences can be reviewed across tools and release boundaries.
Normative requirements
What conforming implementations must, should, and may do.
Use the same normalized starting package and deterministic seed for both compared branches.
Explain every divergent state transition, meter change, evidence outcome, extraction state, and debrief conclusion.
Produce a normalized JSON comparison artifact and accessible nonvisual difference table.
Allow a designer to replay either branch inside the simulator.
Game interaction mapping
What players and interfaces do.
Data contract
Inputs and outputs.
Inputs
- Mission or package identifier
- Applicable authority and roles
- Evidence and state records
- Release and conformance metadata
Outputs
- Human-readable publication view
- Machine-readable JSON
- Reason-coded validation findings
- Deep links to related standards and reports
State contract
Allowed or expected transitions.
| From | Event | To |
|---|---|---|
Evidence and provenance
Review requirements for claims and consequential state.
- Record UTC timestamps, source identifiers, component versions, and reason codes.
- Preserve evidence class boundaries and unknown extension data.
User-interface requirements
How the requirement must appear at the point of use.
- Provide compact metadata and clear status.
- Provide local import and export without server transmission.
- Provide structured fallback for visual representations.
Accessibility requirements
Equivalent access to essential information and controls.
- Support keyboard operation and visible focus.
- Provide live validation status and print-readable output.
Telemetry events
Minimum event records for implementation review.
Required fields:
Abuse and exploit cases
What the implementation must anticipate.
- Silent field loss
- Non-deterministic replay
- False conformance claim
- Unreviewable transformation
Failure and recovery
Fail-closed behavior and recovery path.
Reject invalid structure with explicit findings, preserve the original input, and never discard unknown fields silently.
Allow the user to repair input, restore a local draft, export preserved unmapped data, or restart from a published fixture.
Example implementation
A concise fictional game implementation.
The /compare interface demonstrates this record using PHP, vanilla JavaScript, local JSON, and browser APIs.
Open complete mission examples →Related records and examples
Continue through the operating model.
Supporting research
Deep links into complete canonical reports.
Revision history
Published changes to this record.
Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.
Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.
