SharePlane Next

Data and provenance

The machinery is public too.

SharePlane is designed to be read by people and parsed by agents without forcing either one to reverse-engineer a JavaScript application. This page explains the machine-readable surfaces behind the library and what authority they do, and do not, carry.

Enough machinery to verify the work. Not enough to become the work.

SharePlane generates structured metadata, provenance records, claims, relationships, and receipts alongside the human-readable pages.

Those surfaces exist so agents and skeptical readers can inspect what informed an artifact, how it relates to other work, and what validation occurred.

They are not a second product hiding behind the first one.

The architecture is designed to remain understandable without requiring a diagram containing seventeen cloud logos and an apology.

Architecture

One canonical artifact record. Several useful views.

Each artifact has one canonical structured record and one human-facing page source. The catalog, graph, JSON-LD, sitemap, feed, agent index, topic pages, format pages, author pages, and receipts are generated from that authority.

This reduces drift. A title, date, source, claim, or relationship should not mean one thing on the website and another thing in the machine output because somebody forgot to update the second copy.

Build first. Serve files afterward.

The catalog, graph, indexes, feeds, and discovery files are created before deployment.

At runtime, the host serves static files. No database query is required. No JavaScript application reconstructs the page. No AI model is waiting behind the curtain to improvise the answer differently on Tuesday.

What was published is what the reader receives.

That predictability is a feature.

Catalog JSON

The public artifact index: identity, title, abstract, author, dates, type, topics, privacy posture, runtime posture, and receipt reference.

Open catalog.json

Graph JSON

Typed nodes and relationships connecting artifacts, authors, sources, claims, receipts, validators, collections, and migration origins.

Open graph.json

JSON-LD graph

A Schema.org projection for search engines, agents, and tools that understand linked structured data.

Open graph.jsonld

Agent index

A concise text map of the library and its canonical machine surfaces for language models and other text-oriented agents.

Open llms.txt

Sitemap

The canonical list of public human-readable routes intended for discovery and indexing.

Open sitemap.xml

Artifact record

The public structured record for one artifact, including provenance, claim posture, relationships, dates, runtime behavior, and receipt reference.

Open an artifact.json example

Receipt

A compact record of source identity, hashes, validation outcomes, runtime boundaries, migration posture, and human approval status.

Open a receipt.json example

Artifact context

A deterministic public-safe plain-text projection for agents and text-oriented tools. It does not claim to be canonical Markdown.

Open a context.txt example

Agent package

A deterministic ZIP containing the canonical public HTML, public metadata, receipt, context projection, package guide, and member-hash manifest.

Download an agent-package.zip example

What the graph means

A relationship is evidence, not permission.

The graph records explicit relationships declared in canonical artifact records. It can help a person or agent locate related work, sources, claims, receipts, and authors.

The graph does not authorize rewriting, publishing, merging, or inferring new relationships. It is a navigation and evidence surface, not an autonomous control plane wearing a serious expression.

Why receipts exist

Trust improves when the work leaves evidence behind.

Receipts make important publication facts inspectable: what source was used, whether bytes were preserved during migration, what validation ran, what runtime dependencies exist, and where human approval remains required.

A receipt does not prove an argument is correct. It proves that the artifact's production and evidence posture were recorded rather than left to memory and enthusiasm.

For people:

Use the normal site. The artifact should remain the best reading experience.

For agents and tools:

Start with catalog.json or llms.txt. Follow an artifact's context.txt, artifact.json, receipt.json, and agent-package.json instead of inferring authority from visual proximity.