---
title: "Context Platform"
---

# 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

| Area | What it does | Page |
|---|---|---|
| Spaces and sources | One space per organisation, department, team, group and project; GitHub codebase and GitHub issues sources; personal documents | [Spaces and sources](https://neuralinverse.com/docs/context/spaces-and-sources/) |
| Classification and deny rules | Four classification levels with a DLP action each; organisation rules that refuse Context actions on chosen nodes | [Classification and deny rules](https://neuralinverse.com/docs/context/classification/) |
| Retrieval and attribution | The retrieve API, ranking, budgets, embeddings, and the evidence record of every retrieval | [Retrieval and attribution](https://neuralinverse.com/docs/context/retrieval/) |
| Lenses and sharing | Saved, shareable retrieval views with share levels, expiry and approval | [Lenses and sharing](https://neuralinverse.com/docs/context/lenses/) |
| Handoffs, snapshots and pair sessions | Hand working context to a reviewer; immutable snapshots; live shared sessions | [Handoffs and pair sessions](https://neuralinverse.com/docs/context/handoffs-and-pair-sessions/) |
| Collaboration policy | Per organisation, department, team and project controls over everything that is shared | [Collaboration policy](https://neuralinverse.com/docs/context/collaboration-policy/) |
| Team memory | Decisions, conventions, notes and glossary entries a team edits together; only reviewed text reaches the AI | [Team memory](https://neuralinverse.com/docs/context/team-memory/) |
| Work registry | Who is changing what, and where two pieces of work overlap; advisory only | [Work registry](https://neuralinverse.com/docs/context/work-registry/) |
| Agent instruction files | CLAUDE.md, AGENTS.md and similar files, stored in layers with versions and approval | [Agent instruction files](https://neuralinverse.com/docs/context/agent-files/) |
| Real-time feed | An ordered event stream and presence for the first-party apps | [Real-time feed and presence](https://neuralinverse.com/docs/context/realtime/) |
| MCP endpoint | Retrieval, policy checks and attribution links for MCP clients | [MCP endpoint](https://neuralinverse.com/docs/context/mcp/) |
| Project lookup | Binds a workspace folder to its project by repository address | [Project lookup](https://neuralinverse.com/docs/context/project-lookup/) |
| Settings | Every environment variable of the Context Platform | [Settings reference](https://neuralinverse.com/docs/context/settings/) |

## 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.