Skip to content

How each declarative kind is read and which keys it may carry is data read at run time, and a repository adds a kind with its JSON Schema without a code change

The Rust executable compiles nothing about kinds or keys. On every start it locates the tool distribution's share directory and reads kinds.yaml (for each kind: the format, the front-matter rule, the identity, title and description fields, the version field and its supported values, the schema it must satisfy) and schemas/<name>.schema.json, one JSON Schema per contract, validated with a JSON Schema validator. A repository adds kinds under .ai/repo/knowledge/kinds.yaml and schemas under .ai/repo/knowledge/schemas/, declares a class for them in sources.yaml, and the objects are served; a kind or schema the distribution already declares cannot be redefined.

declared statusdeclared status: guaranteed Declared deterministic and blocking, implemented, and naming the behavioural test that is to prove it. Whether a recorded run supports it is the evidence verdict, shown beside it.

recorded evidencerecorded evidence: not run Declared guaranteed, and not supported by a recorded run: the test is named, and no passing run of the current inputs is recorded. how evidence is recorded

share/kinds.yaml and share/schemas/*.schema.json are the distribution's; .ai/repo/knowledge/kinds.yaml and schemas/ are the repository's; a name declared by both is an error naming both files. The shell tool's allow-lists are generated from the same schemas.

What it means

The Rust executable compiles nothing about kinds or keys. On every start it locates the tool distribution's share directory and reads kinds.yaml (for each kind: the format, the front-matter rule, the identity, title and description fields, the version field and its supported values, the schema it must satisfy) and schemas/<name>.schema.json, one JSON Schema per contract, validated with a JSON Schema validator. A repository adds kinds under .ai/repo/knowledge/kinds.yaml and schemas under .ai/repo/knowledge/schemas/, declares a class for them in sources.yaml, and the objects are served; a kind or schema the distribution already declares cannot be redefined.

How it works

share.rs locates the directory (--share, MAJORDOMUS_SHARE, the repository's share/, the executable's installation); metadata/mod.rs parses the kinds files in order, refuses a kind declared twice naming both files, compiles every schema, and index.rs validates each file's metadata against its kind's schema before it becomes an object: a key the schema does not allow is unknown_key, any other failed constraint is schema_violation. The shell tool's allow-lists under share/allow/ are generated from the same schemas.

How to see it

mkdir -p .ai/repo/knowledge/schemas .ai/repo/notes
printf 'schema: majordomus-kinds/v1\nkinds:\n  note:\n    format: markdown\n    front_matter: required\n    schema: note\n    identity: [id]\n    title: title\n' > .ai/repo/knowledge/kinds.yaml
printf '{ "type": "object", "additionalProperties": false, "required": ["id", "title"], "properties": { "id": { "type": "string" }, "title": { "type": "string" } } }\n' > .ai/repo/knowledge/schemas/note.schema.json
# add to sources.yaml:  - id: note / kind: note / discovery: vcs / pathspec: ':(glob).ai/repo/notes/*.md' / required: false
printf -- '---\nid: first\ntitle: The first note\n---\n' > .ai/repo/notes/first.md
git add -A
apps/majordomus-cli/target/debug/majordomus capabilities describe note.first

What it does not cover

A kind needing a format the reader does not have (something other than Markdown with front matter, YAML, a YAML collection, or plain text) or an identity rule other than named fields or the path is a change in index.rs; data describes objects, it does not define how a format is read. The shell tool reads its allow-lists, not the schemas, so a repository-defined kind is visible to the Rust executable only.

Why it exists

The operator's requirement that extension be data-driven at run time, with a typed and standard contract rather than regex lists. apps/majordomus-cli/tests/external_extension.rs adds a kind with its schema to a fixture repository, reads the object back, sees the schema enforced on a bad one, and sees a redefinition refused; test/cases/76_capabilities_projections.sh proves the distribution's kinds serve the layer init writes with state ok.

Detail rendered from docs/claims/schema-driven-kinds.md.

From the statement to the proof

  1. 1 · the public statement

    How each declarative kind is read and which keys it may carry is data read at run time, and a repository adds a kind with its JSON Schema without a code change

    No feature or README responsibility names it; this page is where it is stated.

  2. 2 · the canonical claim

    schema-driven-kindsdeclared status: guaranteed in docs/CLAIMS.yaml

    Defined in read it on this site · docs/CAPABILITIES.md

  3. 3 · the implementation

    apps/majordomus-cli/src/metadata/mod.rs

  4. 4 · the test and the scenarios

    Test: test/cases/76_capabilities_projections.sh

    Executed in Say what your work is for, once, and have every surface say it.

  5. 5 · the recorded runs

    recorded evidence: not run how evidence is recorded

Verify it yourself

The test runs in a disposable temporary repository and asserts the behaviour, not a string in the source.

from a clone of the repository
bash test/run.sh 76_capabilities_projections

Where this claim is used

The moments this answers

Searches the titles and descriptions of every page this site publishes.