What would a Hansard production system look like if it were designed for the AI era from first principles — rather than retrofitted onto a workflow that was never meant to accommodate it?
This paper sets out an answer. The architecture treats the reporter's contemporaneous chamber log as the foundational document from which downstream AI assistance derives. It separates the live captioning obligation from the considered Hansard record as two architectural concerns sharing audio but not text. It places AI agents only where human judgement is consultatively supported, never where editorial decisions are made. And it produces an open-source XML archive as the long-term preservation artefact — not a proprietary format, not a vendor-locked output, but a record that any future reader from any jurisdiction can read. The architectural commitments hold across deployment substrates: the agents can run on a sovereign local stack, inside an enterprise cloud environment the organisation already controls, or in other configurations a parliament's existing posture admits.
The architecture is designed for adoption by Hansard organisations of varying size, in any English-speaking jurisdiction, with house conventions that differ from one parliament to another.
A production system for the official record of a parliament has different obligations from a production system for any other text. It must be defensible: every editorial decision traceable, every transcript reproducible from its inputs, every audio chunk retrievable. It must be reader-led: a Hansard exists to be read by people who will not have access to the audio, and the text must stand without it. It must be sovereign: the parliament, not its vendor, owns the record. And it must be open: the long-term archive belongs to the citizenry, not to the producing organisation or its software stack.
The architecture this paper sets out is shaped by six commitments:
These six commitments hold regardless of where the AI agents are deployed. The architecture admits a sovereign local stack as one substrate; it admits an enterprise cloud environment the organisation already controls as another. What matters for sovereignty is who controls the editorial record — the text, the corrections, the decisions, the publication, the archive — not where the inference happens. A parliament already operating within an enterprise cloud has already answered the substrate question; what this paper addresses is the editorial agent that runs on top.
The full paper documents the system in three subsystems — live capture and broadcast, Hansard production, corrections and accessibility — with explicit interfaces between them. It catalogues the agents that operate in the system (five named, all consultative, none autonomously editorial). It specifies the profile-routing mechanism that makes the architecture multi-jurisdictional, and it treats the deployment substrate for the agents as a procurement choice independent of the architectural commitments. It describes the human topology: reporter, subeditor, supervising editor, editorial support group, and what each contributes to the record.
Three substantial components are named in the paper but specified separately in forthcoming appendices: the standardised live log schema that makes the reporter's record machine-readable; the supervising editor's dashboard for end-of-day flow management across jurisdictions; and the corrections subsystem that handles speaker-routed correction packages within the published record.
Bradley Reporting has been thinking about this architecture for some time. Publishing the design publicly, as an open invitation to argument and refinement, is a deliberate choice. The Hansard community is small and the work is consequential. A design held privately is a design that cannot be improved; a design held publicly is a design that can.
The paper is intended for Hansard editors, Hansard managers, parliamentary technologists, accessibility practitioners, and anyone else with a stake in how the official record of a parliament will be produced in the years ahead. Commentary, refinement, dispute, and adaptation are welcome.
The architecture has been drafted at version 0.1. A revised version, incorporating feedback and refining the open questions, will follow. Publication of the public paper is targeted for the second half of 2026, contingent on the appendices stabilising. Subscribers to CAL Notes will be notified when it lands.
This paper, like others in the Stewards series, will be drafted in collaboration with Claude (Anthropic), used as a thinking partner across argument structure, citation verification, and successive revision. The originating judgement — what the paper claims, how it is organised, what it leaves out — is the author's. As with all writing in CAL Notes, the AI did not decide what the paper means; the author did.