The Live and Breathing Essay
I built an essay that can rewrite itself to stay evergreen. Here's how it works.
Section 1 · Introduction
Most written content is published once and then left alone. A client update, a country guide, a market outlook or a running news story is accurate on the date it is issued, and it becomes less accurate as the subject moves on. Keeping it current and evergreen is a manual task. Somebody has to reread the piece against what has happened since and revise the lines that are no longer true or out-of-date.
This paper proposes a solution, called the live and breathing essay. It is live because the document stays wired to the dataset it was written from, so it keeps getting tested against new evidence instead of being left alone. It is breathing because that test happens on a rhythm.
An implementation of this architecture runs on the Global AI Regulation Tracker, under a tab called Enforcement Trends. The page reads as an ordinary essay. But behind the scenes it is rendered from a JSON file, which is a plain text file laid out so a machine can easily process and manipulate it, and in that file every statement in the essay is stored as its own record. Once a week a scheduled job checks the tracker dataset for new entries and proposes revisions to the statements those entries affect, for me to accept or reject.
Video 1. Left hand side is the tracker, showing the essay. Right hand side is the admin dashboard I built for curating and managing updates to the tracker (including the essay).
Contents
Introduction
The architecture
2.1 The frontend essay
2.2 The backend mesh
2.3 The algorithm
2.4 The scheduler
2.5 The approval mechanism
Implementation walkthrough
Component to stack reference
Conclusion
Section 2 · The architecture
The idea is to treat an essay like an application. At the core are five components:
the frontend essay a reader is served,
the backend mesh that holds every statement in it,
the algorithm that works out what has changed and rewrites only the part affected,
the scheduler that runs the algorithm on a clock, and
the approval mechanism a person uses to accept or reject each proposed change before it is published.
2.1 The frontend essay
The page that the reader sees.
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.
2.2 The backend mesh
The data skeleton behind the essay.
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." }
]
}Listing 1. An example mesh, cut down to two statements. The fields above sources are rendered to the page and the structures below it are not.
statements The prose a reader is served, one object per statement, each carrying its key, its source, its date and its subject.
sources The evidence the statements bind to, held once and referred to by identifier, so several statements can rest on the same instrument.
manifest A declared list of everything the system is allowed to read. Anything not on the list is never read, so adding a source is an explicit change with a record.
ledger A record of everything already taken in, stored as a content hash of each item rather than a position in a feed. A content hash is a short fingerprint computed from the item’s own text, so the same item always produces the same fingerprint and a changed item produces a different one. A position assumes the feed is stable and ordered, and it fails without any error when it is not. With hashes, running the job twice returns the same answer as running it once, and what counts as new is whatever is not already in this list.
routing Which statement answers for which subject. This is the map the algorithm resolves against. Write it by hand while the document is small, or derive it from what each statement already cites once it is not. Either way it has to be rebuilt when statements are added or removed, and a statement that changes home takes its future updates with it, so a rebuild is a change worth seeing rather than a detail.
residual Where items land when they matter but resolve to no heading. Several items accumulating on one subject indicates that the document has no heading covering that subject.
2.3 The algorithm
The process that collates and filters new updates, and works out what parts of the essay need to be revised.
The algorithm should:
Scrape. Pull updates from the web, including official sources and secondary news sources where permitted.
Filter. Filter the updates for relevance and authoritativeness to your essay .
Route. Work out specifically which statements in the essay are affected by each update against the routing map.
Distil. Distil the drafting revision to the relevant statement, and apply the change.
2.4 The scheduler
A clock that runs the algorithm automatically.
This component is configuration rather than code. A cron expression, a workflow schedule or a hosted trigger will run the algorithm on a clock.
2.5 The approval mechanism
The interface a person uses to accept or reject each proposed change before it is published.
A minimum viable approval mechanism performs five functions.
Notify the reviewer.
Present a word level diff. Show the proposed text marked up against the published text.
Take a decision on each change separately. Accept, reject, or edit and then accept.
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 I used.
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.
Section 3 · Implementation walkthrough
Everything above describes the architecture. In this section, I will walk through how this architecture is implemented on Google Cloud to power the Enforcement Trends essay on the Global AI Regulation Tracker. The frontend essay is served by Firebase Hosting, the mesh is one object in Cloud Storage, the algorithm is a Cloud Run service, the scheduler is a Cloud Scheduler job, and the approval mechanism is an admin dashboard I built and host separately from the site.
essay.json it reads. Cloud Scheduler starts the run, thirty eight entries are collected, and works out that thirty seven of them do not affect the essay, but one does. The Cloud Run service proposes a revision to the affected statement and stops. You accept it in the dashboard, one row in essay.json is written, and the page is rebuilt with the date it was checked.3.1 The frontend essay
Enforcement Trends is an essay about how AI regulation is actually enforced around the world, including an insight into which areas or issues are more heavily scrutinised by regulators than others or whether there are differences in AI enforcement actions across markets. The essay is generated from the tracker’s own dataset, and is updated each week against the entries added to the tracker in that week.
The date on the page is the date the essay last changed.
3.2 The backend mesh
The page is rendered from one JSON file in a Cloud Storage bucket. Below is an excerpt of the live file, cut down to a single insight and with the long values elided. Each field in it does one job.
{
"schema_version": 2,
"generated_at": "2026-08-02T17:04:49.920Z",
"insights": [
{
"id": "fa_personal_data",
"type": "observation",
"heading": "Privacy, data protection and cyber dominate …",
"body": "<p>Privacy, data protection and cyber account …",
"examples": [
{ "country_code": "IT",
"label": "[20 December 2024] Italy's data protection …",
"href": "https://www.gpdp.it/home/docweb/…" }
],
"route": {
"scope": "thematic",
"categories": ["Data Privacy & Protection",
"Cybersecurity", "…"],
"jurisdictions": ["IT", "EU", "BR", "CN", "AU", "…"]
},
"provenance": {
"input_hash": "ead4a8d2fe7e1267592b3efa268d84fb",
"generated_at": "2026-08-02T17:01:51.352Z",
"model": "gpt-5.5"
}
}
],
"dataset": {
"entry_count": 4529,
"jurisdiction_count": 238,
"entry_hashes": ["a3a49e3706d3c698dcb8d5af60e255cd", "…"]
},
"backlog": {
"unrouted_hashes": ["6a40c1bdea47c5cd19c088c946f17d34", "…"],
"by_category": {
"Civil Rights & Liberties": [
"f9553ab247ab0ba5aaccf3f03a12f926", "…"]
}
}
}Listing 2. An excerpt of the live essay file, one insight of ten, with long values elided.
Core fields
id(Unique ID): A fixed identifier so other systems and maps can target an insight directly. This allows you to reorder the essay without breaking code.type(Insight Type): Shows whether the point is an observation (what current data says) or a prediction (where things are heading), as predictions update under different rules.heading&body(The Text): The rendered title and text readers actually see. They are generated outputs, so no system logic depends on them.examples(Sources): The source evidence. Each contains a country code, summary, and direct link so citations resolve automatically without manual checks.route(The Subject): Maps categories to insights so the code automatically routes incoming data to the correct place.
Metadata and system tracking
provenance.input_hash(Input Fingerprint): A digital fingerprint of the source data used to create the insight, tracking if the underlying data has changed.provenance.generated_at(Check Date): The timestamp showing when this specific insight was last checked against its sources.provenance.model(AI Model): Records which AI model wrote the insight for auditability.dataset.entry_hashes(Intake Ledger): A master list of fingerprints for all previously processed entries to prevent duplicate processing.backlog(Unassigned Items): A holding area for entries that didn’t match an existing insight. A growing category here alerts you that a new insight needs to be created.
3.3 The algorithm
The four steps of 2.3 run in one Cloud Run service called updatebigpicture. Cloud Run holds a container that starts when something calls it and stops when it finishes, so the service costs nothing between runs. Here is what one run does.
Read both sides. Pull the whole tracker out of the database and the current essay out of Cloud Storage.
Find what is new. Hash each tracker entry from its label and its link, and subtract the hashes already recorded in the essay. An empty difference ends the run.
Throw away what does not matter. Send the new entries to a cheap model in batches of forty and ask one question of each. An enacted law, a binding rule, a fine, a ban or a significant ruling counts. A consultation, a technical amendment, a speech, a report or a blog does not. Nothing surviving also ends the run.
Send each survivor to its insights. Routing happens in code. Each category has one home insight, chosen by how distinctive that category is to it, with a short override table where my editorial intent beats the statistics. An entry carrying several categories can therefore reach several insights, capped at three, and one that fits nowhere goes to the backlog. The map is rebuilt from the current set of insights on every run, so accepting a draft that adds or removes an insight can move a category to a different home.
Rewrite only what was reached. An insight with nothing routed to it, and with none of its cited entries missing, is left untouched. The rest go to a stronger model one at a time, each with only its own text and the entries routed to it, under an instruction to add rather than redraft and to justify every deletion from the data.
Check what comes back. The chart the model returns is thrown away and the existing one is carried over, so no figure in the essay is ever model authored. Every citation it returns is looked up against the collected entries by link.
Write to a draft, never to the live file. The output is saved as
essay.pending.json. The liveessay.jsonis untouched until I accept the changes in the dashboard.
Over two months the service handled a few dozen requests and sat idle the rest of the time, and a run takes minutes rather than hours.
updatebigpicture service, with two months of request count and latency. The service is idle between runs and is invoked by the scheduler in 3.4.3.4 The scheduler
The scheduler is Cloud Scheduler, a managed cron service. You give it a schedule, a target to call and a way to authenticate, and it makes that call on time whether or not anything else is running. There is nothing to deploy and nothing to keep alive, and a job is one row in a console.
The job is bigpicture-weekly. It runs on 0 3 * * 1 in Australia/Melbourne, which is three in the morning every Monday, and it calls the service in 3.3 with a signed token the service checks before it does anything. It ran on 3 August and the next run is 10 August.
bigpicture-weekly, enabled, weekly, with its last run and next run. The second job in the list is unrelated to the essay.3.5 The approval mechanism
The approval mechanism is a simple private dashboard which has write permissions to essay.json.
When I open it, it loads essay.pending.json, loads the live essay.json, and computes a word level diff between the two. What it shows me is the essay with insertions and deletions marked in place. Each marked run of words is a separate decision, and the default on every one is accept.
Accept. The dashboard merges the accepted runs into the live essay, writes the result to
essay.json, copies the draft and the full set of decisions into a timestamped file underbigpicture/history/, and deletes the draft. Writingessay.jsonfires a storage trigger that recomputesessay.diff.json, which is what the show what changed toggle on the page reads.Reject. The draft is archived to the same history folder with an empty set of decisions and then deleted. The live essay is not touched, and the next scheduled run starts again from the current live version.
Edit. The same view is an editor. I can rewrite any sentence before accepting it, so a change that is right in substance and wrong in wording does not have to be rejected.
The review is checked against a hash of the draft it was opened on. If a scheduled run produces a new draft while I have the old one open, accepting fails and tells me to reload.
Section 4 · Component to stack reference
Here is how you can implement the live and breathing essay on other stacks.
1. The frontend essay
Claude: An artifact, or a repo published to Pages.
ChatGPT: A Canvas, or a repo published to Pages.
Google Cloud: Firebase Hosting.
AWS: S3 behind CloudFront.
Azure: Static Web Apps.
2. The backend mesh
Claude: JSON files in a Project.
ChatGPT: JSON files in a Project.
Google Cloud: JSON in Cloud Storage, or Firebase Realtime Database.
AWS: JSON in S3, or DynamoDB tables.
Azure: JSON in Blob Storage, or Cosmos DB containers.
3. The algorithm
Claude: A Skill for the method, connectors for the sources, drafts to a repo.
ChatGPT: Project instructions for the method, Actions for the sources, drafts to a repo.
Google Cloud: Cloud Run, drafts to a second Cloud Storage file.
AWS: Lambda and Bedrock, drafts to a private S3 prefix.
Azure: Azure Functions and Azure OpenAI, drafts to a private Blob container.
4. The scheduler
Claude: Scheduled tasks.
ChatGPT: Scheduled tasks.
Google Cloud: Cloud Scheduler.
AWS: EventBridge.
Azure: A timer trigger on the function.
5. The approval mechanism
Claude: A pull request, which is a held draft, a redline and a decision at once.
ChatGPT: A pull request, or the Canvas diff view.
Google Cloud: A review console on Cloud Run, writing to Cloud Storage.
AWS: A review page on Amplify or API Gateway, writing to S3.
Azure: A review page on Static Web Apps, writing to Blob Storage.
Section 5 · Conclusion
The live and breathing essay is a solution to keeping written content evergreen. The framework can be applied to almost anything written related. Here is where I would start looking.
News. A running explainer on a live story, against the wire reports and official statements as they land.
Law. A regulatory tracker or a country guide, against the register of instruments it cites.
Finance. A house view or a sector outlook, against the prints and filings it rests on.
Healthcare. A treatment guideline, against the trial results and label changes underneath it.
Insurance. An underwriting manual, against the loss data and the rules it has to follow.
Software. Documentation and security advisories, against the release notes and the vulnerability feed.
Government. A policy explainer, against the statistics it quotes.
Education. Course material, against the syllabus and the cases it teaches.
Suggested citation
Sun, R. (2026). The Live and Breathing Essay: an architecture for published writing that maintains itself against a live dataset. Version 1.0, 3 August 2026. https://www.techieray.com/LiveAndBreathingEssay