# The Semantic Browser
# Book: Language
# Chapter URL: https://programmer.ie/books/language/12-chapter/
# Prose fingerprint (sha256, normalized): 4795441ee1917ca0ee2be8a82e753eb3d4b178d7d3f946778726e239b870bece
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Return to the constructed twenty-page incident report from Chapter 1. A database failed on a Tuesday. The report contains a timeline, log excerpts, five candidate causes and a conclusion disputed by two engineers. A reader could need to decide whether a proposed fix is justified, determine whether another service is affected, or find one timestamp. Those tasks do not call for the same representation. Nor do they permit the same omissions. The preceding chapters developed pieces of a possible mediation layer; this chapter asks whether they can be assembled into one coherent path without losing the constraints that made each piece defensible. The incident is a worked design case, not evidence that such a browser has already improved anyone’s decisions.
Here is the architecture to be tested. The arrows describe proposed data flow, not a compulsory sequence of expensive model calls. A simple lookup may bypass the generative path entirely. In the generative path, checks must occur before a candidate view is released; what a reader later understands or does is a separate outcome that must be measured, not something a pre-display checker can certify.
Proposed Semantic Browser path, not a completed integrated system. Pre-display checks cannot certify what a reader will understand. Open full-size diagram. Call the proposed composition a semantic browser: a reading environment that can retain the source, derive an inspectable interpretation, respond to a declared task, choose whether to alter the presentation, and check each candidate transformation before releasing it. It may also offer separately labelled material alongside the view. The term names a design, not a product with established performance, and certainly not a claim that the system possesses the author’s meaning. Keeping a source-linked record and passing a gate do not establish either complete source fidelity or improved reconstruction by the reader. The architecture is useful only if those outcomes survive independent tests against simpler alternatives.
From the report to a record First the report is treated as an identified, versioned source. An interpretation may be extracted and stored: five reported candidate causes, the evidence each author cites, the sequence of events, the claims attributed to the engineers, and the qualifications on those claims. In the constructed example, hypothesis three can be excluded only if replication lag is below a specified threshold; the report says the necessary measurement is missing. The record must therefore preserve a conditional exclusion and an unresolved condition, not quietly convert them into a finding. Every entry points to a particular passage and source version, and unsupported relations remain candidates or unknown. These links make the reading inspectable, not infallible. An extracted record can omit an important claim, misread an exception, or propagate one mistake into every downstream view. A changed source invalidates any interpretation whose binding cannot be re-established.
Next, the reader declares a task before any new view is selected. The obligations depend on that task and are recorded before the candidate representation is generated. Suppose a manager must decide whether to approve a proposed fix. She needs enough evidence to challenge the leading explanation, not merely an attractive diagram of it. A task-specific obligation set might be:
task: assess whether the proposed fix is justified source: identified incident-report version must remain recoverable: - all five candidate causes and their reported supporting or opposing evidence - who disputes the conclusion and the reasons stated for disagreement - that hypothesis three is excluded only if the lag condition holds - that the required replication-lag measurement is missing - the proposed fix, its author and the stated justification - where each decision-relevant item appears in the unchanged report These are not a summary, a claim that the report is correct, or a complete model of the manager’s intent. They are proposed acceptance conditions for one transformation. The system should expose them for inspection, allow unresolved obligations, and record who approved or revised them. Their adequacy must also be assessed independently: if the source contains a crucial condition that nobody included, a rendering can satisfy every declared obligation and still mislead. Freezing the obligation set before generation prevents the output from quietly redefining success; it does not turn that set into a perfect oracle.
One source, several tasks The same source version is available for four tasks, with a reusable record where one is needed. What can change is the permitted omission, the useful form and the cost of getting it wrong. Obligations must therefore vary by task, even when the report and its interpretation are shared. These are proposed behaviours for a browser, not four reader outcomes already observed.
Deciding whether to open it. An engineer in another team wants to know whether the incident affects her service. A short preview may suffice, provided it accurately identifies the named services, the relevant failure conditions and the status of the disputed cause. The preview supports selection, not approval of a fix. A false skip can be expensive; a false open also consumes attention and may crowd out other relevant reports. If the source does not reliably identify affected services, the preview should expose that uncertainty or fall back to the report rather than fabricate reassurance.
Approving the fix. The manager needs to compare hypotheses with evidence and exceptions. A graph may make the five candidate causes and their stated evidence links easier to inspect; a table may align predictions with observed logs. But an arrow is an assertion, not decoration. The conditional status of hypothesis three, the missing lag measurement and the dispute must remain attached to the relevant claims in each view. Evidence that appears in the diagram does not excuse its absence from the table. Every consequential element must link to the record and the quoted source passage, while the manager remains responsible for assessing whether the evidence justifies the proposed fix.
Carrying out the remediation. An engineer needs an authorised, current procedure with its preconditions, exceptions and rollback steps. If the report already presents that procedure clearly, leave it in place and perhaps reveal the conditions alongside each step. An incident report is not automatically an approved runbook: the system must not turn the reported remediation into an executable instruction or infer permission to act. The source’s status, version and relevant operational authority matter more than generating a visually smoother sequence.
Looking up one fact. A reader wants the exact time of failover. Search and highlight the quoted passage, preserving its timestamp, time zone and whether it records an observation or an estimate. There is no reason to invoke extraction, diagram generation or a language-model answer if direct lookup satisfies the task. The fastest faithful representation may be the unchanged page with one line located.
same versioned source possibly shared, fallible semantic record different task → different preservation obligations choose: unchanged · annotated · generated view Leaving the source unchanged is a first-class output, not a failure to generate. The browser should also be able to defer when an obligation is unresolved, the source is stale, the necessary evidence is absent, or the cost of verification exceeds the expected benefit. The choice itself is an engineering claim: to judge it, we need a baseline in which readers have the unmodified document with competent search and navigation. A generated view should earn its place against that baseline, not merely against a deliberately awkward PDF.
What sits beside the page For the manager, an optional margin could show an earlier postmortem, explicitly identified as another document with its own date and version. The system proposes a scoped relation: this earlier report may contradict hypothesis two under these assumptions; candidate, not confirmed. The reader can open both cited passages and see whether they concern the same environment, period and failure condition. A second item may restate assumptions already present in the incident report, with each source quote attached. If she asks a question, an interactive answer may combine source extracts, retrieved evidence and model inference; those are different origins inside one response, not a new authoritative category created by interactivity.
Origin and epistemic standing must survive presentation and reuse. A quotation from the report is marked as quoted; an interpretation as derived; the earlier postmortem as retrieved external material; any new inference as a model proposal. Merely attaching a citation does not verify that the cited passage supports the claimed relationship. These labels must persist when an item is copied into notes, and a reader should be able to dismiss the margin entirely. Access is another boundary: a sidecar must not search or reveal reports the reader is not permitted to see, and the current reading task does not authorise permanent profiling of the reader.
Checking before showing Before a generated view is released, the proposed design applies a preservation check to that view in isolation. The unchanged source remains immediately available; source lookup does not require the generative gate. The check compares the candidate with the frozen, task-specific obligations and its source-linked record, including direction, condition, uncertainty and relevant evidence. Checking a bundle only once is unsafe: a valid qualifier in a diagram can mask the same qualifier missing from a table. Nor does passing the gate show that the record itself was complete or that a real reader will draw the right conclusion.
Suppose a comparison table presents hypothesis three as ruled out while omitting the condition on replication lag and the fact that its measurement is missing. The row is tidy and misleading. If the checker identifies that omission, the candidate is refused. A bounded repair may restore the condition and source link, after which that table must be checked again. If the system cannot demonstrate the required preservation, it returns the unchanged source with a clear indication that the generated view was withheld. It does not quietly replace the source with a flawed candidate just because a disclaimer would be convenient. These are proposed gate behaviours, not a claim that an existing checker can detect all such semantic errors.
The gate must be evaluated as an instrument, not congratulated for having a refusal branch. It needs planted omissions, reversed relations, altered numbers, misplaced qualifiers and fluent nonsense that repeats the expected words; it also needs faithful views so false refusals are counted. Crucially, test on held-out variants, not only the constructed cases used to repair the checker. Record false passes, false refusals, unresolved outcomes, latency and whether repair introduces fresh errors. A checker that frequently refuses is not necessarily safe, and one that rarely refuses is not necessarily useless. Its discriminating performance matters.
What it costs, and where it can fail Composition introduces costs that isolated examples conceal. Interpretation and checking take time and money; a source-linked record can become stale; a shared extraction error can mislead every view; a sidecar can consume the attention that a diagram was meant to save. Even the correct choice of representation can be undermined by a faulty renderer or a reader who trusts the margin more than the report. The costs are task-dependent. For a timestamp lookup, the cost of a full pipeline may exceed the entire task; for a disputed causal diagnosis, the cost of overlooking a missing condition may dominate a modest delay.
The difficult claim is therefore about the assembled system, not the cleverness of its parts. A good relation classifier cannot compensate for the candidate that retrieval never found. A correct semantic record cannot prevent an unfaithful diagram unless the renderer and gate honour it. A checker can reduce one class of distortion while creating delays or false confidence elsewhere. The parts must be tested together against competent non-generative and simpler generative baselines. The complete architecture has not been evaluated with real readers in this book, and the scripted demonstration below cannot supply that missing evidence.
A proposed end-to-end test The incident report is a useful walkthrough but a poor sole benchmark. Freeze a small, varied corpus of constructed and source-authorised reports with verified passages, source versions, disputed claims and deliberately planted failure modes. Before the experiment, independent reviewers define each task’s preservation obligations, evidence references and acceptable decisions; keep a held-out assessment set separate from the examples used to build the gates. Include easy single-fact lookups, relevance triage, disputed approvals and procedure interpretation, because a browser that wins only on complex diagrams may still lose overall.
Compare at least four conditions: the unchanged report with strong search/navigation, human-authored task views, direct model-generated views with source links, and the proposed semantic-record browser with its gates and abstention. Where feasible, ablate the record, checking and sidecar separately so that a gain is not credited to the whole architecture without identifying the useful component. Counterbalance task order across readers, hold model versions and task budgets fixed, blind outcome adjudicators to the interface used, and repeat model-backed runs rather than accepting a polished single sample.
Report distinct outcomes: obligation-level preservation and unsupported additions; false skips on selection tasks; decision correctness on held-out incident questions; time, navigation and interruption burden; helpful and harmful abstentions; checker false passes and false refusals; source-trace accuracy; and production cost. Ask readers what they believe before scoring correctness, so increased confidence in a wrong answer is observable. Stratify the results by task and source difficulty, and retain the unchanged source as a candidate for every task. A browser that is more appealing but less accurate, or more faithful but prohibitively slow, has not demonstrated a general advantage. This is a proposed experiment, not an experiment already run.
What the browser does not claim The boundaries established along the way still hold when the pieces are assembled:
source ≠ semantic record ≠ rendering source-linked ≠ faithfully interpreted consistent across views ≠ correct against source retrieved ≠ verified; cited ≠ supported checker passed ≠ intent preserved preference ≠ comprehension ≠ task benefit permission to render ≠ permission to act The record is a revisable interpretation, not the report and not a source of truth. A retrieved document has been found, not independently verified; a citation identifies a place to check, not proof that the candidate relation holds. A passed preservation check is evidence about specified obligations only, and reader preference is not comprehension or effective action. The source stays accessible in its actual version, corrections to its derived record are logged, and no generated view can silently replace an approved document or authorise operational changes. Those distinctions are controls that an implementation must enforce, not guarantees conferred by the architecture’s diagram.
What has changed The conventional fixed-page path is a useful comparison, although authors, editors and software have long offered more than one view and readers have never been passive decoders:
AUTHOR → FIXED PAGE → READER The proposed browser inserts a conditional, inspectable mediation path. It does not require generation for every encounter, and it must not mistake the following schematic for a guarantee of understanding:
SOURCE → unchanged view ────────────────────────→ READER ↓ if a new view is useful source-linked interpretation + declared task ↓ preservation obligations + proposed rendering ↓ per-view check → admit / repair / fall back ↓ if admitted task-specific view ────────────────────────────→ READER ↓ outcome still unknown This is one concrete form the book proposes for intelligence entering the channel: an inspectable choice about whether and how to transform a representation for a current purpose. The system may interpret, route, render, decline or show its evidence; it does not become the author, know the reader’s mind, or acquire authority to act. Communication now has another accountable participant in the middle, capable of changing the evidence from which the reader reconstructs. Whether that change is a gain must be judged from the source and the reader’s actual task outcome, not from the existence of a generated interface.
Running it The reference implementation (ernanhughes/project-language) documents npm run example:ch12, a scripted demonstration using a shortened constructed incident report and a hand-written semantic record. It runs with a scripted stand-in for the model on a Pi host and makes no real model call. The example is a test of the program’s defined routes and checks under supplied inputs, not a real-model extraction experiment, independent semantic evaluation, or reader study.
In the documented example, proposed generated views are gated before appearing in the browser view. A structurally invalid document record causes fallback to the source. The script exercises both a repair after refusal and a bounded sequence that ends in fallback; a view is closed once admitted or returned, and only the reader can reopen it. A checker without validation against its supplied reference cannot authorise a generated view. The direct fact-lookup branch returns the source unchanged, and the procedure branch adds annotations without rewriting the source text. These are implemented routing and control rules for the constructed case, not proof that real extraction or real readers behave well.
The build also found why per-view checks matter: checking a diagram and table jointly allowed a missing condition in one row to be masked by the diagram that still included it. The local check was narrowed to each view and the relevant row, then strengthened after review to require the condition’s wording, hypothesis evidence and arrow direction. That history is evidence that the implementation catches some constructed errors, and that the earlier checker was inadequate. It is not evidence of coverage against unseen errors. Extraction is still bypassed by a hand-written record; its completeness, semantic faithfulness, checker generalisation, reader effects and end-to-end costs remain unmeasured.
Where this leaves us, and what it creates Part I has developed a disciplined proposal for representation mediation. A receiver reconstructs meaning from what a representation makes available. A task can justify changing that representation, but a generated view may drop an exception, invert a relation, or amplify an unsupported claim. A semantic record, typed relations, declared preservation obligations and a checked rendering path make some of those risks inspectable. They do not remove the risks automatically. The Semantic Browser gathers the proposed mechanisms into one testable design, with a reason to leave the source alone and a way to say that a candidate has failed. Its central claim is architectural; the evidence of human benefit is still to be earned.
The browser suggests a family of views—previews, diagrams, comparisons, annotated sources and optional evidence panels—selected for a reader who has already encountered a document. That raises a different problem. Most potentially valuable sources are not open in front of anyone: conference recordings, newly published papers, incident reports, advisories and conversations accumulate faster than a person can examine them. Generating another form for each source does not decide which source deserves attention, and unlimited generated representations can make overload worse. Part II therefore changes the question from what form should this take for the current task? to what should reach the reader at all, why, and when? The authority to select is another decision to make visible and test, not a benefit conferred by making rendering cheap.