The control layer most GRC stacks leave implicit.
You already have dashboards, article trackers, and consultants. They can tell you a regulation changed. They often do not make explicit which of your own field-mapping decisions now needs re-review.
This page runs the real DORA profile through the loop a bank actually lives: compare your schema to the source-bound profile, record your reviewed decisions, then watch a regulatory change land and show you — by name, by reviewer, by exact cause — what you now have to re-review. Nothing here is mocked. It reads the live profile-view JSON.
What existing tools do well, and the control layer they often leave implicit.
- track which regulations changed and when
- manage tasks, owners and deadlines
- cite articles and show timelines on dashboards
- store your policies and control mappings
- bind each reporting field to a source-bound profile object with recomputable hashes
- tell you which of your accepted mappings a profile change puts back into review
- tie each stale decision to the specific profile/source change that caused it
- preserve your reviewer's name on the re-review backlog
Three steps. Your data on the left, the source-bound profile on the right.
Loaded from /assets/data/dora.profile-view.json — the same generated object the package produces. loading…
Step 1 — Your internal DORA incident schema, compared to the source-bound profile.
A typical bank holds its own incident schema, built by a vendor or in-house. ActProof compares it field-by-field to the public profile and produces a source-bound gap report: what matches, what is missing, what is vendor-only, and — the one that matters in an exam — what your schema overclaims.
| Your field | Maps to (source-bound) | Status |
|---|---|---|
| Run the comparison to populate. | ||
Step 2 — You review the candidate mappings and record decisions. ActProof never decides for you.
Nothing is auto-approved. A reviewer on your team accepts the mappings that hold and notes the ones that need work. The result is a bank overlay — your decisions, pinned to the exact profile hash they were made against, with the reviewer's name on each one.
The overlay is the bank's own object. It stays a file the bank owns — it is never sent to ActProof, and the local API deliberately refuses to accept it over HTTP.
Step 3 — A delegated regulation amends the profile. Which of your decisions just went stale?
This is the moment generic change tracking becomes insufficient. A change lands: one field's source basis is amended and the profile's semantic hash moves. Your dashboard says “DORA updated.” ActProof says something more operational — which accepted decisions now need re-review, why, and whose name is on the review record.
It survives an exam because it underclaims.
ActProof does not file your report, decide your compliance, or replace your reviewer. It makes your own decisions inspectable, and it makes a regulatory change actionable at the field level.
The gap report, the reviewed overlay, and the change-impact report are the same three objects an examiner would ask you to produce: what you mapped, who reviewed it, and how you responded when the rule moved. Most institutions reconstruct that by hand, under time pressure, after the change. This produces it as a by-product of working against a source-bound profile, while keeping final judgement inside the bank.
- the gap report is computed against the real profile-view JSON
- your decisions carry a reviewer and a profile-hash pin
- a profile change maps precisely to your re-review decisions
- the re-review backlog preserves who approved what, and when
- legal compliance or supervisory acceptance
- that a matched field is legally correct
- that your schema is complete without review
- to submit or lodge anything on your behalf
Run it against your own schema, locally, behind your own controls.
Install the package, point compare-schema at your incident schema, and the whole loop runs offline inside your environment. The overlay stays a file you own. ActProof never receives your incident data.
Source atoms sit below the field table.
ActProof source atoms identify the legal fragments that profile fields draw on. They make field meaning inspectable before candidate mapping, bank overlays or pre-validation run.