Requirements Distillation in Regulatory Technology

The Regulatory Problem

Mapping source authority onto product architecture is a central problem in regulatory requirements work. The established requirements-engineering vocabulary for that work is traceability: the ability to connect requirements back to their sources and forward into design, implementation, verification and change impact.¹^,2

The regulation and the architecture describe the same future system from different directions. The regulation describes the allowed system (actors, records, obligations, time limits, control powers, evidence expectations etc), while the product architecture describes the running system (components, data flows, failure modes, ownership boundaries, support processes, customer-facing claims etc). Requirements become actionable product work only after those two descriptions are connected in a maintained requirements model.

Time adds another distinction. Each statement may become stale as often as the regulator revisits their requirements. A flat Confluence page can hold that status, but only when the team enforces it manually. Regulatory-change-management and compliance-management systems instead treat obligations, controls, owners, tasks, impacts and review status as managed objects.³^,4

These problems meet in product management praxis, where conceptual classification becomes operating work and needs to inform project planning, stakeholder advisory, externally facing comms and so forth. Such challenges may also be understood as a knowledge representation problem. A useful representation of a highly regulated product has to bind authoritative sources, requirements interpretations, delivery state, communication boundaries, and temporal logic into the same maintained object, so that teams can reason over versions, dependencies, approvals, and permissible claims. Provenance standards and architecture-view standards give that local object its wider disciplinary anchors: one records where an assertion came from, and the other separates stakeholder-specific views from the underlying architecture description.⁵^,6

This article is a review of my experience working as a Product Manager in the software fiscalisation domain. It summarises my attempts at the conceptual and pragmatic tasks I described above, and a few of the challenges I encountered throughout.

A Software Fiscal Machine

The job of fiscalisation software is to turn a retail sale into a fiscal record. The system records the operation, preserves the required data in a verifiable form, issues the commercial document and sends the daily receipt data to the authority.⁷ That work makes the software a regulated fiscal component with duties exceeding ordinary point-of-sale features. For products sold across European fiscalisation regimes, the recurring duties are durable fiscal records, attributable submissions, tamper-evident data, regulated transmission, inspection access and so forth.⁸

The Italian case is particularly interesting when it comes to requirements elicitation and maintenance. At the time my team tackled it, software fiscalisation in Italy had only recently been authorised⁹, which made it a disruptive change in an industry previously dominated by hardware-only compliance. In that still-unsettled territory, the institutional technical specifications that would guide implementation moved on their own difficult timeline¹⁰, with shifts in versions, phrasing, and interpretation. Apart from direct governmental channels, the team had to incorporate and triage information from stakeholder roundtables, category-association conferences, meetings with industry actors, including both written materials and oral clarifications, across formal and informal settings with different degrees of authority.

For all these reasons, the team had few priors for mapping the fiscal functions onto the target product, which made requirements unstable where source terms still had to be translated into architecture, ownership, evidence and support obligations.

Regulatory Distillation

Regulatory distillation is my local name for the operational combination of regulatory change management, requirements traceability, provenance, and audience-specific architecture views. It converts a regulatory and institutional corpus into accepted product state: the requirement or decision record that links source authority, interpretation, owner, status, affected architecture, and review trigger. The first finding, as I have already hinted, is that the corpus contains several source classes. Official specifications, annexes, institutional clarifications, internal architecture knowledge, questions from customers or partners and miscellaneous intel can all trigger new product work, but each statement needs its authority class and version before it enters the requirement model.

The second finding is that distillation works as a pipeline. Source material enters with authority class and version. Terms are normalised into a practical domain model of actors, components, fiscal objects and relations. Requirement-bearing statements then receive provenance state and product state. Provenance state records where the statement comes from and when it needs review, while product state records where it lands in the architecture and what work it creates. The resulting record must be evaluated against the target architecture before it is rendered into dedicated engineering, sales, support or leadership views.

