Placet Experiri

A Stack View of the Document Processing Market

Fri, 05 Jun 2026 00:00:00 GMT

“AI document processing” is a vast product category. It encompasses enterprise content platforms,¹ hyperscaler APIs,²^,3^,4 frontier parsing services,⁵^,6 open-source converters,⁷^,8 OCR baselines,⁹ web-capture tools,¹⁰ review queues,¹¹ and full workflow systems.¹² The definition hides a complex stack, one running from record custody to approved output.

The products examined here tackle document processing with varying concerns. As a tentative map of the market, we propose to follow the responsibility boundary across the complementary concerns of document custody, representation and review.

Criteria cut across markets

Criterion	Layer	Responsibility
Intake coverage	Layer 1: custody	Accept the source forms the workflow has to govern.
Provenance	Layer 1: custody	Keep each derivative and field attached to source, page, block and version.
Governance	Layer 1: custody	Enforce access, audit, retention and data residency around the record.
Layout fidelity	Layer 2: representation	Preserve page structure needed for extraction and review.
Structured extraction	Layer 2: representation	Turn recognised content into fields with schemas, confidence and source locations.
Agent-readable output	Layer 2: representation	Produce a derivative an agent can read without losing needed structure.
Review routing	Layer 3: review	Send uncertain or policy-sensitive output to a reviewer as work.

Criteria grouped by stack layer.

The boundaries we see in the table correspond to specific product capabilities. A DMS can own the record and route the work, while saying little about how a table cell turned into a field. A cloud API can return polygons, spans and confidence, and be reticent about which version is authoritative. A converter can give the agent readable Markdown, while dropping the page geometry that a reviewer later needs.

The literature treats document intelligence as a pipeline of services. Quality checks, classification, extraction, rule evaluation, routing and human review each occupy a separate step, and model inference is only one operation in the system.¹³

These considerations are not merely taxonomical. When procurement buys one layer and just assumes the adjacent ones, the gap shows up at implementation time. The team is left to reconstruct the missing controls: the location of the approved version, the reason an outdated policy was used and the person responsible for approving the extracted field.

The stack can be read through three responsibilities: custody of the record, representation of the record as usable derivatives and review of the output accepted for use.

Layer 1: Custody

DMS custody and workflow

We start from custody, since every later layer depends on it. Custody takes care that a source can be clearly archived, identified and referenced. The DMS is the institutional home of the document record. Its custody work covers intake, versions, permissions, routing, approvals, retention and audit.

We will analyse Doxis as a worked example. SER Group renamed the company after its platform in Q1/2026, while repositioning as “The Document Intelligence Company”. Furthermore, it installed the co-founder and CEO of the document-processing vendor it had acquired the previous year as Chief AI Officer.¹⁴ This repositioning is exemplary of a trend in established vendors putting document management and document AI into the same stack.

The custody surface can be broad. Doxis describes lifecycle management from intake to archive, routing into digital workflows and third-party systems, compliance tracking, ERP and CRM integrations, and platform certifications for security and compliance.¹² Its no-code application layer lets users build workflow applications on top of the record system. The same offering covers governance and review routing. The record environment includes files, users, roles, retention rules and process state.

Doxis strategically decomposes automated text capture into capture from email, scanner, and portal, classification for document type and routing, extraction of fields with or without a predefined schema and validation for formal accuracy, duplicates, and missing required details.¹⁵ The acquired layer adds a set of utils, such as conversion to structured formats, anonymisation, verification against trusted sources, fraud detection and review by a human in the loop as a dedicated module.¹⁶

The integration point is the transaction system around the record. Doxis offers business connectors for ERP, accounting, CRM and HR systems, vendor-specific SAP, Microsoft and Salesforce interfaces, and a universal ERP connector that can pass extracted invoice data into an ERP workflow.¹⁷^,18^,19 Those connectors sit at the boundary between custody and execution, letting the DMS keep the approved document record while SAP, Salesforce or another line-of-business system receives the data it needs to continue the process.

Web intake as custody work

Not all sources come as files. For example, a policy page, institutional FAQ, public regulation or vendor manual may enter the workflow through a URL. We have previously treated this as a source-interface problem.²⁰ Modern agentic workflows may choose a representation at access time, with Markdown, HTML, JSON, links and status fields preserving different classes of evidence.

As a comparison, legal scholarship treats URL evidence as an archive problem. A Harvard Law Review essay separates link rot from reference rot. Reference rot names the case where a URL still resolves but no longer contains the cited material, and the essay treats page capture at citation time as the remedy.²¹ Administrative workflows need the same separation. The URL identifies where the source was found, while the record is the captured snapshot that can be reviewed later.

Layer 2: Representation

A working system needs to preserve identity, page location, confidence, approval state and custody while the file inevitably changes shape. A derivative is the agent-readable representation generated from a record, usually Markdown, JSON, HTML, or other structured document formats. The agent usually works on the derivative rather than the canonical file, which gives the model a readable surface with both enough structure for reasoning and enough provenance for review.

Cloud APIs expose page mechanics

A hyperscaler API is a hosted document-analysis service from a large public cloud provider, such as Microsoft Azure, Google Cloud or AWS. The name comes from hyperscale computing, where infrastructure and software architecture scale as demand grows.²² Page mechanics are the concrete facts returned by this layer. They give the surrounding system an input contract and an evidence model. The input contract says which source files and output formats the service supports, while the evidence model ties extracted content back to page structure. A DMS or the run record in a prototype uses those facts to attach a derivative to the right source page or route a difficult page to another parser.

Among the reviewed cloud APIs, Azure AI Document Intelligence covers a broad product surface. It accepts PDF, images, Office formats and HTML, and can return either JSON with page polygons and character spans or Markdown through a documented output mode.²

