The Live and Breathing Essay

The frontend is an ordinary web page, but with two twists:

• The page is generated from the mesh and never edited by hand. Editing the rendered prose creates a second copy of a statement that the mesh does not know about, and nothing then determines which copy is authoritative.
• The page carries a currency date and a diff. The date records when the document was last tested against its evidence, not when it was last written. The diff shows a returning reader what changed. The release path has already computed that diff for the reviewer, so displaying it costs almost nothing.

The 'mesh' is basically the data skeleton that sits behind the essay. Every statement lives in it as its own data object, and each one carries the metadata a machine needs to work with it, an identifier of its own, the source it rests on, the date it was last tested against that source, and the subject it answers for. Think of it as a graph.

JSON is the most viable format of this graph. See below example.

{
  "statements": [
    { "key": "enf-014",
      "source": "gpdp-2026-04",
      "date": "2026-04-02",
      "subject": { "topic": "enforcement",
                   "jurisdiction": "IT" },
      "text": "Regulators act under existing privacy law."
    },
    { "key": "gpm-021",
      "source": "oj-l-2024-1689",
      "date": "2025-08-01",
      "subject": { "topic": "general purpose models",
                   "jurisdiction": "EU" },
      "text": "Model providers carry transparency obligations."
    }
  ],

  "sources": {
    "gpdp-2026-04": {
      "title": "Provvedimento 2 April 2026",
      "url": "https://example.org/gpdp/2026/04" },
    "oj-l-2024-1689": {
      "title": "Regulation (EU) 2024/1689",
      "url": "https://example.org/eu/2024/1689" }
  },

  "manifest": [
    { "id": "gpdp",
      "url": "https://example.org/gpdp/feed.xml",
      "added": "2026-01-11" },
    { "id": "oj-l",
      "url": "https://example.org/eu/oj/feed.xml",
      "added": "2026-01-11" }
  ],

  "ledger": ["9f2a41c8d6e0b537",
             "1c7d90ab34f6e2d1",
             "4e88b0195ac7f6d2"],

  "routing": {
    "enforcement / IT":            "enf-014",
    "enforcement / EU":            "enf-014",
    "general purpose models / EU": "gpm-021"
  },

  "residual": [
    { "hash": "6b18e5f2a90c4d73",
      "date": "2026-06-19",
      "subject": "insurance / SG",
      "note": "Mattered, and no statement owns it." }
  ]
}

The algorithm should:

• Collate. Pull everything the manifest allows since the last run. Fetching and parsing only, with no model involved.
• Filter. Drop anything already in the intake ledger, then test whatever survives for whether it changes something the document currently asserts. Most items are discarded here, because most consultations, speeches and reports change no obligation. Where exactly you draw that line is an editorial decision, and it belongs in this step rather than further down. A draft law that is plainly going to pass may well be worth keeping.
• Route. Resolve each survivor against the routing map. A subject has one home statement, so a subject never resolves to two. An item usually carries several subjects, so an item can still reach more than one statement. Cap that fan out, at three in the running implementation, and read an item that hits the cap as a sign it is really a subject the document does not cover yet.
• Distil. Send the affected statement, and only the affected statement, to be amended against the item that reached it.

This component is configuration rather than code. A cron expression, a workflow schedule or a hosted trigger will run the algorithm on a clock.

Without the scheduler nothing starts a run and the document returns to manual maintenance.

A minimum viable approval mechanism performs five functions.

• Hold the draft. Write the proposed change to an address the site cannot serve. Enforce that with the address rather than a flag on the record, because a flag is a rule the publishing code has to keep obeying and one bug defeats it.
• Notify the reviewer. Send the draft to somewhere the reviewer already looks. A draft that waits for somebody to remember to check on it will sit there past the point at which publishing it was worth anything.
• Present a word level diff. Show the proposed text marked up against the published text. A clean result reads as finished and gets approved without much scrutiny. A diff presents each change as a decision.
• Take a decision on each change separately. Accept, reject, or edit and then accept. Batching removes the point of the review, because a reviewer who has to take nine changes in order to get one stops reading them. The third option matters because a proposed change is often correct in substance and wrong in wording, and without it the choice is between publishing wording you would not have written and rejecting a correct update.
• Write and archive. On acceptance, write the accepted text to the mesh and stamp the statement with the date. Store the draft and the decision taken on each change, including drafts rejected in full. That archive is the record of what the system proposed and what a person allowed.

The approval mechanism can come in various forms, including:

• A pull request. The run opens a branch and a pull request. The diff view is the redline, line comments and commits onto the branch cover editing, review history is the archive, and merging is the acceptance. No interface code at all, if the document already lives in a repository.
• An email. The run sends the diff as an HTML email with an accept link and a reject link, each a signed single use URL. This suits a reviewer who is not technical and reads on a phone. The whole draft is accepted or rejected as one, since a link carries a single decision.
• A chat message. The run posts the diff into Slack or Teams with accept and reject buttons. Same shape as email, faster to answer, and the channel history is the archive.
• An MCP server. MCP is a standard way of handing an AI assistant a set of actions it is allowed to take on your behalf. Expose the pending draft, the redline, and the accept and reject calls as those actions. The reviewer then works inside whatever assistant they already use, and can ask what a change is based on and dictate a rewording in the same conversation before deciding.
• A dashboard. A page listing pending drafts, rendering the redline and taking a decision on each change individually, with an editor for rewording. The most work to build, and the only option here that gives both per change decisions and inline editing without a repository workflow. This is what runs in production, and 3.5 shows it.

A change is written to the mesh only after a person accepts it. The frontend rebuilds only then, carrying the date of that decision.

Side note. This component is optional. Connect the algorithm's output directly to the mesh and the document updates itself with nobody in the loop, which is a reasonable configuration where a wrong statement costs little and gets corrected on the next run. Include the approval mechanism where a person has to be accountable for what the document says. The running implementation includes it because the essay states what the law requires.