Governance

Governance is what separates a context layer from a wiki. The semantics are the circle: equal access, not equal authority.

The circle, normatively#

  1. Everyone reads. All participants, people and agents alike, with access to a context layer MUST be able to read the whole of it. A context layer with role-gated reading within it isn’t a shared context layer; where different people may read different material, that material belongs in separate context layers (see Access boundary below and distribution.md).
  2. Anyone proposes. Any participant, person or agent, MAY propose changes to the context layer. Agent-authored proposals are first-class: an agent that discovers missing or wrong context while working SHOULD propose the fix in the same change set as the work that surfaced it. A proposal SHOULD carry rationale sufficient for a reviewer to understand its intent and expected effect; that rationale is the minimum a person needs in order to approve. Leji 1.0 defines no generalized evidence protocol (see Scope of 1.0).
  3. People approve. Every change to the context layer MUST be approved by a person before it becomes canonical. Approval rides the repository’s existing review mechanism (pull requests); Leji introduces no separate process. Participation MAY happen through any interface, but canonical approval MUST be an auditable review record in that mechanism: attributable to the approving person and bound to the change set under review. An approval expressed only in external discussion, chat, ticket state, or document comments does not count until it becomes such a record; mirroring it into a comment does not. Widening how people take part never moves where authority is recorded.

Requirements#

  1. Ownership, not authorship. The manifest MUST name a primary owner (owners.primary) and MAY name a continuity owner (owners.continuity): a different person who carries the same accountability when the primary is unavailable or steps away. An assisted adoption SHOULD name the continuity owner before outside help leaves; a solo context layer MAY have none, which honestly signals it has no succession. Owners are accountable people: an agent proposes and reviews but never owns, and naming the primary again as continuity provides none. The owner is accountable for the context layer’s health: that it stays current, that stale or contradictory content gets pruned, and that every area has someone who tends it. Owners are not curators. The content is written and kept true by the whole circle as it works; concentrating that in one keeper is the bottleneck this model exists to avoid.
  2. Review scope. Context layer changes SHOULD be reviewed by the people closest to the affected content, the area owners, not funneled through a single gatekeeper. Area ownership is the repository’s existing ownership map (a CODEOWNERS file, a team convention), not a new manifest field; Leji reuses it the way it reuses pull requests for approval. The primary owner is accountable for ensuring every area has one. Review asks more than “is this true?”: why this belongs in the context layer, who will rely on it, what shows it holds, and when it should be revisited. A change that cannot answer those is a link or a note, not canonical context. The standing review question for any change set is did this change alter the context?; if yes, the context delta belongs in the same change set.
  3. Inclusion and removal. Proposing is open; inclusion is not. Content belongs in the context layer only if it changes how future work is done: it sets a constraint, encodes a decision, defines an interface or ownership boundary, or stops a repeated mistake. Everything else is linked, not absorbed. The context layer MUST have a removal path as deliberate as its approval path: stale, superseded, and duplicated content is pruned in ordinary reviewed change sets, and pruning is part of each area owner’s duty, not a separate cleanup project. A context layer that only ever grows is one that rots while passing review. Durable guidance SHOULD clear the proven-twice gate (per content-categories.md): a one-off fix can be merged, but a norm becomes canonical only after it has held across at least two real tasks. Capture what is true, not what is hoped for.
  4. Changelog discipline. At indexed conformance and above, every approved context layer change MUST append a machine-readable changelog entry per machine-readable-surface.md.
  5. Freshness. Context layer content SHOULD carry review horizons (freshness.reviewAfter in index entries and profiles). Tooling SHOULD report content whose horizon has passed, and MUST NOT silently treat stale content as current. At governed conformance, freshness checking MUST run in CI. Review freshness (above) is distinct from checkout currency: whether the copy a reader holds matches the canonical repository. A reader establishes checkout currency from the version control system (git); the working tree is current only to the revision checked out, and tooling MUST NOT silently treat an unverified copy as current. A reader that reaches the context layer as plain file content, with no accessible git working tree or version metadata (file content uploaded or synced into another interface, without the repository), MUST treat checkout currency as unknown rather than current.
  6. Canonical content lives in the context layer. Knowledge that governs how work is done MUST NOT exist only in a vendor configuration file, a chat thread, or an individual’s notes. If it governs work, it belongs in the context layer, under review.

Access boundary#

Leji defines no access-control mechanism of its own. Access to a context layer is governed by the version control system (git) and the platform the repository lives on: the repository host’s permissions, and the filesystem or shared drive that exposes the working tree. The context layer is the unit of access.

  1. A context layer MAY live in an access-controlled repository. Leji does not grant, check, or enforce that access; the version control system and its host do.
  2. A conforming context layer MUST NOT require role-gated reading within itself. “Everyone reads” is scoped to a context layer’s audience: everyone the version control system admits reads all of that context layer.
  3. Content that needs a narrower audience (an executive, finance, security, or incident-response context) MUST live in a separate context layer with its own repository, manifest, owner, and review gate, permissioned by the version control system. Restricted context is a separate context layer, never a restricted region of a shared one.
  4. Composing a restricted layer into another team’s context is the federation case, with the additional rules for restricted mounts in distribution.md.

The maintenance model (non-normative)#

The context layer is maintained one delta at a time, riding work that is happening anyway: a task surfaces missing or wrong context; the fix travels in the same reviewed change set; the changelog records it. There’s no separate documentation sprint, and there never needs to be one. Wrong context produces wrong output that someone feels the same day; that, plus review, plus CI on the mechanics, is the entire forcing system.

That fast feedback catches wrong content quickly. Slow accumulation, content that is merely mediocre or redundant, is caught by the inclusion bar and the removal path above, applied by the people who own each area. This is curation, and Leji distributes it on purpose. A single curator looks like the safe way to hold quality and is the opposite: they become the slowest path in the system, changes queue behind them or route around them, and they hold less context than the area experts do. The context layer either stalls or forks. Every area owner pruning and gating their own slice is what keeps the whole context layer small and true without a chokepoint. The owner tends the health system; the circle tends the content.