// Azure layout response sketch
{
  "status": "succeeded",
  "analyzeResult": {
    "apiVersion": "2024-11-30",
    "modelId": "prebuilt-layout",
    "stringIndexType": "textElements",
    "content": "Payment due\nEUR 184.20",
    "pages": [
      {
        "pageNumber": 1,
        "width": 8.5,
        "height": 11,
        "unit": "inch",
        "words": [
          {
            "content": "184.20",
            "polygon": [4.12, 6.38, 4.78, 6.38, 4.78, 6.55, 4.12, 6.55],
            "confidence": 0.997,
            "span": { "offset": 16, "length": 6 }
          }
        ]
      }
    ],
    "paragraphs": [
      {
        "role": "sectionHeading",
        "content": "Payment due",
        "boundingRegions": [
          { "pageNumber": 1, "polygon": [0.92, 5.8, 2.1, 5.8, 2.1, 6.0, 0.92, 6.0] }
        ],
        "spans": [{ "offset": 0, "length": 11 }]
      }
    ]
  }
}

Azure output ties text spans to page geometry.

When plain Markdown cannot express tables with merged cells or multi-row headers, the service embeds HTML tables. It can also mark paragraph roles, section nesting and handwriting spans with confidence. A workflow can stay on this route when embedded text is enough. If it needs embedded Office images or workbook-level spreadsheet logic, the file has to go elsewhere.

Google Document AI is organised around processors, meaning configured parser or extractor endpoints. The examples relevant here are processor families. A form parser extracts key-value pairs, tables and checkboxes without a schema. A layout parser produces structure-aware chunks. Custom extractors take a developer-defined schema and can run through a generative foundation model, a trained custom model or a fixed template.

// Google processor object sketch
{
  "type": "CUSTOM_EXTRACTION_PROCESSOR",
  "displayName": "travel-expense-invoices",
  "name": "projects/123456/locations/eu/processors/a1b2c3d4e5f6",
  "state": "ENABLED",
  "processEndpoint": "https://eu-documentai.googleapis.com/v1/projects/123456/locations/eu/processors/a1b2c3d4e5f6:process",
  "defaultProcessorVersion": "projects/123456/locations/eu/processors/a1b2c3d4e5f6/processorVersions/pretrained"
}

A processor object gives the endpoint and version behind a configured extractor.

The useful planning parameter is the amount of labelled data each route expects. Google’s own table puts production quality at three documents for fixed templates, 10-100+ documents for custom models, and 0-50+ documents for foundation-model extraction depending on layout variation.³ This determines whether an administrative prototype can begin with a few sample forms or needs time for a preliminary labelling project.

Amazon Textract is especially explicit about page geometry in this group, with a narrower input and output surface. Its analysis response returns text, forms, tables, queries, signatures and layout as blocks, and each block can carry page number, bounding box, confidence and relationships to other blocks.⁴ Queries answer developer-supplied questions with answer blocks, while adapters customise those query responses after the team uploads representative documents, annotates query answers and trains the adapter.²³

// Textract query request sketch
{
  "Document": {
    "S3Object": {
      "Bucket": "expense-intake",
      "Name": "receipt-page-1.png"
    }
  },
  "FeatureTypes": ["TABLES", "FORMS", "QUERIES", "LAYOUT"],
  "QueriesConfig": {
    "Queries": [
      {
        "Text": "What is the reimbursable total?",
        "Alias": "reimbursable_total",
        "Pages": ["1"]
      },
      {
        "Text": "What is the invoice date?",
        "Alias": "invoice_date",
        "Pages": ["1"]
      }
    ]
  }
}

Textract queries turn business questions into named answer fields.

Mistral Document AI is closer to the representation role than to custody or review. Its primary output is a readable derivative of the page, with structure and hierarchy preserved in Markdown. Tables can arrive inline or as separate Markdown or HTML objects, and confidence is available at page or word granularity under a broad language-coverage claim.⁵ That is a good shape when the output is immediately passed to a language model, but a weaker choice when the next consumer is a database field that later has to be audited against the source pixel. A word-level confidence score on generated Markdown anchors provenance less tightly than a polygon on the original page.

// Mistral OCR derivative sketch
{
  "pages": [
    {
      "index": 0,
      "markdown": "# Receipt\n\nTotal due [tbl-0.html]\n\n![img-0.jpeg](img-0.jpeg)",
      "tables": [
        "<table><tr><th>Total</th><td>EUR 184.20</td></tr></table>"
      ],
      "images": [
        {
          "id": "img-0.jpeg",
          "top_left_x": 118,
          "top_left_y": 220,
          "bottom_right_x": 412,
          "bottom_right_y": 540,
          "image_base64": "..."
        }
      ],
      "dimensions": {
        "dpi": 200,
        "height": 2200,
        "width": 1700
      },
      "confidence_scores": {
        "average_page_confidence_score": 0.982,
        "minimum_page_confidence_score": 0.91,
        "word_confidence_scores": [
          { "word": "Total", "confidence": 0.99 },
          { "word": "184.20", "confidence": 0.96 }
        ]
      }
    }
  ],
  "model": "mistral-ocr-latest",
  "usage_info": {
    "pages_processed": 1
  }
}

Mistral centres the derivative on Markdown, extracted tables and image metadata.

The model-side literature explains why page mechanics remain necessary even when the parser is a vision-language model. OCR-first pipelines can lose layout and reading-order information before the model sees the page. Model-native readers remove the separate OCR step, but long documents still stress context windows, and small layout changes can change what the model reads.²⁴^,25 Newer OCR systems keep structure explicit by detecting layout and reading order first, then recognising content inside page regions.²⁶ Difficult pages move page mechanics inside the model pipeline before extraction.

Hard-tail parsing

Cloud APIs handle ordinary page description. The hard tail starts when a page needs more than text, tables and coordinates from a general layout API. Dense tables, charts, handwriting, nested sections and mixed scans are common in administrative work, and a few such pages are enough to collapse the pipeline.

The ParseBench comparison makes the hard-tail problem visible at the level of the model by testing whether parsers preserve source text, keep reading order and avoid omissions or hallucinations on enterprise pages.²⁷ In the published benchmarks, extra VLM capability and compute produced only marginal gains on the parsing metrics. Parser quality is better measured on document-parsing tasks rather than inferred from the model’s general rank.²⁷^,28

