R1 · Trust infrastructure · post-AI hiring

Governed
by execution.

Most AI governance is documentation — binders, sign-offs, evidence assembled by hand. R1's governance executes: every AI request checked in-path, every refusal recorded, every dollar accounted. Live, in public.

6/6
gates active
100%
calls governed
Enforcement simulator — live path
gateway · six gates
GATE 01
Purpose binding
Call must declare a governed operation
GATE 02
Route resolution
Approved primary + fallback models
GATE 03
Registry gate
Model registered and enabled
GATE 04
Budget check
Principal · operation · global ceilings
GATE 05
Rate & concurrency
Fixed window + TTL leases
GATE 06
Ledger write
Event committed, identity hashed
Select a scenario to fire a request through the gates.
01
The distinction

Two kinds of AI governance exist. Only one is running here.

Documented
  • Policy binders and sign-off workflows
  • Evidence assembled by hand, after the fact
  • Deployment checked once, at release
  • Answers live in a private dashboard
Governance as paperwork
  • Every request checked at execution, in-path
  • Evidence written by the enforcement itself
  • Budgets refused in real time — per principal, per operation
  • Refusals and spend published on this page
Governance as execution
ai_usage_events — live
append-only
resume
sha256:d2fc5662eb30
$0.0006
analysis
sha256:3520e0785992
$0.0042
embedding
sha256:1cc6cc8506e7
$0.0015
job-extract
sha256:3c6c70c1d50d
$0.0051
intelligence-report
sha256:410876d29d1e
refused
chat
sha256:a4f31a5b5b54
$0.0060
every request writes an event — succeeded or refused
12
governed AI capabilities, each with its own routing and budget
budget enforcement — principal, operation, global
Fails closed

Disabled model → refused. Exceeded budget → rejected. Missing route → error. Every gate refuses in-path. No tokens, no spend, no exceptions.

02
What is governed

Every AI capability is registered as a governed purpose with its own routing, budgets, and audit trail. If a capability is not on this list, it does not reach a model.

Conversational assistant
chat
Resume intelligence
resume · signup-resume
Fit & career analysis
analysis · career-analysis
Job data extraction
job-extract · job-enrich
Semantic matching
embedding
Market intelligence
intelligence-*
03
From tokens to decisions

Token-level governance tells you what the model cost. Decision-level governance tells you who it helped decide — and that is where hiring law lives.

Assistance, enumerated

Every AI touchpoint in a hiring workflow is a governed purpose — parse, match, analyze, draft. The touchpoint list is a query, not an investigation.

Decisions, recorded

Alongside token events, R1 records hiring decisions with reasoning in the decision audit trail — AI assistance and human verdict, bound together.

Humans, accountable

The system records assistance; people own verdicts. Accountability chains end at a person, which is what regulators and auditors actually ask for.

04
The ledger

It records accountability — never content.

Recorded
  • Operation and purpose of every call
  • Requested model vs. model that served
  • Token counts — prompt, completion, total
  • Cost per request, month, principal
  • Latency and terminal status
  • Route revision in force
  • Hashed principal and billable owner
Never recorded
  • Prompt text or model responses
  • Candidate documents or profiles
  • Message or conversation content
  • Un-hashed identifiers

Append-only. Monotonic config revisions. History cannot be rewritten — only extended. Exportable for compliance review.

05
Regulatory alignment

Stated plainly: what the architecture supports today, and what remains ahead.

EU AI Act

Employment and recruitment are named high-risk. The obligations — documentation, logging, human oversight — are the artifacts this system produces by executing.

Annex III — high-risk
NYC Local Law 144

Bias audits require enumerating every AI touchpoint in hiring. Purpose-bound governance makes that enumeration a query, not a project.

Audit-ready data model
EEOC / Title VII

Adverse-impact review needs the exact boundary of algorithmic assistance in selection. Purposes draw it explicitly, per operation.

Boundary documented

On the roadmap: independent third-party bias audits, provider attestations, gateway content guardrails. A governance page that overstates is itself a governance failure.

06
Principles

Three rules the system is built on.

01

Governance must execute

A policy that cannot block a request is a suggestion. Controls run in the request path — enforcement is code, not documentation.

02

Every token is accounted

No AI request exists outside the ledger. Unlogged spend is a defect, not an edge case.

03

Humans decide

AI ranks, drafts, extracts, analyzes. Hiring decisions remain with people — the system records assistance, never verdicts.

The trust stack

Proved in public, not requested in private.

Enterprise dashboards ask you to trust them. R1's infrastructure is published, live, and independently checkable — three layers, one position.

01
Security
The server stores math, not messages. E2EE by construction.
02
Transparency
Every key change, hash-chained and publicly verifiable.
03
Governance
Every AI action enforced in-path and written to the ledger.
Trust is not requested. It is verifiable.Bring your risk review
Governance — R1 Trust Infrastructure