Developer documentation

Developer portal

Last reviewed 31 August 2026

Developer Portal

cainstudio.online/portal — and the same portal

on the self-hosted deployment at /portal.

An engineering control centre for the Trust Fabric. One page, no build step, no

framework: it loads in a single request, and you can read the whole of it with

view-source and check that the panels really call the endpoints they claim to.

The rule this portal is built on

> Every interactive panel names the real endpoint it calls. A panel with no

> backing endpoint is declared planned and rendered as a stub.

That is enforced, not intended. portal.validate() cross-checks every live

panel's declared endpoints against the deployment's real OpenAPI document during

sync.sh, and the build fails if one is missing. It caught three real mismatches

the first time it ran.

Panels are labelled:

There is currently 1 planned panel (a live event stream). There is no

streaming endpoint yet, and polling once a second dressed up as "live" would be a

lie about the architecture.

The portal is governed by CAIN

Consequential developer actions — publishing an extension, rotating a key,

revoking a principal, changing policy, exporting evidence — are routed through the

real decision path before they happen:

POST /portal/actions/publish_extension

VERDICT: ALLOWED | decision_id: fd_a4003572107e46aba05f930a
  identity       allow    enforcing
  authorization  allow    enforcing
  policy         allow    enforcing
  risk           allow    enforcing
  actionproof    skipped  enforcing

That decision is real evidence. It is retrievable, signed (HMAC-SHA256 over 8

fields), and reading it is itself recorded in the evidence access log.

Two deliberate properties:

• It authorizes; it does not act. The endpoint answers "may I" and returns the

decision id. A single call that both decides and acts is one where you could

never prove afterwards that the check ran.

• It fails closed. If the control plane is unreachable it returns 503, never

an approval. An unknown action returns 404 with the list of known ones — it does

not silently allow.

If CAIN cannot govern its own control surface, it cannot govern anything.

Roles

Ten roles, each a lens over the same platform — not ten products. Each carries its

own learning path, the APIs it actually touches, the conformance suites that matter

to it, and a project template.

Your role selection persists locally. Your credential does not — see below.

Panels

Trust Decision Explorer · submit an action, watch the real stage-by-stage path

ActionProof Debugger · submit a plan; reports not_configured honestly when there is no profile

Evidence Explorer · decisions, signatures, and who read what

Agent Run Viewer · one correlated run, and what a shadow deployment would have refused

Policy Playground · dry runs with no enforcement and no side effects

Security Lab · real injection payloads through the risk screen — including a benign control, because a screen that flags everything is not a screen

Conformance · live posture per stage, including stages enforcing with nothing loaded

System Status / Metrics · the same data cain doctor reads

Marketplace / Extension Publisher · browse, claim a handle, authorize a publish

MCP Inspector · list tools over real MCP

Integration Generator · local — a template, not a code model

Trust Surface · the eleven domains with their published coverage gaps

Executable Quickstart · progress checked against the API

Your credential

The portal asks for an API key and holds it in that tab's memory only. Not

localStorage: an injected script can read localStorage, and this is a

full-privilege credential. The cost is retyping after a refresh, which is the

right trade for a surface that governs production.

Every panel calls the same authenticated APIs your agents call. There is no

privileged back channel — anything the portal shows you, you can reproduce with

curl.

Onboarding

Ten steps: create account → create project → install CLI → connect agent/MCP → run

first trust decision → inspect evidence → pass conformance → build extension →

publish → deploy.

5 of 10 are checked against the real API. The other 5 cannot be verified from a

browser — whether cain.yaml is on your disk, whether the CLI is installed,

whether cain test passed — and they are drawn with a dashed border and say why.

Showing an unverifiable step as complete would make the whole progress display

worthless.

Community

Discord · GitHub · vulnerability reporting (safe harbour, real response target) ·

changelog · what we don't do yet · roadmap.

Named as not built, rather than quietly omitted: a forum (Discord covers it; a

dead forum is worse than none), a certification programme (cain test is the

conformance check — a certificate implies an assessor and there isn't one), and a

paid bug bounty (reporters are credited instead).