LlamaCloud decomposes the product surface into Parse, Extract, Classify, Split, Sheets and Index. The platform maps those products to LLM-ready text, schema-shaped JSON, document categories, concatenated-document separation, spreadsheet-like data and hosted vector search.⁶ The managed service acts as an escalation route for pages in which the baseline API does not preserve enough layout or visual structure.

Document-ETL research reaches the same result by treating the whole processing pipeline as an object of optimisation. Complex document tasks improve when the pipeline rewrites the task, decomposes the data and evaluates candidate plans before execution.²⁹ Parsing therefore encompasses orchestration concerns: the pipeline chooses the representation, routes page regions that need specialist handling and passes only acceptable results to extraction.

Open converters and local baselines

A converter is the component that turns the source file into a derivative that the rest of the stack can consume. A quick converter is useful when the first goal is to make a large source set readable, while a more structured parser is necessary when tables, reading order and layout objects will later be more thoroughly inspected. Research systems that construct knowledge from heterogeneous documents follow this split by separating layout, metadata and semantic layers, with human review deciding which extracted relations survive.³⁰

MarkItDown is a fast converter for LLM-readable text rather than a high-fidelity document renderer.⁷ It converts a wide intake range, from Office and PDF to images, HTML and archives, while preserving headings, lists, tables and links where it can. Scanned pages use a vision-model plugin, and Azure AI Document Intelligence supplies the cloud escalation path. Its value is early corpus access. A team can turn mixed files into rough Markdown quickly enough to inspect, search and prototype over them, then reserve structured parsing for the files whose tables, reading order or provenance need inspection.

Docling is the structured parser in this group. It parses each input into a unified document representation and exports Markdown, HTML, structured text or lossless JSON.⁸ It operates a distinction in which Markdown helps the agent read, and lossless JSON records the parser’s objects. A pipeline that stores both can answer later questions about a table cell or reading-order decision which a Markdown-only pipeline usually cannot.

OCRmyPDF and Tesseract define the local OCR baseline. OCRmyPDF wraps Tesseract to add a searchable OCR text layer to scanned PDFs, locally and deterministically.⁹ The baseline works for clean printed scans because it produces repeatable searchable PDFs, but it is the wrong tool for complex layout, tables and handwriting. It gives the pipeline a cheap first pass and the evaluator a control row for downstream paid layers.

The deterministic baseline has also gained a model-native neighbour, Surya, an open-source OCR toolkit that installs from the package index and can run through local inference backends.³¹ A local fast tier can now add model-native OCR before it reaches a cloud API.

LiteParse extends the local tier from OCR into parsing. It gives a pipeline a first-pass parser that can run locally, while failed pages escalate to LlamaCloud or another frontier parser.³² The local baseline can therefore include parser logic as well as OCR, with managed escalation reserved for pages that fail the local pass.

The remaining tools are specialised use cases around representation. Apache Tika belongs at intake, where email attachments and legacy repositories arrive in many formats, and Tika detects file types while extracting text and metadata across more than a thousand formats.³³ GROBID belongs to scholarly PDFs, where PDF-to-TEI, references and citation links are the needed derivative.³⁴ Pandoc belongs at publication, turning approved Markdown back into DOCX or PDF for circulation.³⁵ These tools cover boundary cases around the representation layer and leave layout-aware extraction to a dedicated parser.

Layer 3: Review

Review is where a proposed field becomes an institutionally accepted value. The parser supplies candidate evidence; the review layer gives it institutional standing by recording the review outcome under the governing source version.

Validation workbenches

Validation products make the review role into a concrete system interface. Rossum sends empty fields and low-confidence fields into a validation stage and points the reviewer to the relevant document area.¹¹ ABBYY Vantage treats human-in-the-loop review as the step used when validation rules fail or when a document class and extracted data need manual correction, and it ties those corrections to continuous learning and straight-through-processing analytics.³⁶ Instabase turns failed validations from a deployment into review tasks by file, run or packet, with queues, escalation groups and service-level targets.³⁷

Validation is packaged as an exception workbench. The reviewer typically receives a queue, a document viewer, a field editor, validation rules, assignment, and a return path into downstream systems. The review layer should therefore be evaluated through work objects as much as through extraction metrics. The useful ergonomics test for these systems is whether a low-confidence field becomes a traceable task with a source location, reviewer, decision and replayable output.

A sample implementation

A travel-expense workflow shows a full stack traversal at a small scale. The design choice is to separate responsibilities before choosing parsers. The DMS owns the case, evidence, policy version and approval trail. The agentic workflow reads those records, routes each source to a parser, creates field records, sends unsafe fields to review and writes the approved result back to the case.

This sample implementation uses an arbitrary DMS for custody, LlamaIndex for orchestration, LiteParse for the local parser route, LlamaParse for the escalation parser route, Apache Tika for uncertain intake metadata, DMS-attached derivative storage, a finance review queue and an ERP connector for the approved reimbursement payload. We treat the optimal stack as the configuration that preserves provenance and acceptance state at the lowest operational cost.

The workflow keeps three source classes: the case, the evidence and the governing policy. The hotel invoice and ticket screenshot are ordinary evidence. The receipt photo is the escalation candidate. The travel-expense policy is versioned governing material.

Evidence enters through ordinary administrative channels, usually an email attachment or self-service portal upload. The DMS creates the case record, while the intake edge may still receive forwarded messages, screenshots, zipped attachments or files with weak MIME metadata. Apache Tika belongs at that edge, before parsing, where file type and attachment metadata have to be established before a routing decision is made.

// Workflow record types
type WorkflowCase = {
  caseId: string
  dmsRecordId: string
  employeeId: string
  policyRecordId: string
  state: "submitted" | "in_review" | "approved" | "rejected"
}

