Neural Inverse Govern
Documentation

Version Latest

Context Platform

How Neural Inverse Govern gives AI tools governed, attributed context from your code, issues and team knowledge, and what each part of the Context Platform does.

The Context Platform is the part of Neural Inverse Govern (powered by Keystone) that decides what context an AI tool may see. It indexes your repositories, issues and team knowledge into spaces that follow your organisation's structure, and answers retrieval requests from the Editor, the Agents app, the CLI and MCP-capable tools. Every answer is authorised per space for the person asking, passed through DLP, cut to a token budget and written to an HMAC-chained evidence record.

The Context Platform runs inside the Govern server. It needs no external service: PostgreSQL holds spaces, sources, chunks and the event feed, and an embeddings endpoint is optional.

How a retrieval is answered

Every retrieval runs the same fixed steps, whether it comes from the REST API, the MCP endpoint, a lens, a pair session or the endpoint agent:

  1. Candidates. The spaces that can contribute: the chain of the requested space (project, owning team, department, organisation) plus the caller's own groups, teams and departments.
  2. Authorisation. Each candidate space is checked for the caller before anything is searched: the organisation's deny rules, the role grant, and the space read model (membership and classification). Spaces that fail are dropped.
  3. Search. Full-text search, and vector search when an embeddings endpoint is configured, over the authorised spaces only.
  4. Rank. A hybrid score multiplied by a weight for the level of the space the chunk came from.
  5. DLP. The action of each source's effective classification (redact, drop or withhold the source) is applied to every chunk.
  6. Budget. Chunks are added in rank order until the token budget is used.
  7. Attribution. The request, the spaces, the sources and a SHA-256 of every delivered chunk are recorded in the evidence chain.

Hierarchy decides where context may come from; it grants nothing. Authorisation decides whether the caller may use each space. DLP decides whether retrieved content may be returned. A failure at any step fails the request closed.

What the platform contains

AreaWhat it doesPage
Spaces and sourcesOne space per organisation, department, team, group and project; GitHub codebase and GitHub issues sources; personal documentsSpaces and sources
Classification and deny rulesFour classification levels with a DLP action each; organisation rules that refuse Context actions on chosen nodesClassification and deny rules
Retrieval and attributionThe retrieve API, ranking, budgets, embeddings, and the evidence record of every retrievalRetrieval and attribution
Lenses and sharingSaved, shareable retrieval views with share levels, expiry and approvalLenses and sharing
Handoffs, snapshots and pair sessionsHand working context to a reviewer; immutable snapshots; live shared sessionsHandoffs and pair sessions
Collaboration policyPer organisation, department, team and project controls over everything that is sharedCollaboration policy
Team memoryDecisions, conventions, notes and glossary entries a team edits together; only reviewed text reaches the AITeam memory
Work registryWho is changing what, and where two pieces of work overlap; advisory onlyWork registry
Agent instruction filesCLAUDE.md, AGENTS.md and similar files, stored in layers with versions and approvalAgent instruction files
Real-time feedAn ordered event stream and presence for the first-party appsReal-time feed and presence
MCP endpointRetrieval, policy checks and attribution links for MCP clientsMCP endpoint
Project lookupBinds a workspace folder to its project by repository addressProject lookup
SettingsEvery environment variable of the Context PlatformSettings reference

Permissions

Context actions are context:space:read, context:space:search, context:space:write and context:space:admin. They are ordinary permissions, granted by binding a role that carries them. Held on the organisation they apply to every space; per-space permissions (context.spaces:read, :use, :write, :manage) can also be bound on one space, its project, team or business unit.

  • Reads use context:space:read plus the space read model.
  • Writes (create, delete and re-index sources) need context:space:write and are always enforced.
  • Administration (classification, weights, deny rule view, index jobs, GitHub App, collaboration policy) needs context:space:admin on the organisation's root space or the node's space, always enforced.
  • Decisions that must be a person's (approving an agent file version, setting a legal hold, accepting team memory, sharing a lens, acknowledging an overlap) answer 403 context.person_required to an API key before anything runs.
  • A snapshot, a memory entry or a source in a space the caller may not read answers 404, exactly like an id that never existed.

Enforcement is the default for every organisation. An organisation can opt into a shadow mode, in which role denials are only logged, through the feature flag context.authz.shadow; a missing, disabled or unreadable flag means enforce. Hard denials (personal spaces of other people, organisation deny rules, the space read model) apply in both modes.

In the console

The console has a page for each working Context feature: spaces (with an Archived view), each space and its sources, project context, classification, the GitHub App, deny rules, status, lenses, the retrieval test, weights, snapshots, handoffs, attributions, Context DLP findings and index jobs.

These have no console page yet and are used from the Editor, the Agents app, the CLI or the API: the collaboration policy and share oversight, team memory, the work registry and agent instruction files.

What is not available yet

  • Source connectors exist for GitHub repositories, GitHub issues and pull requests, and personal documents. Wiki and documentation systems, conversations, regulatory sources and Linear are refused when a source is created.
  • Issue comments and review threads are not indexed.
  • Subproject and business unit weights are defined but no space has those levels.
  • The handoff inbox has no read state, and a pair session's host cannot remove a participant.
  • The endpoint agent does not yet call the project lookup itself; the Editor and the Agents app do.

Last reviewed 17 October 2026View as Markdown

Context Platform · Docs · Neural Inverse