IARPG-OPS-2 · 2.0.4-wip Intelligence operations design system Fictional missions · neutral authorities
IARPG.COM INTELLIGENCE AGENT ROLE PLAYING GAME
Work in progress IARPG-OPS-2 2.0.4-wip

Global publication search

Search the operations design system

Type to search standards, missions, roles, authorities, reports, sources, schemas, and UAI memory.

JUR-01CurrentTasking & LogisticsPublished WIP

Evidence-Based Jurisdiction and Warrants

Severity and evidentiary certainty are separate axes; jurisdiction determines who can observe, investigate, restrict, pursue, or review.

Purpose

What this record standardizes.

Define trusted and untrusted tasking, deterministic handoffs, operational resources, jurisdiction, and support systems.

Rationale

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.

01
MUSTrequired for conformance

Track offense severity separately from evidentiary certainty.

02
MUSTrequired for conformance

Use anomaly, suspect file, confirmed warrant, and active manhunt as distinguishable case states.

03
MUSTrequired for conformance

Expose reason codes, jurisdiction, evidence basis, review path, and applicable restrictions.

04
SHOULDrecommended unless a documented reason applies

Fund bounty outcomes through fines, bonds, seized value, or capped budgets rather than unconstrained currency creation.

05
SHOULDrecommended unless a documented reason applies

Provide surrender, appeal, restitution, review, evasion, and lawful resolution paths.

06
MAYoptional supported behavior

Different jurisdictions recognize or contest the same case differently based on evidence and agreements.

Game interaction mapping

What players and interfaces do.

01Accept tasking
02Lock escrow
03Carry package
04Complete handoff
05Review warrant reason
CollectValidateDeliverDebrief

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.

FromEventTo
not-applicablerecord requirement evaluatedconforming-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.evidence-based-jurisdiction-and-warrants.evaluated

Required fields:

event_idtimestamp_utcmission_idrecord_coderesultreason_code

Abuse and exploit cases

What the implementation must anticipate.

  1. A participant attempts to omit required context so another role accepts a misleading task.
  2. A generated or user-authored statement is presented as server-authoritative without verification.
  3. A consequential state transition occurs without a durable reason code.

Failure and recovery

Fail-closed behavior and recovery path.

FAILURE

Fail closed for irreversible or settlement-bearing actions. Preserve the current state, show the missing requirement, and allow correction or documented exception review.

RECOVERY

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 JUR-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

Supporting research

Deep links into complete canonical reports.

Revision history

Published changes to this record.

1.0.02026-07-19 UTC

Initial IARPG-OPS-1 publication.

2.0.1-wip2026-07-19 UTC

Expanded for IARPG-OPS-2 workbench, simulation, evidence, accessibility, telemetry, and machine-readable publication.

2.0.2-wip2026-07-19T16:42:07Z UTC

2.0.3-wip2026-07-19T18:45:50Z UTC

Reviewed for integrity-aware package verification, merge, multi-role replay, custody comparison, batch review, backup, publication preview, and release-promotion workflows.

2.0.4-wip2026-07-20T12:04:07Z UTC

Reviewed for canonicalization, round-trip portability, recovery, provenance, compatibility, accessibility, hosting evidence, and stable-promotion gates.

Connected tools and standards

Explore the wider AI ecosystem.