type WorkflowSource = {
  sourceId: string
  role: "evidence" | "governing_policy"
  kind: "hotel_invoice" | "b2c_receipt" | "ticket_screenshot" | "travel_expense_policy"
  dmsRecordId: string
  fileName?: string
  version?: string
  custodyState: "submitted" | "approved" | "restricted"
}

type RouteDecision = {
  routeId: string
  sourceId: string
  route: "local_liteparse" | "managed_llamaparse" | "manual_reject"
  parser?: "liteparse" | "llamaparse"
  reason: string
  outputVersion?: string
}

type DocumentDerivative = {
  derivativeId: string
  sourceId: string
  routeId: string
  format: "markdown" | "structured_json"
  uri: string
  contentHash: string
}

type ExtractedField = {
  fieldId: string
  sourceId: string
  routeId?: string
  name: "vendor" | "date" | "total_amount" | "currency" | "policy_clause"
  value: string
  location: { page?: number; bbox?: number[]; section?: string }
  confidence?: number
  reviewState: "accepted" | "queued" | "corrected" | "reference"
}

type ReviewTask = {
  taskId: string
  caseId: string
  fieldIds: string[]
  trigger: "low_confidence_total" | "policy_conflict" | "total_mismatch"
  assigneeGroup: "finance_ops"
  state: "open" | "accepted" | "corrected" | "rejected"
}

type ApprovalPayload = {
  caseId: string
  approvedAmount: string
  accountCode: string
  approvalState: "approved" | "rejected"
}

Record types keep custody, routing, derivatives, review and approval separate.

Custody stays narrow in this example. The case is the parent DMS record. Evidence documents attach to it, while the policy remains an approved record referenced by version.

LlamaIndex makes the routing decision source by source.³² The hotel invoice stays on LiteParse because stable text positions are enough for extraction. The photographed receipt escalates to LlamaParse because the reimbursable amount may depend on skew, faint print, discounts and tax lines.³⁸ The route record gives the review layer the parser, reason and output version behind each field.

The two parser routes produce different derivatives, but the workflow treats both as records. Markdown gives the agent a readable surface for comparing the receipt, invoice and policy. Parser JSON keeps the layout objects a reviewer needs when a total or line item is questioned.

The field record is the unit the agent and reviewer can share. It keeps the extracted value with the source, page location, route id, confidence and review state. That is enough for the agent to compare the receipt total with the policy clause and for the reviewer to reconstruct the path that produced the value.

Review starts where the workflow cannot safely validate its output. Low-confidence totals, policy conflicts and total-line mismatches become review tasks for finance operations. Once a reviewer accepts or corrects the field, the ERP connector receives the approved amount, account and approval state.

Parser routing, review, and approved ERP handoff.

The sequence view shows the same separation in time. Tika types uncertain intake files before the DMS creates the case and receives the approval record. LlamaIndex routes sources to LiteParse or LlamaParse. Extraction emits field records, the review layer records corrections, and ERP receives only the approved payload.

Provenance keeps the agentic part tied to the record system. Source links and page locations show why a value was accepted. Confidence decides whether the value enters the queue, but the source relation makes the decision reviewable.³⁹^,40

Stack failure points

Failure points concentrate in representation and provenance. Tables, handwriting, dense layouts and mixed scan-and-digital bundles do not behave like ordinary text extraction. A reliable stack routes at page level, keeps simple pages on the local or lower-cost path, escalates difficult pages, and stops pages that lack enough evidence before extraction. Tables need a separate test set drawn from the institution’s documents, because recent parsing research separates page layout, table structure and region-level recognition instead of treating them as one text-recognition problem.²⁵^,26

The provenance failure is less visible during a successful run. A derivative can fall out of step with the record. The DMS record can move on while an agent keeps reading an older corpus, and confidence scores only route review because they do not prove a field is correct.⁴¹ A reviewer can correct a wrong amount or date only when the field still points to the source version and page region that produced it.

At some point, further parser accuracy gives diminishing returns. The more useful investment is a fast review path: the system identifies uncertainty, routes it to the right owner, and turns the decision back into maintained product state. Model accuracy can reduce the number of exceptions, but review design determines whether the remaining exceptions stay cheap and bounded.

Appendix: Competitor matrix by stack role

Tool	Role	Product category	Strongest position
Doxis	custody	enterprise content platform	system of record, workflow routing, retention, audit and review surfaces
Azure AI Document Intelligence	representation	cloud document analysis API	broad intake, page geometry, spans, confidence and Markdown output
Google Document AI	representation	cloud document extraction platform	schema-driven extraction, form parsing and foundation-model extraction
Amazon Textract	representation	cloud document analysis API	PDF and image intake, explicit geometry, confidence, forms, tables and queries
Mistral Document AI	representation	Markdown-native document API	page Markdown, HTML tables, word confidence and language coverage
LlamaCloud	representation	managed frontier parser	enterprise tables, charts and agentic parse/extract
Docling	representation	structured open converter	lossless document object plus Markdown export
MarkItDown	representation	fast open converter	rapid corpus conversion into LLM-readable Markdown
Unstructured	representation	document partitioning library	element partitioning with opt-in table structure
OCRmyPDF / Tesseract	representation	local OCR toolchain	deterministic searchable PDF/A and sidecar text
Apache Tika / GROBID / Pandoc	representation	format utility set	file-type extraction, scholarly TEI and approved Markdown export
Cloudflare crawl	custody	web capture API	site capture to Markdown, HTML or JSON with crawl status
ABBYY Vantage	review	validation workbench	human verification, correction workflow and continuous-learning analytics
Rossum	review	transactional validation queue	low-confidence and empty-field review tied to document context
Instabase	review	deployment review queue	failed validations become review tasks with queues and service targets
UiPath Document Understanding⁴²	review	RPA document automation platform	validation actions suspend and resume orchestration
Automation Anywhere Document Automation / Tungsten TotalAgility⁴³^,44	review	business automation platform	extraction, validation, routing and audit inside automation
Amazon Augmented AI⁴⁵	review	managed human-review service	human-review workflows around ML predictions and Textract

