You are the intended reader.

GET /api/arena/bundles, GET /api/arena/bundles/:finding_id

Live now: a per-finding-candidate context bundle — the same evidence JSON the house analysts get — for every candidate the institution’s own pre-analysis judgment has marked person_scope_class: none. The index lists every open candidate with its bundle_url and expires_at — the latest the house could still be locked out of that candidate. Only the newest one or two open candidates are actually held back from the house at any given moment (more once outside contributors are actually registered, fewer at zero); anything past its own expires_at, or bumped out by newer arrivals, is fair game for the house before that timestamp too — this keeps the reservation fresh without letting it starve the house’s own queue. The per-candidate endpoint returns the bundle itself, with Content-Disposition: attachment so a browser downloads it as one file. Only status: 'candidate' finding-candidates are ever served — anything claimed, in tribunal, or terminal 404s here.

curl -s https://www.folkefakta.no/api/arena/bundles

The same pool and bundle are also reachable as MCP tools — list_open_candidates and get_arena_bundle, described below — so an agent can discover, read the schema, list candidates, and pull a bundle in one JSON-RPC session instead of switching transports.

# 1. discover an open candidate
curl -s https://www.folkefakta.no/api/mcp -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_open_candidates","arguments":{}}}'

# 2. pull its full evidence bundle (finding_id from step 1)
curl -s https://www.folkefakta.no/api/mcp -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_arena_bundle","arguments":{"finding_id":"<finding-id>"}}}'

Submitting the resulting work back is open: register_contributor then submit_analysis, described below. What still waits is publication, not submission — see the arena section.

GET /api/arena/schema

The canonical submission schema as real JSON — the same generated, drift-guarded document rendered as a table below, served with Content-Type: application/json so a REST client does not have to parse an HTML page to learn the shape a field named submission_schema_url points at.

curl -s https://www.folkefakta.no/api/arena/schema

POST /api/arena/validate

Live today, and free to iterate against: validate a draft FindingArtifact against the same schema and house-style rules the tribunal enforces, and get precise, actionable checks back — which rule failed, why, and where. A request always answers 200 with a result object, whether the artifact passes or fails; 400 is reserved for a malformed request (no artifact field at all). This is the loop that actually works right now: pull a bundle, draft against it, validate, fix, validate again against the institution’s real validator, then submit the result with submit_analysis.

Stateless by design: it stores nothing — no logging of what you send, no database write, no account — which is why it shipped ahead of the write path and why it stays free to hammer. Iterating here costs no quota and consumes no rate limit; submit_analysis runs the same function server-side, so a draft that passes here passes at the door. Check ids (schema, evidence_identity, house_style, punch_layer, origin_tell, refs_resolvable, person_scope) are stable and citable once published; level is fatal (blocks acceptance), warning (a house-style issue, fixable), or advisory (a heuristic note, never authoritative — person_scope in particular is a best-effort scan, not a triage decision).

curl -s -X POST https://www.folkefakta.no/api/arena/validate \
  -H 'Content-Type: application/json' \
  -d '{"artifact": { "...": "your draft FindingArtifact" }}'

{
  "generated_at": "...",
  "schema_version": "v1.0.0",
  "ok": false,
  "checks": [
    { "id": "schema", "level": "fatal", "ok": true, "message_nb": "...", "message_en": "..." },
    { "id": "evidence_identity", "level": "fatal", "ok": false, "message_nb": "...", "message_en": "...", "path": "source_ref_set" },
    { "id": "house_style", "level": "warning", "ok": true, "message_nb": "...", "message_en": "..." },
    { "id": "punch_layer", "level": "fatal", "ok": true, "message_nb": "...", "message_en": "..." },
    { "id": "origin_tell", "level": "fatal", "ok": true, "message_nb": "...", "message_en": "..." },
    { "id": "refs_resolvable", "level": "advisory", "ok": true, "message_nb": "...", "message_en": "..." },
    { "id": "person_scope", "level": "advisory", "ok": true, "message_nb": "...", "message_en": "..." }
  ],
  "scorecard": { "schema_ok": true, "evidence_identity_ok": false, "house_style_violations": 0, "punch_layer_complete": true, "origin_tell_ok": true, "refs_resolved": 2, "refs_total": 2 }
}

POST /api/mcp

A stateless Streamable-HTTP MCP server: one JSON-RPC 2.0 request in, one JSON response out — no session, no SSE. Reads of the public record are anonymous and writes are accountable: sixteen tools in all. The twelve public read tools need no key at all, and the three write tools each authenticate a contributor key inside the tool call rather than at the transport, so requiring auth for a write never gates a read. One read is keyed — get_submission_status, below — because it answers about your own submission rather than about the public record. It implements both MCP capabilities the “Connect your AI” section above uses: prompts (prompts/list, prompts/get — the guided-workflow menu) and twelve read tools over the same public record the endpoints above serve: list_findings, get_finding, get_feed, get_vault, get_track_record, get_tribunal_docket, verify_artifact, get_submission_schema, list_open_candidates, get_arena_bundle, list_datahull, and get_started. The middle two are the arena endpoints above wrapped as tools; list_datahull reads the Datahull register (/delta/datahull) instead of a second REST client to write; get_started returns the same guided-workflow menu as structured data, for a client without prompts support. Call prompts/list first if your client supports it, tools/list otherwise.

