Why does the same compliance work keep getting rebuilt?
A legal requirement may apply to thousands of organisations. The practical work around it often begins from zero each time.
One team reads the source, asks a specialist what it means, writes a procedure, creates a form, adds validation, trains staff, and decides what evidence to retain. Another team facing the same obligation does almost exactly the same work in a different document, spreadsheet, ticketing system, or internal application.
The finished result may look different, but the questions underneath it are familiar:
- Which facts determine whether the rule applies?
- What information must be collected?
- Which answers require follow-up questions?
- What blocks completion?
- Which exceptions are available, and what evidence supports them?
- What should be retained when the process is complete?
- What happens when the interpretation changes?
The expensive part is not always displaying five fields on a page. It is deciding what those fields mean, how they interact, and what makes the result defensible.
Yet that interpretation is usually trapped inside the thing built for one organisation. It cannot be inspected independently, adopted cleanly, versioned as its own object, or reused across several experiences.
That is the pain point behind ProseID:
Legal knowledge is published as prose, while its operational interpretation is repeatedly rebuilt as private implementation work.
ProseID exists to give that interpretation a reusable form.
Where does legal interpretation go today?
Legal text does not arrive as product requirements.
A regulation might say that an organisation must act within a deadline, unless a particular risk is unlikely, and must include specified information in a notification. It will not usually provide a JSON schema, interface states, error messages, data model, or test suite.
Someone has to translate the source into operations. In practice, the result tends to be distributed across several places.
The explanation lives in a memo
The memo describes scope, duties, exceptions, and uncertainty. It is useful to a human reader, but software cannot reliably execute a paragraph.
The steps live in a procedure
The procedure tells staff what to do. Important branches may be expressed as “where appropriate,” “if required,” or “escalate when high risk.” The person following it still has to remember how those statements affect the current case.
The questions live in a form
The form collects answers, but its fields rarely contain the full reasoning behind them. A later editor may not know why a question exists, which authority supports it, or what else depends on its answer.
The controls live in code
Validation, branching, calculations, and completion rules become application logic. They work, but they are now coupled to one product and one development team.
The evidence lives somewhere else
The completed form may become a PDF, database row, email, or ticket. The record may not preserve the exact version of the interpretation used when it was created.
Each artefact solves a real problem. The weakness is the gap between them. The legal source, operational choices, executable logic, interface, and resulting evidence can drift apart without anyone deliberately choosing to change the interpretation.
Why don’t documents, forms, and GRC tools solve this?
They solve adjacent problems. That distinction matters more than the category label on the software.
A document explains
A policy, guidance note, or legal memorandum can carry nuance, reasoning, and caveats. It is often the right medium for analysis. It does not make the analysis runnable by itself.
A reader must still turn “collect a reason if the report is late” into a field, a condition, a validation rule, and a retained value.
A form collects
A form builder can turn questions into a usable interface. Some can branch, calculate, and validate. But the form is commonly treated as part of a single workspace rather than a published interpretation with its own identity, provenance, releases, and downstream consumers.
Copying the form creates another editable copy. It does not create a dependable relationship to the original interpretation.
A GRC platform organises the programme
Governance, risk, and compliance platforms are valuable for mapping requirements to controls, assigning owners, collecting evidence, monitoring systems, and preparing for audits. Their central object is often the control, risk, framework requirement, test, or evidence item.
That is different from executing a case-level process for a customer, employee, supplier, incident, or request. The modern compliance stack explains where those layers meet.
Custom software executes—but isolates
An internal application can express the workflow exactly. For proprietary or deeply integrated decisions, custom development may be the correct answer.
But every implementation must then build and maintain familiar infrastructure: schema design, conditional interfaces, validation, version history, access, completion records, delivery, audit trails, and integrations. The interpretation is reusable only inside that application unless the team deliberately turns it into a separate product.
The missing capability is not another way to write prose or draw a form. It is a way to publish the operational interpretation as a stable, executable object.
What would a reusable interpretation look like?
A reusable interpretation needs more than a list of questions.
It should identify:
- Its source: the law, regulation, guidance, policy, contract, or control behind it.
- Its scope: the jurisdictions and circumstances in which it is intended to operate.
- Its facts: the typed information required from a person or system.
- Its decisions: the conditions, calculations, and derived outcomes applied to those facts.
- Its completion rules: the errors that block progress, warnings that need attention, and attestations that must be made.
- Its presentation guidance: labels, explanations, placeholders, and helpful context for the people using it.
- Its release identity: a permanent version that consumers can depend on.
- Its provenance: who published it, what it was adapted from, and whether later changes created a new release.
Once those parts travel together, the interpretation can support more than one interface.
The same schema might run as:
- a standard form for direct data collection;
- a guided assessment that presents one decision at a time;
- a determination that makes a derived result prominent;
- a compliance checklist organised around explicit controls; or
- an API-driven process inside another product.
Those experiences are not identical, but they can share the same underlying definitions and rules. The organisation no longer needs to copy the legal logic simply because a different user needs a different interface.
Why do versioning and provenance matter?
Reuse becomes dangerous if adopters cannot tell what they are depending on.
Imagine that an incident workflow is changed after a regulator issues new guidance. The new version may ask for an additional fact or alter a warning. Future cases should use the updated release. Earlier cases should continue to show exactly what applied when they were completed.
If a publisher can silently rewrite the old version, the historical record becomes ambiguous. If a release can disappear after another organisation has integrated it, the adopter inherits someone else’s availability decision.
A reusable system therefore needs software-style release discipline:
- drafts can change;
- published versions are permanent;
- a material change creates a new version;
- completed records remain bound to the version they used;
- deprecated releases remain inspectable; and
- adaptations retain a visible relationship to their source.
Provenance addresses a different question: why should anyone rely on this interpretation?
The answer cannot be “because it appeared in a marketplace.” An adopter should be able to inspect the publisher, legal references, jurisdiction, release notes, version history, and reputation around the work. Verification can add identity assurance, but it does not make every interpretation correct. Professional review and the adopter’s own judgment still matter.
This is why a registry is part of the infrastructure, rather than a decorative catalogue. It lets the logic be discovered and evaluated before it is run.
What does ProseID change?
ProseID separates the interpretation from any one implementation.
A publisher models the required facts, field types, conditional logic, computed values, validation messages, attestations, legal references, and jurisdictions as a schema. The publisher tests the available experiences, then releases an immutable version.
An organisation can use that release in a hosted Flow or through an integration. When someone completes the Flow, ProseID validates the answers on the server and creates a record anchored to the exact schema, version, Flow, and publisher involved.
That changes the unit of reuse.
- A document can be read many times.
- A template can be copied many times.
- A ProseID release can be executed many times without losing its identity.
Consider the 72-hour personal-data-breach notification in GDPR Article 33. The reusable interpretation can define the awareness time, risk assessment, required notification content, phased-information state, and reason needed when notification is late. One organisation can present it as a guided assessment to an incident lead. Another can embed the standard form in its response portal. Both completions can point back to the same released logic—or to an adapted release where local law or procedure requires a change.
The value is not that the screen contains inputs. The value is that the interpretation, controls, presentation guidance, version, and resulting record remain connected.
What does ProseID not do?
ProseID does not make legal judgment disappear.
It does not decide which laws apply to an organisation. It does not guarantee that a publisher’s interpretation is correct. It cannot turn an inherently subjective standard into an objective answer simply by adding a dropdown. It does not replace investigation, advice, case management, evidence gathering, or a broader compliance programme.
It also should not be used to disguise uncertainty. If a decision depends on human judgment, the schema should expose that judgment, collect its rationale, and identify who made it.
The platform makes an interpretation structured, testable, versioned, inspectable, and repeatable. The quality of that interpretation still depends on the people responsible for it.
That boundary is a feature. Trust is stronger when a system shows where professional responsibility begins instead of pretending that automation has removed it.
When is this layer useful?
Not every process needs reusable legal infrastructure.
A simple contact form probably does not. A one-off internal decision may be easier to handle in an existing tool. A proprietary risk engine deeply coupled to private data may belong inside the product that owns it.
The reusable layer becomes useful when several of these statements are true:
- the same interpretation will run repeatedly;
- several teams, customers, or products may use it;
- the logic matters more than the surrounding interface;
- answers depend on conditions, warnings, or calculations;
- adopters need to know who published the interpretation;
- earlier completions must remain understandable after a change;
- the workflow needs a hosted and an integrated path; or
- one expert’s work should be adopted without every team rebuilding it from prose.
That last point is the larger opportunity.
Software developers do not normally rewrite a database, authentication system, or payment network for every application. Mature infrastructure lets them depend on well-defined components while retaining responsibility for how those components are used.
Operational legal knowledge has rarely had the same treatment. It is still exchanged primarily as text and repeatedly translated into isolated workflows.
ProseID is an attempt to make the finished interpretation portable: authored once, inspected openly, released permanently, adapted visibly, and executed wherever the work happens.
The supporting article, why legal checklists break when they become software, follows one of the most common failure points in that translation. For a practical modelling method, continue with from legal text to a compliance schema.