Tools grouped by their strongest stack responsibility.

Towards a Reliance Layer in Document Agents

Tue, 12 May 2026 00:00:00 GMT

Agentic document work implements agent systems that handle documents as inputs, working materials and outputs inside administrative or knowledge workflows.

Innovation in the domain has proceeded parallel to broader technological change around model and agent tooling. A community of builders, researchers, product teams and open-source maintainers is experimenting with newly open technical possibilities at a restless and at times frantic pace. The results of their tinkering are routinely shared in engineering writeups or social media posts. Such signals are fragmentary but analytically relevant as empirical records, before their operational findings harden into vendor categories or institutional procedures.

In this article we provide a snapshot of the state of the field over Q1 and Q2 2026 with three evidence classes. We read social media posts for frontier builder behaviour (emerging practice, tacit vocabulary, recurring operational problems) and consider arXiv papers for ongoing innovation in the literature (named methods, benchmarks, formal mechanisms). Finally, we use official docs, product posts and engineering writeups to track the pace of industry adoption.

Field signals in 2026 tend to show that model capability is not yet enough to make document pipelines institutionally reliable, with a surrounding layer of work accumulating around it as a remedy. Several frontier models shipped during the same period,¹ but reliability questions persisted across the release cycle.

Part I starts from six recurring problems in agentic document work and follows the field response to each one.

Procedure skills. Procedures are difficult to repeat if they exist only in prompts or tacit routines.
Attribution substrate. Text extraction does not by itself make document output checkable. Claims, fields and source locations have to remain attached to the extracted content.
Source interfaces. The document format has to trade off between stripping evidence and spending context on page structure.
File-backed state. Long runs need durable state because decisions, open questions and accepted sources otherwise disappear with the context.
Harness engineering. A model can propose dangerous actions if adequate checks, limits, or halting conditions are not enforced.
Reliance layer. A document output is not institutionally usable without a properly informed review.

While the discipline is still rapidly evolving, the first five developments already produce maintained and actionable workflow objects. Part II tackles the unresolved sixth object, and attempts to describe an artefact for making agentic document work institutionally reliable.

Part I: Field signals

Today’s agents are capable of autonomously taking a topic, gathering its sources, reading them, and writing a long referenced report while checking in with the operator only occasionally.² However, long reports tend to lose their thread, and later sections can forget what earlier sections established, thus collapsing the entire pipeline. A long document run is only as reliable as the conditions that hold around it.

In agentic document work, usable output depends on maintained run conditions (procedure, source access, durable state, external checks and institutional criteria). Across those conditions, the field is still working through problems and partial repairs.

1. Procedure skills

Builders increasingly move recurring document procedures out of throwaway prompts and into reusable procedures. A skill is a procedure set down once, versioned and shared like code, then loaded by an agent at the start of a task. Domain experts can package multi-year practice into skills that agents reuse across tasks, and vendors can release capabilities as installable skills as they do with built-in features.³ An ecosystem has since formed around skills, with an open skill format shared across multiple agent products and public registries, where a single widely adopted skill’s installs run to the hundreds of thousands.⁴

How much skill-writing transfers to a document-heavy organisation depends on how much of the organisation’s procedure is already explicit. A written procedure translates into a skill almost directly, and can be handed to an agent in already executable form, while a procedure that relies on tacit knowledge has to be extracted first. Organisations that already have well-documented procedures start their automation processes ahead.

Once skills are installed, they become part of the dependency surface. Public skill ecosystems already contain malicious payloads and insecure skills that expose secrets, embed hidden instructions, or fetch executable content at runtime.⁵ OWASP collects those and adjacent risks in its Agentic Skills Top 10.⁶ An organisation that installs a skill is installing executable behaviour, and owes the skill the scrutiny it gives any other software.

Alongside skills, connector protocols define how an agent reaches external systems, including file stores, databases, and services. Skills tell the agent how to perform a task, and connector protocols expose the systems the task can use. The practical example is Model Context Protocol (MCP), an open standard for connecting AI applications to external data, tools, and workflows.⁷ Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation, and later roadmap work describes protocol development through maintainers, working groups, and Specification Enhancement Proposals.⁸ This marks a clear division between shared infrastructure and institutional procedure. Connectors and parsers can often be bought off the shelf. Procedure is inherently local because it contains the organisation’s rules, exceptions, vocabulary, and acceptance thresholds.

2. Attribution substrate

Extracted text is usable only when the output still shows where each claim or field came from. For years document parsing was treated as preprocessing, the boring step before the interesting retrieval, but that order has now reversed. Infrastructure vendors are repurposing around document understanding, on the stated reasoning that the further agents push into knowledge work, the more decisions need audit trails back to their source documents.⁹

Parsing technology changed over the same period. Our field inquiry includes practitioner measurements where vision-language models beat conventional OCR without document-specific training on varied pages.¹⁰ A separate production guide estimates self-hosted VLM OCR at 700-1,000 $ for 10 million pages, enough to change the cost profile of archive-scale preprocessing.¹¹ The leading edge has shifted to small, specialised document models, with open-weight options that outperform far larger generalists on parsing benchmarks,¹² and production architectures standardise on two-tier routing, in which a fast local parser handles the bulk and only the genuinely hard pages escalate to a heavier model.¹¹

Extraction products changed accordingly. The frontier offering competes on attribution, with page references, bounding boxes and confidence scores aimed at keeping humans in the loop.¹³ The selling point is moving from parsing accuracy to review ergonomics. Production reports also tend to agree that the text layer produced by OCR is the input for everything downstream, and when transcription fails, the whole pipeline fails with it.¹⁴

3. Source interfaces

The first source decision is representational. The workflow chooses which version of the document enters context.

The field record shows three maintained source forms, web representations served from a URL, local source systems and derived views built over source material.

