612741b387
Content build-out on top of the Phase 1 topic move. No behavior changes. Splits (existing content relocated, cross-linked): - queries/index.md → mutations/index.md (insert/update/delete + the inserts-vs-deletes rule) and search/index.md (the multi-modal search functions + a hybrid-ranking overview tying nearest/bm25/rrf together). queries/index.md now covers the read shape and points at both. - branching/index.md → branching/time-travel.md (snapshots/time travel) and branching/merge.md (three-way merge + the 7 conflict kinds, verified against error.rs MergeConflictKind). New pages (written from the code, user-facing): - quickstart.md — init → load → query → branch, with verified CLI flags. - concepts/index.md — what OmniGraph is + the L1/L2 (Lance/OmniGraph) framing. Expanded operations/audit.md from a 7-line struct dump into a real actor-tracking page (server token-resolved vs CLI --as chain; reading the trail; the omnigraph:recovery reserved actor). Index wiring: docs/user/index.md and AGENTS.md's topic table link every new page; also normalized AGENTS.md's docs/user link display text to match the Phase 1 retargeted paths. Verified: zero broken .md links; check-agents-md.sh green (57 links, 54 docs). Deferred to Phase 3: de-dev polish (grammar paths, IR internals still in queries/branching), guides/, and a possible reference/config.md split (the config schema is already coherent in cli/reference.md). Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
1.7 KiB
Audit & Actor Tracking
Every write in OmniGraph records who made it. The actor id is persisted on the graph commit, so the commit history is an audit trail of which actor changed the graph and when.
Where the actor comes from
The actor is resolved differently depending on the front end, but it always lands on the commit:
-
HTTP server — the actor is resolved server-side from the bearer token. A client cannot set its own actor id; it is derived from the authenticated token. See policy for how tokens map to actors.
-
CLI / embedded — the actor is self-declared through one resolution chain:
--as <actor>on the command,- then
operator.actorin~/.omnigraph/config.yaml(see the CLI reference), - otherwise none.
This difference is intentional: storage credentials imply a self-declared actor, while a server resolves the actor from a token it trusts.
Reading the audit trail
Actor ids are stored on each commit in the commit graph. List commits to see who made each change:
omnigraph commit list graph.omni
System-initiated writes use reserved actor ids — for example, automatic recovery
of an interrupted write records omnigraph:recovery, so operator changes and
machine repairs are distinguishable in the history:
omnigraph commit list --filter actor=omnigraph:recovery graph.omni
What is tracked
Every successful publish — load, change, branch merge, and schema apply — appends a commit carrying the resolving actor. Because publishes are atomic, the actor on a commit is exactly the actor responsible for that whole change.