The context layer is the knowledge your lineage, the in-app
assistant, and any connected LLM read. px lets you keep it as files in your repo and
sync it with px context apply — without migrating your existing docs.
The model: manifests point at pristine bodies
The only Prometheux-aware artifact is a context-set manifest — a *.context.md file
that carries the config and references plain body files. The bodies stay untouched, so
you can point at docs you already have (a wiki, a docs/ tree, playbooks).
A manifest:
Fields
Activation behaviours
retrieved (default) — the note lives in the semantic pool and is looked up only
when a request is relevant. Costs nothing when unused.always — a rule: injected verbatim into the assistant’s instructions on every
request. Strongest guarantee, but costs tokens every message.on_demand — only the title is listed each request; the assistant fetches the body
when it decides it needs it. Good for long playbooks.
Links
Declared in the manifest, so bodies stay pristine. Relations: relates_to, defines,
example_of, contradicts. Link a note to a lineage concept with
to: concept:<predicate>.
derived_from provenance edges are platform-owned (emitted by context-concept runs) —
never author them.
Applying context
context apply is idempotent: a small CLI-owned state file
(.px/context-state.json) maps each note’s identity (manifest, referenced path) to its
server note id + a content hash, so re-applying updates changed notes, skips unchanged
ones, and (with --prune) removes notes you dropped.
Commit .px/context-state.json so re-apply stays idempotent across machines and CI. If
it’s lost, context apply reconciles against the server’s existing notes by content so
notes aren’t duplicated.
Duplicates are allowed
Identity is the manifest reference, not the body path — so the same body listed in two
sets becomes two notes, each with its own scope/activation. px never merges or
dedupes; the plan surfaces duplicates so they’re visible, but leaves them to you.
Sync model — one-way, files win
The manifests + bodies in your repo are the source of truth; the platform holds a
retrieval/embedding replica. A set under git sync is git-owned (in-app edits to its notes
are locked/flagged, like ArgoCD owning a namespace). Context not under git stays in-app
editable. There is no merge logic.
Sync from CI
See CI/CD for applying lineage the same way. 