The first source is the web-served representation. Practitioners are increasingly looking for smaller, cleaner representations,¹⁵ and infrastructure can set that representation at two points in source access. Network operators such as Cloudflare act upstream when the same URL can answer different clients with different formats.¹⁶ Open-source crawlers and paid APIs act downstream, after the URL has become the starting point for a crawl or capture job.¹⁷^,18

Both moves place the format decision inside source access. A server can negotiate Markdown before sending the page, and crawl endpoints can return Markdown, HTML, raw HTML, links, metadata, status fields, headers or schema-shaped JSON without naming one canonical target.¹⁶^,17^,18 Each representation preserves different evidence. Markdown reduces boilerplate, HTML preserves page structure, JSON serves extraction, and link or status fields tell the agent what it can reopen, follow, or treat as a failed fetch.

The practitioner debate is about information loss. Compact text or diagrams save context, source-produced Markdown can be more faithful than an automatic HTML-to-Markdown pass, and stripped outputs can remove links the agent needs for its next crawl step.¹⁵^,19 If representation is chosen at capture time, a richer output can be used when the agent needs page state to follow references, while a simpler one can be used when source text is enough.

The second source is the local source system. Inside knowledge systems, an application mediates source access even when no web endpoint negotiates the representation. Raw files give the agent content, while the application can expose relations the file tree does not carry, including links, tags, tasks, metadata, permissions and search structures. The evidence is narrow. In the corpus, an Obsidian CLI test reports faster searches through the application’s maintained index, and Obsidian’s own CLI exposes search, tasks and vault reads as commands.²⁰^,21 The same product direction appears in document stores such as Google Drive and Box, whose MCP surfaces expose search, metadata, file content, permissions, extraction and governed access to agents.²²

A portable version of the same move appears in Google’s Open Knowledge Format. OKF represents curated knowledge as a directory of Markdown files with YAML frontmatter, so agents and tools can consume the same knowledge bundle without a new runtime, service, or SDK. A field signal around the release described the same structure as a living wiki that agents can query or edit.²³

The third source is the derived view. In this form, another system reads the source material first and exposes a prepared result the agent can query or call. DeepWiki indexes repositories into wikis with diagrams, source links and grounded Q&A, and its MCP server exposes those wiki operations as tools.²⁴^,25 In the literature, Doc2Agent turns API documentation into validated tool definitions that agents can call.²⁵

The shared pattern is that source access is maintained in the URL response, in the local application, or in a prepared layer over the material. For document agents, the source is the file plus the maintained access layer around it, including representations, relations, commands and derived views that help the agent find the right material and check what it found.²²^,25

4. File-backed state

The state problem appears when a long run has to preserve its decisions, open questions, and accepted sources after the conversation has moved on. Agent tooling and practitioner guidance have by now settled on solving this problem by moving state into files. The durable state lives in named Markdown files and project instructions that can be inspected and versioned with the rest of the workspace.²⁶ Practitioners support this operational framework by recording decisions and open questions as they work, so that the next session or agent may start with the appropriate context.

Subagents address the same drift problem while also making parallel research easier. Claude Code documents subagents as delegated workers with separate context windows, so high-volume work can stay outside the main conversation and return only a summary.²⁷ Published experiments go a step further and remove context management from the model altogether. A deterministic engine sits outside the model, compresses the history, and keeps a pointer to every original passage. That engine outperformed agents managing their own context at every length tested.²⁸

Tool documentation and empirical surveys now describe a recurring decomposition into memory files, working files and subagents, but the pattern is still provisional. Context files are widely used, and repository-level evaluations report mixed effects. Unnecessary instructions can lower task success while raising cost, so the useful state file is a maintained interface with selected decisions, open questions, accepted sources and update rules, not a larger context dump.²⁹^,30

The stable pattern is that context strategies survive when they are inspectable and rerunnable from disk, because inspected state can also be debugged, audited, and handed to the next session, or to the next model.³¹

5. Harness engineering

The control problem deals with model actions that another layer has to execute, check, limit, or halt. The scaffolding around the model has become known as harness engineering. In this arrangement, the model drafts each action, while the harness executes it, checks the result and applies the run’s limits on tool use, write access and approval.

Harness improvements can move capability at the system level without changing the model: a system’s benchmark results may improve when its harness changes while holding the model constant.³² OpenAI describes the dependence between agent performance and the working environment at repository scale. Early Codex progress slowed because the environment lacked the tools, abstractions and internal structure the agent needed, so the team moved engineering effort into repository structure, feedback loops, validation and guardrails around Codex.³³

How long an agent can run unattended depends in part on whether the agent can check its own work.³⁴ Some practitioners now package that review loop as a reusable skill, which runs a reviewer over the work, applies the findings, and repeats until the reviewer returns clean.³⁵

The harness argument has also moved upward into model-adjacent systems. Claude Code’s dynamic workflows let Claude write a task-specific harness around the run,³⁶ and engineering accounts treat tool loops, compaction and iterative verification as part of the operating environment rather than wrapper code alone.³⁷ The scaffolding for short contexts became less central, and in its place came memory policies for runs that span days, coordination between agents, and enforcement hooks that block destructive operations and require an approval before anything ships.³⁸ The centre of gravity now sits in control, in the questions of who decides, what gets checked and what may happen when the agent is unattended.

Harness planning is also contested, as some practitioners read heavy upfront plans as waterfall development reborn, where the full design is fixed before any work begins.³⁹ A less disputed claim is that harness design should follow failures observed in use, while verification should precede any agent action that changes a file, sends an answer, or enters production.³³^,40

6. Reliance layer

Reliance begins after the model has produced an answer, when the institution still has to decide whether the output can enter its work.

No settled artefact in the field yet combines evidence, validation, review responsibility, approval scope and permitted use. Adjacent solutions exist, but they still scatter the work across a multitude of objects (eval suites, production traces, review queues, approval gates, provenance records, policy cards, audit trails, evidence packages etc⁴¹). None plays the same role that skills play for procedure, parsers for attribution, context files for state and harnesses for control.

The gap is already visible in production, where generated answers can reach users before validation, review, and regression tests catch the relevant failures.¹⁴^,40

