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.

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.

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.

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 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.

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