Build log
From scattered links to a public record
A build log about making claims inspectable across HTML, structured data and read-only tools.
One claim, several readers
Public work accumulates in disconnected places: an announcement, a conference page, a company award and an old byline. A biography can compress those into a fluent story while losing the exact attribution. I wanted a reader to inspect the source behind a sentence without reconstructing that history.
This site starts with a catalog. Each record has a stable identity, source, date, exact description and verification qualifier. Company awards remain company awards. A speaking appearance supported only by my own post retains that limitation. Checking that a URL responds does not independently corroborate everything said on the page.
Keep the ordinary web useful
I chose static HTML so the record and essays are present in the first response. Navigation, article text and source links remain usable without a client script. Structured data and a JSON export provide other representations of the same record. They do not contain extra persuasive claims hidden from a human reader.
The cost of this choice is a release step for content updates. In return, there is no model in the reading path and no database needed to answer a public-record lookup. The page, exported record and tool response can be compared with the reviewed release.
A deliberately small tool surface
The public MCP endpoint offers three read-only operations: keyword search, evidence retrieval by record ID and a list of cataloged bylines. The native WebMCP adapter registers those operations only in a supported top-level browser document on this site’s HTTPS apex. It skips unsupported browsers.
That endpoint reads the published catalog. It cannot retrieve private notes, act on an account or contact anyone. The useful capability is a source-backed lookup. Browser support and actual browser-agent execution are separate checks; an HTTP tool response does not establish either.
Check the release and its limits
During deployment, content checks passed while an additional header check caught missing static security headers. The repair used the asset-upload API’s request field for headers, followed by a fresh readback. That is a small example of why acceptance needs more than one happy-path probe.
The live checks compare page and module bytes, media types, record fields, crawler directives and selected security headers. Requests carrying crawler user-agent names test those request paths. They do not prove that a provider’s verified crawler visited, that a page entered an index or that an assistant cited it. Those outcomes need their own evidence.
The next experiment
I want to evaluate how assistants use the sources: which claims they support, whether they preserve team attribution, and where they should say they cannot verify something. The public record supplies a reference set; it cannot predetermine the answer.
For now, the site is an inspectable publishing system with a small public tool interface. The open work is to test retrieval and attribution on actual assistant surfaces, then publish the misses and the fixes. This build log reports my implementation experience; it is not independent certification of the platform.
Sources and attribution
This is an original, self-published piece by Vihang Patel. The sources below support the referenced frameworks; fictional examples and personal judgments are identified in the text.