A generated explanation can make an answer look finalised even when no external check has occurred. Self-explanation research treats faithfulness as a property measured outside the explanation, because the model’s account is another generated output with no access to the process it claims to describe.⁴² Code shows the distinction because the generated artefact can be tested outside the model. Scientific-code benchmarks compile, execute, time, and review generated code against expected behaviour and domain conventions.⁴³ Document output has no equivalent compiler, so the outside check has to be a record attached to the result.⁴¹^,44

Evaluation suites add a quieter risk. They describe the world at the moment their cases were written. A prompt can pass that suite, ship, and keep passing after policies, sources, or user behaviour change, even while production answers degrade.⁴⁵ The field response is to keep evals alive and prompts versioned, with production traces feeding new cases and products proposing fixes.⁴⁰

Production reports put substantial work into exception routing, validation, review queues, and audit documentation.¹⁴ The expense does not stop at inference. The apparatus that makes generation usable needs its own budget.

The candidate artefacts point to the same requirement. A usable output needs a point-of-use record of its sources, checks, review, and approved scope.

Part II: The case for a reliance artefact

Part I shows five conversions from run behaviour into maintained workflow objects. A procedure becomes a skill file, source access becomes an interface, attribution becomes a parsing substrate, state becomes files, and control becomes a harness. Each conversion gives later cases something explicit to inherit.

The missing maintained object

The remaining condition deals with institutional permission around the output. The field already contains records that cover part of the job, including evidence packages, policy cards, gates, production traces, and audit trails.⁴¹ These scattered artefacts, however, have not yet hardened into one maintained artefact that travels with the output and states its permitted use.

Field signal	Workflow condition	Maintained artefact
Procedure skills	procedure	authored task files and local operating rules
Attribution substrate	source attachment	extraction pipelines with source locations
Source interfaces	source access	approved source sets and served representations
File-backed state	continuity	context files, decisions, open questions, and history
Harness engineering	control	execution, validation, permissions, and stopping rules
Reliance layer	institutional use	TBD

Five conditions already have inherited artefacts, while institutional use remains the open slot.

The table sets a boundary for the proposed artefact. A reliance-specific object doesn’t replace the artefacts named in the first five rows, rather it points to them and records the permitted use that follows from their evidence.

The distributed validation target

Code is the easier reliance case because generated work has an executable target. A generated patch can compile, run, fail tests, or violate conventions, and scientific-code benchmarks use those external checks instead of the model’s own explanation.⁴³ Document work has to build the check out of workflow records. Production document systems route low-confidence extractions or missing keys to human review, and confidence scores can decide whether a field is accepted automatically or flagged for review.⁴⁴ A report, extraction, or decision has to show source evidence, satisfy policy criteria, and enter a system of record through a review decision.

Business process research already treats workflows as designed and analysable objects rather than loose sequences of tasks.⁴⁶ Agentic document work inherits that premise, but the workflow now includes model-facing machinery that determines how sources are read, how state persists, and how validation records are written.⁴⁷ That makes the workflow itself a review target. Reusable rules create their own drift risk. A case can pass today under conditions that no longer hold for the next source set, policy update, or approval path.⁴⁶^,48

Trace density and missing judgment

Code changes usually carry diffs, review comments, test results and issue history. Those records give agents a dense trace environment because they preserve both the outcome and the reasons a change was accepted. Document-heavy institutions often lose such a substrate. The final form, answer, or decision may be archived, while the source passage, validation result, or reviewer judgment may sit in another system or disappear altogether.

Trace density is the ratio of recorded reasoning to recorded outcomes in a domain.⁴⁹ According to this metric, code has high trace density because the accepted change is usually stored with the evidence that made it acceptable. Administrative archives can show the opposite pattern. They keep forms, approvals, and filed answers, but often separate those outcomes from the reasons and checks that made them acceptable.

We argue that the reliance layer should be hardened by increasing trace density around the output. A derivative can record its source, version, transformation, and actor.⁵⁰ An attributed claim can point to the source passage that supports it.⁵¹ A reviewed field can record who checked it, which validations ran, and what was approved.⁴⁴ These records do not recover all judgment, but they give later review a concrete stack trace to inspect.

The permitted-use record

Trace can support review, but reliance starts only when the institution approves a bounded use. The institution still has to decide whether a reviewed output remains a draft, enters a file, or supports an external action such as payment or publication.⁵² An evidence account is the broad record behind that decision. It ties the output to source evidence, validation state, review state, and unresolved exceptions. The output-attached part of that account is the reliance artefact, or reliance record. It travels with one output version. Its central field is the permitted use, which states what the institution may do with the output and points back to the evidence that justifies that use.

Illustrative reliance-record fields map the output to evidence, authority, versioned policy and reopening checks.

Existing work already covers parts of that record. EviBound treats evidence as a gate on generation, PROV-AGENT records agent provenance, and Policy Cards specify policy and evidence requirements for use.⁴¹ These components make a reliance artefact plausible, but they do not yet do its job. None sits with one output version and states the approved use together with the source, policy, or workflow changes that reopen review.

Revision loop for drift

Sources, policies and approval criteria are moving, ever-changing targets, which calls for continuous revisions of the reliance artefact. In an attempt to capture the temporal logic of such adjustments, we may split the agentic document workflow into three repeatable operations.

The run produces one output and its trace. Verification checks that output against source evidence, permissions and review criteria. Revision changes the workflow version that new runs will inherit. Adjacent software practice and self-adaptive-systems research already use linked feedback loops for runtime control, and the Q2 2026 field record makes the same shape visible in agentic document work.⁴⁸

The field examples supply different parts of that loop. Production document pipelines make run and verification visible through exception routing, validation, review queues and audit documentation.¹⁴ Agent-evaluation guidance supplies revision when production traces become new cases for later runs.⁴⁰ Harness accounts show the same revision pattern at repository scale, where failures trigger changes in tools, abstractions, feedback loops and future controls.³³