Regulatory distillation pipeline with architecture-state evaluation as the gate

Architecture-state evaluation gates source material before it becomes audience-specific projections.

The statement type determines the review route. A source obligation must return to review when the source changes, a technical rule when the specification changes, and an architectural inference when the product architecture or accepted interpretation changes. An effective requirement taxonomy keeps those review triggers visible beside each requirement, rather than treating all requirement statements as if they had the same source authority and change behaviour.¹¹

Requirement type	Function in the model
Explicit regulatory	Preserves obligations stated in official source text
Explicit technical	Preserves rules stated in specifications or annexes
Derived architectural	Records what follows when source material meets the target architecture
Certification-support	Keeps evidence and explanation ready for evaluation
Operational	Covers monitoring, onboarding, failure handling, and support
Communication	Bounds what sales, support, and partner material can claim

Requirement taxonomy used to route review triggers.

By this stage, substantial knowledge work has already been done. However, the representation problem does not end once an interpretation has been accepted and enforced at the document level. The team still has to decide where each obligation lands in the architecture, which component owns it, and what evidence proves it. These decisions too need to be sourced, back-linked and maintained.

Text Without State

Distillation usually produces several document types. Each solves a local coordination problem, but each also loses part of the regulatory state when treated in isolation.

Document type	Useful because	Fails when it stands alone
Source map	Preserves authority, source version, and relevant passages	Leaves the product decision for another layer
Requirement register	Atomises obligations and assigns ownership	Flattens unlike statements unless status and review triggers are typed
Architecture note	Records where an accepted interpretation lands in the product	Ages when the architecture changes without a linked review
Jira epic or story	Turns an accepted requirement into executable work	Strips source authority and ambiguity down to delivery language
Confluence page	Gives teams a readable shared explanation	Relies on manual discipline to keep status, audience, and version true
Certification pack	Packages evidence for approval, audit, or institutional review	Optimises for proof and leaves daily product decisions underspecified
Sales or support guidance	Translates accepted interpretation into reusable external language	Can detach from authority when edited as ordinary knowledge
Open-question log	Keeps ambiguity visible while a decision is pending	Becomes an archive if no owner links it back to the requirement model

Document projections and the regulatory state they lose when isolated.

These documents are views over the same product state in different operating contexts. I use projection here in the architecture-description sense: a stakeholder-specific view should expose what that audience needs without severing the link to the maintained model. A DMS is a good target for the readable view, as long explanations, source summaries and cross-team guidance need digestible sources to rely on.

As the product state evolves, the need for a traceable source of record emerges quickly. An effective distillation system keeps those properties attached to the same maintained object, then renders the object into the document each team needs. For example, one requirement row can feed a Jira refinement note and a Confluence support page, while both inherit the same source passage and review owner. When that layer is absent, the organisation manages many correct-looking texts, each implying a requirement state. The divergence appears later, when an implementation, certification file, sales claim, or support answer no longer matches the regulatory knowledge the product depends on.

Projections From One Model

The projection layer turns the register into working documentation. It renders the accepted product state into targeted audience views while keeping interpretation, source reference, review trigger and owner in one place. A knowledge base (e.g. a collection of Confluence pages) is the readable surface for those views. Each team needs ordinary, accessible pages, a dedicated degree of granularity and information density, whereas each page inherits its claims from the maintained model.

The engineering projection converts accepted requirements into buildable work. It shows the atomic requirement, source passage, affected product surface, implementation implication, ambiguity state, refinement links and so forth. A Jira story can then carry both the task and the reason that task exists, so engineering work can return to the model when a source, interpretation, or architecture decision changes.

The sales and support projections translate the same state into permissible language. Sales should receive claims that stay inside the accepted interpretation, while support needs explanations that first map customer vocabulary back to fiscal concepts. A useful output is in plain, understandable but bounded language. Once a sales claim or support answer circulates, customers, partners, or certifiers can treat it as the company’s position, so the projection has to explicitly state its authorisation status.

