Developer reference

OIM Core API draft.

This first-pass documentation presents the intended contract shape. Keep the API small, deterministic, versioned, and boring.

Endpoint

POST /oim/evaluate
Authorization: Bearer <token>
Content-Type: application/json

Request packet

{
  "packet_id": "decision-001",
  "metadata": {
    "timestamp_iso8601": "2026-05-20T14:00:00Z",
    "submitter": "system-or-actor-reference",
    "version": "1.0"
  },
  "declared_options": [
    { "description": "Proceed" },
    { "description": "Do not proceed" }
  ],
  "declared_assumptions": [
    { "statement": "Required review is current" }
  ],
  "declared_invalidation_conditions": [
    { "condition": "Review window expires" }
  ],
  "advisory_signals": [
    {
      "signal_id": "sig-001",
      "human_response": {
        "justification": "Reviewed by accountable authority"
      }
    }
  ]
}

Response artifact

{
  "packet_id": "decision-001",
  "packet_fingerprint": "sha256:...",
  "oim_core_version": "oim_core_v1_1",
  "outcome": "STRUCTURALLY_VALID",
  "error_count": 0,
  "errors": [],
  "conditions_checked": [
    "packet_id_present",
    "metadata_present",
    "options_sufficient",
    "assumptions_present",
    "declared_invalidation_conditions_present",
    "signals_acknowledged"
  ]
}

Naming rule

Prefer STRUCTURALLY_VALID / STRUCTURALLY_INSUFFICIENT over PERMIT / REFUSE in external materials. This prevents buyers from confusing structural admissibility with execution authorization.