PV-01Missing required
Required fields absent or empty.
Any required profile field with no value. These block readiness.
Pre-validation lints a draft incident report against a source-bound profile and tells you what is missing, what is unexpected, and which present fields still carry interpretive or evidence risk.
It does not verify report bytes, signatures, timestamps or anchors — that is downstream verification in actproof-py. Pre-validation answers an earlier, cheaper question: is this draft shaped and evidenced well enough to proceed?
Before a company submits a regulatory incident report, someone has to ask: have we actually filled in everything the rule asks for? Are there fields we invented that the rule never mentioned? And are the hard, judgement-heavy fields backed by the evidence a supervisor would expect to see?
Pre-validation does that read-through automatically, against the same source-bound profile the rule was mapped into. It returns a plain status — blocked, attention required, or ready for pre-verification — with the specific fields behind each. It is a readiness check, not a verdict on compliance.
Pre-validation reads a draft report payload as field_id → value and checks it against the source-bound profile. It surfaces five signals, each pointing at specific fields.
Any required profile field with no value. These block readiness.
Values submitted under keys the profile does not recognise — possible drift or invention.
Fields the profile marks as interpretive, where a supervisor looks first.
Present fields whose evidence labels call for committee-grade records.
Fields carrying a non-public disclosure tier, flagged so they are handled accordingly.
blocked, attention_required, or ready_for_preverification — computed, never asserted.
The status is derived, not stored: it follows directly from the signals above, so it can never disagree with them.
Pre-validation is exposed identically across the command line, the REST API and the MCP server, so a person, a CI pipeline and a compliance agent all read the same result.
| MCP tool | Purpose | Market utility |
|---|---|---|
explain_field_source | Explain why a DORA field exists and which source atoms support it. | Grounds agent answers and human review. |
source_coverage | Report required, optional, template-field and contextual coverage. | Prevents overclaiming and exposes review state. |
lint_report | Detect missing fields, unknown fields and high-attention fields. | Useful before internal review or submission preparation. |
prevalidate_report | Return a deterministic prevalidation status with the fields behind it. | Creates a bridge toward future pre-verification packaging. |
A partial DORA initial-notification draft, checked against the source-bound profile.
The output names the missing required fields and the present fields that still warrant attention, then returns one status.
$ actproof-events lint-report \
op:eu.dora.ict_incident_notification_initial.v1 \
draft-report.json
lint-report for op:eu.dora.ict_incident_notification_initial.v1
status : blocked
prevalidation_status : blocked
required present : 3 / 15
missing required : affected_member_states, business_continuity_plan_activated, ...
high interpretive load : classification_criteria_triggered
ready_for_preverification : false
boundary: pre-validation only; not legal advice, not certification.
next: actproof-py performs canonicalisation, timestamping and anchoring.Structural and evidence gaps are caught at draft time, against the source-bound profile — long before anyone canonicalises bytes or requests a timestamp. The hard verification layer only runs on drafts that are already shaped right.
The boundary is the same discipline as the rest of ActProof: it states plainly what the layer can and cannot establish.
Pre-validation makes a draft report inspectable against a source-bound profile before any cryptographic commitment. The verification layer comes after.