The leadership projection exposes acceptance state. It groups unresolved interpretations, certification dependencies, risk surfaces, and architecture constraints into a view that shows where the product can proceed and where review remains open. It is less detailed than the engineering register, but its claims need stronger provenance because they guide strategic decisions.

Provenance should be a concrete registry object rather than a tacit and scattered documentation habit. In a small team, the lowest-friction implementation can be a spreadsheet row collecting all relevant requirements attributes (stable requirement ID, source passage ID, interpretation note, linked Confluence or Jira page, owner, status, review trigger etc). More formal implementations can use the same conceptual structure in a GRC, requirements-management, or knowledge-graph system. Each paragraph, answer or delivery item then references the requirement ID, so the projection carries a pointer to the source and to the decision that licensed it. If such a pointer disappears, source text becomes accepted interpretation, accepted interpretation becomes repeated explanation, and repeated explanations finally collapse in unsupported local claims.

Retrieval Leaves State Unresolved

Retrieval improves access to the corpus. A search index, semantic retrieval layer, or ordinary document query can find the relevant specification paragraph, surface nearby clauses, compare source versions and translate domain terms into comprehensible language. This reduces the cost of reading the corpus and helps teams return to the same shared evidence.

However retrieval is not yet product knowledge. A retrieved paragraph still has to be translated into accepted requirement or decision state before it can guide implementation or communication. As opposed to treating retrieved material as an accepted answer, we will consider it a candidate product state change, and subject it to review.

A review packet is needed at this point, including retrieved evidence, proposed decision and affected product-state record, as well as a linked owner. The review mechanism itself can be as complex as a full review-routing system, or as simple as a Jira ticket that collects the relevant evidence, records the owner’s decision and keeps the justification in the ticket history.

Change Propagation

We have previously mentioned temporal dimension as a complexity multiplier. Change propagation is the distillation workflow’s version of change impact analysis: it protects product state when a source, interpretation, or architecture decision shifts underneath.¹² When one object changes, the model should identify the affected records before teams rediscover the change through implementation work or customer questions.

There are two practical implementation regimes for tackling change propagation. One uses agents to monitor sources, update candidate records, inspect projections, and prepare review packets. The other uses manual operating discipline, with registers, DMS pages, review meetings and so forth.

The agentic version is straightforward in shape. Source changes enter a watcher, changed blocks are matched against requirement IDs, and affected projections are marked for review. The system can draft candidate edits, find unsupported claims, and assemble evidence. The model prepares a state transition, and institutional authority stays with a human owner.

The manual version uses the same state machine, but has weaker enforcement unless the review ceremony is kept deliberately close to the register. A spreadsheet can hold source ID, requirement ID, audience, owner, downstream pages, review trigger and status. Confluence can carry the readable view, while review meetings close or reopen tracked assumptions.

At the time I was handling this product, commercial regulatory-change platforms already existed for regulatory-change management.¹³^,14 They were not, however, widely adopted in my organisation, which preferred custom implementations.

By Q3 and Q4 2025, the agent stack already had APIs with built-in tools and tracing¹⁵, coding agents that could edit repositories and run tests¹⁶, connector protocols¹⁷, and agent builders for orchestration and evaluation.¹⁸ The remaining gap was practical reliability for long-horizon knowledge work. Q4 model releases made that gap smaller through stronger tool use¹⁹, agentic coding and context management²⁰, while the workflow still needed manual custody over downstream projection control. Operatively, that meant that generated summaries, source excerpts and Confluence drafts had to be manually reconciled against the register before they could become product state.

The operational lesson, resonating even clearer today, is that agentic enforcement should automate the maintenance burden while leaving authority decisions with named owners. The workflow can watch, compare, draft, route and explain. Product owners still decide the accepted interpretation, the allowed projection and what may be said outside the organisation.