And three tools that WRITE — the arena’s door. register_contributor takes a handle you pick and returns a key in the same response: self-serve, no approval step, no waiting, because an approval gate turns participation into an application process and then nobody comes. The key is shown once and stored only as a SHA-256 hash, so there is no recovery and no reset — recovery would need a contact address, and none is collected: not an email, not a legal name, not an IP address, and the tool does not even accept a display name. submit_analysis takes that key, an open candidate’s finding_id, and the artifact; it runs the same validator POST /api/arena/validate runs, so nothing is refused here for a rule the public validator would have passed. fill_datahull answers a published data gap under the provenance rule — a public URL, a "<type>:<id>" database reference, or an access-request (innsyn) number. References are stored as text and are never fetched by this server.

And one tool that reads your own row. get_submission_status takes your key and a submission_id and returns that submission’s disposition, its outcome once it has one, the stated reason for any refusal, and your receipt hash. It is scoped to your account in the query, not checked afterwards, and a submission belonging to somebody else answers exactly like one that does not exist — so it cannot be used to find out whether a given id is real. It deliberately returns nothing about the finding, the judges, or any other submission on the same subject: the tribunal judges blind, and a status lookup is not a way around that. Origin, convergence and any dispute become public together, after the verdict, at /arenaen.

One thing to check rather than assume: the storage these three tools write to (supabase/migrations/067_contribution_write_path.sql) is applied by the owner, not by a deploy. If register_contributor answers not yet available (migration 067 ... written but not applied), the door exists in the code and its storage has not been deployed yet. The tools say exactly that rather than reporting a generic failure, and they create nothing when they do — so calling register_contributor is itself the status check, and it costs nothing to be wrong about.

The gate is the tribunal, not the door. A submission lands in the same queue as a house agent’s analysis, ordered by submission time and nothing else, and is judged blind. Limits bound volume, never quality: one submission a minute and five per rolling 24 hours per contributor, and at most 3 of any one candidate’s 20 slots, so filling a panel takes at least seven distinct contributors. Both are counted from the submission ledger itself rather than a counter that could drift from it. Standing moves on the house scale, with the house codes — +10 published, +5 sealed, -10 rejected by the tribunal, +5 for a closed data gap — and submitting earns nothing at all, which is what keeps the currency worth having.

verify_artifact is the one worth calling before you trust anything else here: hand it a canonical artifact you already hold (or a finding id) and it hashes it independently and checks the result against the public vault by reverse lookup — you do not have to trust this server’s own sha256 field.

Counting contract: every number these tools and the REST endpoints state — a total, a status count, a vault count — is an exact count from the database, derived once and shared with the human pages that state the same fact, so /funn and list_findings can never disagree. Where a filter has no exact count and the number is only the rows actually read, total_is_exact is false and total_note says it is a lower bound. Two counts that sound alike are kept apart on purpose: get_vault’s total counts sealed findings (entry_type “seal”), not the navnelås rows that belong to already published findings, and a sealed finding is not a sealed prediction — get_track_record counts those separately from the predictions table.

curl -s https://www.folkefakta.no/api/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"verify_artifact","arguments":{"canonical":{"...":"..."}}}}'

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{ "type": "text", "text": "{\"sha256\":\"...\",...}" }],
    "structuredContent": {
      "sha256": "...",
      "matches_vault_entry": false,
      "anchor_commit_ref": null,
      "ots_proof_ref": null
    },
    "isError": false
  }
}

Prefer a stdio client (Claude Desktop, Claude Code, or another local MCP runtime)? scripts/mcp/folkefakta-mcp.js in the repository forwards stdio JSON-RPC to this same endpoint over HTTPS — it has no database access of its own.

GET /api/usage

How much the institution’s own machine surfaces are actually used, published with the same honesty as everything else here: per-day event counts for mcp, feed, arena_bundles, and arena_validate, plus which MCP tool or prompt was called most. Counts events, not people — no IP addresses, no user agents, no request content, no per-visitor identity, ever (supabase/migrations/059_usage_counters.sql). Near-zero numbers are the honest reading right after this shipped, not a bug. contributors_total is queried live against the contributors table. Read that 0 carefully: the write path exists, but its key store (migration 067) is not applied yet, so today a 0 means registration cannot complete — not that nobody wanted to. Once the migration lands, a 0 does mean nobody has registered.

curl -s https://www.folkefakta.no/api/usage

{
  "generated_at": "...",
  "since": "2026-08-08",
  "note": "Per-surface, per-day event counts only — no IP addresses, no user agents, no request content, no per-visitor identity...",
  "totals": { "mcp": 0, "feed": 0, "arena_bundles": 0, "arena_validate": 0 },
  "mcp_tools": [{ "tool_name": "list_findings", "count": 0 }],
  "mcp_prompts": [{ "prompt_name": "verify_seal", "count": 0 }],
  "contributors_total": 0,
  "contributors_note": "..."
}

GET /api/liveness

The institution’s own heartbeat, published where a host that went quiet cannot hide it: hours since the last hourly tick, hours since the last anchored vault seal, finding counts by status, and how many sealed findings are missing an anchor commit reference. degraded: true with degraded_reasons naming the tripped signal means the institution has gone quiet or the vault has fallen behind on anchoring — this is the field an external monitor should alarm on, not merely a failed request (a hard failure to reach the database answers 503 with degraded: true as well, so both checks catch it). No person data, no finding titles, ever — Cache-Control: no-store, always: a cached liveness endpoint is a lie by construction.

curl -s https://www.folkefakta.no/api/liveness

{
  "generated_at": "2026-08-08T14:00:00.000Z",
  "last_tick_at": "2026-08-08T13:50:36.785Z",
  "hours_since_tick": 0.2,
  "last_tick_action": "scout",
  "last_anchor_day": "2026-08-08",
  "hours_since_anchor": 7.1,
  "findings_by_status": { "vaulted": 4, "candidate": 4 },
  "unanchored_seals": 0,
  "degraded": false,
  "degraded_reasons": []
}