The DORA profile, running from its own JSON.
This page reads /assets/data/dora.profile-view.json and turns it into a field-level operating surface.
Nothing below is a hand-entered field table. The frontend consumes the generated profile-view projection and renders coverage, source atoms, review state, prevalidation findings and MCP-style tool outputs from that object.
The DORA profile, running from its own JSON.
Required template-field coverage is complete; optional fields are contextual, visible, and not counted as template-field release coverage. Pick a field to trace how the JSON feeds the frontend.
| Field | Req. | Precision | Review | Load | Evidence | Prevalidation impact |
|---|---|---|---|---|---|---|
| Loading generated fields… | ||||||
The selected field as generated data.
This is the actual field object read from dora.profile-view.json, trimmed only by the browser view.
Loading…
This is the layer beneath GRC.
Most GRC tools start with a workflow. ActProof starts one layer lower: the source-bound field.
The live JSON page shows the market utility without overclaiming. It does not file the DORA report. It shows what each field is, where it came from, how precise the binding is, what evidence it expects, and what an agent or validator can check before verification.
- the frontend is generated from the profile-view JSON
- required DORA fields are template-field bound
- optional fields are visible but not overclaimed
- prevalidation and MCP-style outputs can be derived from the same object
- legal compliance or supervisory acceptance
- cryptographic receipt verification
- field-value factual correctness
- stateful incident-report submission
One generated object. Many surfaces.
The same profile-view JSON can feed websites, APIs, MCP tools, audit packs, report linters and vendor schema checks. This is the source-bound pre-validation layer made visible.