Such a cyclical approach may be used to repair reliance drift. A review finding can become a new eval case, a validator, a source rule, a procedure change, or an update to the reliance artefact. The later case is then checked against a failure the earlier case exposed.⁴⁰ Human judgment remains inside the cycle in two places: a reviewer can approve one output during verification, and the institution can revise the rules that govern future cases.

Review findings become workflow revisions, and later cases run against the revised conditions.

A reliance process is governed over time. The institution accepts one output, records why, and updates the workflow when the record exposes a gap. Governance enters the loop when a review finding changes the conditions future runs must satisfy.

Conclusion

Part I followed a migration from run behaviour to workflow objects. Workflows around procedures, source access, attribution, state and control become usable when teams can inspect and revise them. Part II deals with the remaining gap at the point where a reviewed output becomes something an institution may use. The next field signal is systems moving reliance decisions from review practice into fully formed workflow infrastructure.

Frontier model releases, spring 2026. ↩
Naskręcki, Feb 2026; Zhao, Feb 2026. ↩
Agent Skills, 2026. ↩
Vercel, Jan 2026; skills.sh, 2026. ↩
Snyk ToxicSkills, Feb 2026. ↩
OWASP Agentic Skills Top 10, 2026. ↩
MCP docs, 2026. ↩
Soria Parra, Dec 2025; MCP roadmap, 2026. ↩
Liu, Jun 2026. ↩
Dasanaike, Mar 2026. ↩
Dubrov, Mar 2026. ↩ ↩²
OmniDocBench, 2026. ↩
Liu, Feb 2026. ↩
Alan engineering, Mar 2026. ↩ ↩² ↩³ ↩⁴
Man, May 2026. ↩ ↩²
Cloudflare docs, 2026. ↩ ↩²
Crawl4AI CrawlResult docs, 2026. ↩ ↩²
Firecrawl crawl docs, 2026. ↩ ↩²
Ubl, Feb 2026. ↩
Cincotta, Feb 2026. ↩
Obsidian CLI docs, 2026; Newton, Feb 2026. ↩
Google Drive MCP docs, 2026; Box MCP tools docs, 2026. ↩ ↩²
Google Cloud OKF, 2026; Haynes, Jun 2026. ↩
Cognition, May 2025; DeepWiki docs, 2026. ↩
DeepWiki MCP docs, 2026; Doc2Agent, 2025. ↩ ↩² ↩³
Claude Code memory docs, 2026. ↩
Claude Code subagents docs, 2026. ↩
Ehrlich and Blackman, 2026. ↩
Galster et al., 2026; Gloaguen et al., 2026. ↩
Yang et al., 2026. ↩
Daugherty, May 2026. ↩
LangChain, Feb 2026; Agentic Harness Engineering, 2026. ↩
OpenAI, Feb 2026; Böckeler, Apr 2026. ↩ ↩² ↩³
kepano, Feb 2026. ↩
Steinberger, May 2026. ↩
Anthropic, Jun 2026. ↩
Willison, 2026. ↩
Osmani, May 2026. ↩
Zechner, May 2026. ↩
Anthropic engineering, 2026; LangSmith Engine, May 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵
EviBound, 2025; PROV-AGENT, 2025; Policy Cards, 2025. ↩ ↩² ↩³ ↩⁴
Madsen et al., 2024. ↩
Tian et al., 2024; Zhang et al., 2026. ↩ ↩²
Amazon A2I Textract docs, 2026; Microsoft Document Intelligence confidence docs, 2026. ↩ ↩² ↩³
elvis, Mar 2026. ↩
van der Aalst and van Hee, Workflow Management: Models, Methods, and Systems, MIT Press, 2002. ↩ ↩²
Popova et al., 2013. ↩
Arcaini et al., 2015; Böckeler, 2026. ↩ ↩²
Koratana, Mar 2026. ↩
W3C PROV Overview, 2013. ↩
Schreieder et al., 2025. ↩
NIST AI RMF Core, 2023; Cobbe et al., 2021. ↩

Requirements Distillation in Regulatory Technology

Sat, 25 Apr 2026 00:00:00 GMT

The Regulatory Problem

Mapping source authority onto product architecture is the central problem in regulatory requirements work.

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 are actionable only after those two descriptions are joined into one product 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, the source otherwise loses track of why it holds the requirement and when it should be reviewed.

These problems meet at 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 successful 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.

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

What we may call regulatory distillation is the conversion of a regulatory and institutional corpus into accepted product state. 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 then evaluated against the target architecture before it is projected into dedicated engineering, sales, support or leadership views.

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.

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 projections from the same product state into different operating contexts. A DMS is a good target for the readable projection, as long explanations, source summaries and cross-team guidance need digestible sources to rely on.

As the product state evolves, the need for a single source of truth 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 (and often it is very costly to amend), 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 need 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. The simplest, most inexpensive solution is 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). 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 product 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 protects product state current 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 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, inevitably, weaker enforcement. 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.⁵ 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.

Placet Experiri

A Stack View of the Document Processing Market

Criteria cut across markets

Layer 1: Custody

DMS custody and workflow

Web intake as custody work

Layer 2: Representation

Cloud APIs expose page mechanics

Hard-tail parsing

Open converters and local baselines

Layer 3: Review

Validation workbenches

A sample implementation

Stack failure points

Appendix: Competitor matrix by stack role

Footnotes

Towards a Reliance Layer in Document Agents

Part I: Field signals

1. Procedure skills

2. Attribution substrate

3. Source interfaces

4. File-backed state

5. Harness engineering

6. Reliance layer

Part II: The case for a reliance artefact

The missing maintained object

The distributed validation target

Trace density and missing judgment

The permitted-use record

Revision loop for drift

Conclusion

Footnotes

Requirements Distillation in Regulatory Technology

The Regulatory Problem

A Software Fiscal Machine

Regulatory Distillation

Text Without State

Projections From One Model

Retrieval Leaves State Unresolved

Change Propagation

Footnotes