Purpose
What this record standardizes.
Define trusted and untrusted tasking, deterministic handoffs, operational resources, jurisdiction, and support systems.
Operational logistics must expose risk, settlement, custody, and failure states before a player commits time or collateral.
Normative requirements
What conforming implementations must, should, and may do.
Label tasking as verified, authority-reviewed, reputation-backed, or unverified before acceptance.
Verified tasking lock reward terms and use deterministic completion or review rules.
Unverified tasking disclose that objective, reward, or sponsor claims may fail without engine settlement.
Expose issuer history, proof of interaction, dispute record, and relevant reputation without presenting them as infallible truth.
Unverified tasking offer higher potential reward or unique access to justify risk.
Game interaction mapping
What players and interfaces do.
Data contract
Inputs and outputs.
Inputs
- Task contract
- Cargo or intelligence packet
- Jurisdiction state
Outputs
- Settlement event
- Handoff record
- Warrant or clearance event
State contract
Allowed or expected transitions.
| From | Event | To |
|---|---|---|
| not-applicable | record requirement evaluated | conforming-or-documented-exception |
Evidence and provenance
Review requirements for claims and consequential state.
- The implementation records the source, UTC event time, mission identifier, responsible role, and reason code for consequential state changes.
- Generated dialogue and player interpretation are not stored as authoritative facts without a separate verification event.
User-interface requirements
How the requirement must appear at the point of use.
- Show the record code and requirement level at the point of use.
- Expose the reason for blocked, failed, escalated, or irreversible actions.
- Provide a direct link to the canonical standard and machine-readable record.
Accessibility requirements
Equivalent access to essential information and controls.
- Essential information is available without reliance on color, audio, motion, or a VR-only gesture.
- Keyboard, screen-reader, reduced-motion, seated-play, and high-contrast equivalents are documented where the interaction applies.
Telemetry events
Minimum event records for implementation review.
standard.verified-and-unverified-tasking.evaluated
Required fields:
Abuse and exploit cases
What the implementation must anticipate.
- A participant attempts to omit required context so another role accepts a misleading task.
- A generated or user-authored statement is presented as server-authoritative without verification.
- A consequential state transition occurs without a durable reason code.
Failure and recovery
Fail-closed behavior and recovery path.
Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.
Restore from the last authoritative event, retain the rejected transition in the audit log, and require a new validated event before continuing.
Example implementation
A concise fictional game implementation.
A mission interface evaluates TASK-01 before advancing the relevant state and writes the result to the local event log with a UTC timestamp and reason code.
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.
Initial IARPG-OPS-1 publication.
Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.
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.
