Arbiter Developer Docs

Fragmented records are a structural failure, not a compliance inconvenience. Every regulated operation still asks the same questions (who owns which risk, which control applies, and whether the evidence still matches what was asserted) while each system keeps its own answer.

Arbiter is the system of record for those answers. The risk register entry (a risk, control, or policy record) is the unit of record: every entry carries a lifecycle state, mapped framework obligations, and SHA-256-fingerprinted evidence, with optional sealing onto Stratum for independent verification. Dashboard, REST API, and MCP read and write that same tenant data under the same RBAC — no separate contract per surface, and nothing to reconcile between them.

Who this is for

When the assessor asks for ownership, applicable controls, and whether evidence still matches what was asserted, you need one shared answer. Use this table to see if Arbiter is your path.

You are…	The problem you feel	What Arbiter gives you
Compliance or risk owner in a regulated operation (financial services, professional services, and similar)	Answers live in different systems; prep becomes reconstruction	One live register of risks, controls, policies, and SHA-256-fingerprinted evidence your assessor can work from
Developer wiring partners or agents	A second permission model or scraped UI path	Same tenant data via REST or MCP under the same RBAC as the dashboard
External assessor or reviewer (including CPA engagements)	Screenshot packages and portal sprawl	Scoped read access plus hash-manifested export packages, not a separate portal SKU

Start here. No workspace yet? Create one at arbiter.blockskunk.com. Then mint a key and complete a first call in Quickstart.

Explore by topic

Topic	Start here
What Arbiter is and which surfaces exist	Integration Surfaces
Who can read or act	Access Model
States a record moves through	Lifecycle
Shapes partners and agents read	Records
What a fingerprint or seal proves	Verification
Machine-readable REST contract	API reference

Use the matrix above to pick a starting page. The sections below expand what Arbiter delivers and how verification layers fit together.

What Arbiter gives you

Capability	What it gives you
Lifecycle state	One shared answer to “where is this risk or control, and what can happen next.”
Multi-framework mapping	One control maps once across the frameworks you report against, not a parallel library per standard.
SHA-256 fingerprinted evidence	Tamper-evident proof at upload; if the file changes, the fingerprint breaks.
Assessor-ready exports	Audit-package ZIP with hash manifest for assessor handoff.
Scoped external reviewers	Read-only assessor access in-product, not a separate portal SKU.
Same data via UI, REST, MCP	One org, one permission model; programmatic surfaces inherit the user’s RBAC.
Optional Stratum seal	Independent ledger proof when entitled; see Verification. Maturity: available by arrangement.

How the system fits

Three verification layers. Do not collapse them into a single claim.

1. Operational (Live). Arbiter dashboard and APIs: risks, controls, policies, incidents. Day-to-day GRC at speed, role-scoped and audited.
2. Hash-chained (Live). SHA-256 fingerprints on evidence and package manifests. Tamper-evident without requiring a ledger.
3. On-chain (Available by arrangement). Metadata-only seals onto Stratum (Verified on-chain). Proves anchoring of a published digest, not that Arbiter’s internal review was correct. NPI never leaves for the ledger path.

Beyond these boundaries, how review decides and how scores are reached is not part of this contract.

Reading order

Product / assessor vocabulary

To answer	Read
Who can read or act on what	Access Model
States a risk or control moves through	Lifecycle
Shape of each record type	Records
What a fingerprint or seal proves	Verification
What stays public vs private	Disclosure Boundary

Integrator path

To answer	Read
Which surface can I build against today	Integration Surfaces
Mint a key and complete a first call	Quickstart
Auth and key lifecycle	Authentication
Machine-readable REST / Partner Read	API reference
Push/ack partner events	Webhooks