Purpose
What this record standardizes.
Define how players and synthetic characters gather information while preserving source class, access path, reliability, and collection limitations.
Collection is useful only when the game can explain where information came from and what the collector could actually observe.
Normative requirements
What conforming implementations must, should, and may do.
Every collection method declare what it can observe, what it cannot establish, and what exposure it creates.
Collection output identify source discipline and acquisition context.
Missions offer at least two plausible collection approaches when the environment supports them.
Collection disciplines conflict, requiring players to reconcile timing, identity, or attribution differences.
Game interaction mapping
What players and interfaces do.
Data contract
Inputs and outputs.
Inputs
- Collection requirement
- Source profile
- Access plan
Outputs
- Source report
- Observation
- Collection log
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.collection-discipline-selection.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 COLL-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.
