Shared proof surfaces

Inspector, AX, and DX

DX is the comfortable, high-bandwidth surface for humans deep inside a project. AX is the distilled, bounded, proof-carrying surface for agents — and for humans acting like agents. The system is deliberately biased toward making good AX fall out of the same explicit model that keeps it maintainable for humans: no "nice for developers, incomprehensible to everything else" magic.

Rich human surface.

Source DOM, Scope, Data, Timeline, Branches, Diagnostics, Plugins, and mutation affordances in one DevTools panel.

Bounded agent surface.

Plain command output first, structured JSON when requested, and packets that carry just enough proof to act safely.

What the Inspector actually is

Not a separate analytics dashboard, not a CMS: a live, high-density projection of the same graph, LZR tape, and proofs the build system uses. The frame below demonstrates the model — every value in it is read from this project’s own artifacts at build time.

Inspector projection Sidecar-driven

Sourcesrc://components/component-bound.html

<set key="campaign" value="{{ data://campaign.json }}" />
	<scenario-layout
		title="Component-bound rendered effects"
		family="component invocation and prop lineage"
		source="src://components/component-bound.html"
		rendered="rendered://public/components/component-bound.html"
		coverage="component prop changes, source ownership, rendered-effect proof"
	></scenario-layout>
	<test-panel label="What this page tests" tone="blue">
		<p>Component invocation attributes, component-bound text, and data-backed rendered effects.</

Datadata://campaign.json

{
  "title": "Corpus Campaign",
  "client": "Corpus Client",
  "url": "/campaign.html",
  "adCount": 2,
  "newsletterCount": 1,
  "assets": [
    {
      "src": "/assets/banner.jpg",
      "alt": "Banner asset"
    },
    {
      "src": "/assets/newsletter.jpg",
      "alt": "Newsletter asset"
    }
  ],
  "variants": [
    {
      "id": "banner",
      "width": 300,
      "height": 250
    },
    {
      "id": "newsletter",
      "width": 640,
      "height": 480
    }
  ]
}

Scopecampaign

campaign

title"Corpus Campaign"

client"Corpus Client"

url"/campaign.html"

adCount 2

newsletterCount 1

assets [2 items]

variants [2 items]

Renderedrendered://public/components/component-bound.html

<section class="card  campaign-header" data-panel="Campaign header"><h2>Campaign header</h2> <h1 id=campaign-title>Corpus Client Campaign</h1> <p class=scope-note>This page is intended to reproduce component/data-bound rendered-effect proof gaps.</p> </section>

Open the live scenario ->

Tab	What you are actually looking at
Source	The real LZR template DOM with semantic control structures — not the minified output.
Scope	Expression lineage, data reads, and foreach context that the render plan recorded.
Data	JSON Patch operations validated against current proofs.
Timeline / Graph / Diagnostics	Build events and ownership from the Hypermake graph and tape ledger.
Mutations	A PreparedMutation checked against source hashes, tape versions, scope, and impact before anything is written.

Core AX surfaces

Plain output first

Agent-readable CLI output by default; --json when you need the full machine form.

hypermake explain rendered/public/components/component-bound.html

Bounded AX packets

Small, self-contained fragment descriptions: ownership, lineage, reads, patchability, and validation vocabulary without dumping the world.

hypermake agent-brief rendered/public/components/component-bound.html

Graph commands as truth

resolve, match, explain, graph, affected-by, doctor answer the same questions the Inspector answers.

hypermake affected-by src/components/component-bound.html

Proofs as artifacts

Span maps, tape ledgers, data-read sets, and edit maps are graph-owned artifacts, not hidden runtime state.

cache://hypermake/lzr/spans/rendered/public/components/component-bound.rendered-spans.json

Why the bias runs toward AX

For humans, the Inspector turns "why is this text here and what happens if I change the data" into seconds instead of minutes of grepping. For agents, the same surfaces give bounded, high-signal context to propose precise edits without reconstructing the project model. When DX and AX are in tension, AX wins: good AX forces the underlying model to stay explicit, while opaque-but-pleasant DX tends to hide the complexity that later bites the team. When something is hard for an agent, treat it as a signal that part of the model is still too implicit — the fix is usually more explicit provenance or a better projection, not a smarter prompt.

Recover the same truth from the CLI shell

hypermake resolve rendered/public/docs/inspector-ax-dx.html
hypermake explain rendered/public/docs/inspector-ax-dx.html
hypermake agent-brief rendered/public/components/component-bound.html
hypermake graph rendered/public/docs/inspector-ax-dx.html --json --pretty=false