The data

The capabilities, barriers, undo classes, deployment shapes and mandates an ABP is written in, as JSON at stable addresses with cross origin access, with the source bytes they were promoted from.

Source: https://abp.sgit.ai/data/index.html↗ · site v0.11.0 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a .md twin; internal links below point at them.

Home↗ / The data

The data

The published vocabulary of the Agent Behaviour Policy: 23 capabilities, 4 barriers, 3 undo classes, 17 deployment shapes and 16 starting mandates, at stable addresses with cross origin access.

Start at /data/index.json↗. It names every other file, carries the counts and states the version to pin. This is v0.11.0.

Where it came from, and what that obliges

This site did not author this ontology. It was published as a data pack the game at what-can-it-do.games.sgit.ai↗ reads, and the job here was to promote it out of a game's internals into a published schema the network can cite. Nothing was renamed.

The bytes as fetched are served unchanged under /data/upstream/↗, and the build recomputes the hash on every run and refuses to write if it disagrees. Anything rendered stays one click from its source bytes.

How much of it was measured

21 of 99 capability rows were measured, meaning seen directly on the thing itself. The other 78 were derived from what the deployment architecturally is, or from the vendor's published documentation. By tier: derived 45, observed 21, documented 13, inferred 1, self-reported 1.

A precision the headline loses. A row at the observed tier: seen directly, on the thing itself. No row in this pack is at the measured tier, which the pack defines as a dated probe with an evidence file. The published headline of 21 of 99 counts the observed rows, and so does this site.

No row here was obtained by probing anybody's system. A row is measured only from a system we are entitled to run, or from the vendor's own published documentation.

The files

The deltas, which are here on purpose

18 stored deltas, one per deployment shape and mandate pair, at /data/deltas/index.json↗. Derived and never authored. Stored under deltas/, each record pinning the version of both inputs and the time and code version that produced it. No field in one is writable by a person: change a grant or a mandate and recompute. Corrected from computed and never stored on 11 September 2026; the brief is in /docs/briefs/. What that means and why it changed↗.

The release gate recomputes every stored delta on every build from the profile and the mandate it names, and fails on a single row of disagreement. That is how a machine holds `never authored': the rule forbids the act rather than the artefact, and a hand edited delta is a fiction nothing downstream could detect.

What is deliberately not in these files

The contributed shapes, and the intake path

8 deployment shapes were contributed by riskmandate.ai and promoted here at v0.4.4, which is the answer to the second of the three requests it published against this site: under the three layers a shape is a layer one fact, owned by nobody, and it belongs at the address every consumer reads. The bytes as fetched sit under /data/contributed/riskmandate/↗, never edited, with a hash per file and a hash over all of them that the build and the gate both recompute. Each promoted profile pins the hash of the one file it came from, carries the contributor's own provenance block whole, and keeps the contributor's contradictions, research needed and what the grammar cannot say, because those are the finding.

The tier is the contributor's and this site did not raise it. 16 of 42 contributed rows are at the contributor's measured tier, from a dated probe of an instance an early user was entitled to run, with the write up held by the contributor as the evidence file. The rest were read from vendor documentation on a date and quoted. Nothing was probed by this site, and the rows are counted beside the map's 99 rather than folded into them, because the two were obtained differently.

The intake path is the same for anybody. A proposed shape is a abp/profile/v1 file and a mandate that applies to it, fetched from an address the proposer publishes, held here as the bytes fetched with their hash, and promoted without renaming anything. Every capability id has to be one of the 23; a row that needs a new verb, object class or reach is a proposal to the grammar and needs a probe, and the contributor's not_in_grammar field is where that is recorded rather than forced.

Proposing a change

The data files are the shared facts and they live in this repository so that people can propose changes. The site and its data are the library; a cloned vault is the instance. Two rules come with that.

A proposal carries evidence. Every node taken from a third party site carries a source URL, a retrieval timestamp and a content hash. A proposal that changes a capability row without one is an assertion, and the release gate refuses it.

A consumer pins a version. Anything that computes from these files states which version it computed against. A clone that floats against the latest has no reproducible output.

One transform happens between these files and the pages. The source prose carries em dashes, en dashes and curly quotes because it was written elsewhere, and this repository holds a rule that its documents are pure ASCII. Both survive: the JSON keeps the upstream strings exactly as they arrived, and every upstream string rendered into a page is transliterated at render time. The bytes are one click away either way.

The schema, explained↗ · The upstream pack manifest↗ · The map this came from↗

Site index for agents↗ · HTML version↗