Context resolver
How Numinance builds a small, cited, access-checked context bundle for each stage from the systems that already hold your knowledge.
The resolver is part of the proprietary runtime. The knowledge port it calls is a public contract.
Give it context. Let it engineer. Context is retrieved per change from the customer's own systems, never copied into a vendor index.
Flow
Context resolver flow
How does context get acquired, and when does the system stop instead of guessing?
- Repository docs · worktree, human-authored
- ADR · worktree
- Ticket · KnowledgeConnection
- Runbook · KnowledgeConnection
- Knowledge connection · MCP or REST search
- 1 · Authorized sources5 of 5 sources
Only sources the connection scope and the principal can reach.
- 2 · Search and fetch5 of 5 sources
Every call runs under the principal's authorization (authz_context_digest). Denied sources and quarantined connections drop out here.
- 3 · Deduplicate5 of 5 sources
Identical content collapses by digest.
- 4 · Redact5 of 5 sources
Secrets and PII spans are redacted before persistence; BundleSource.redactions keeps the count.
- 5 · Freshness check5 of 5 sources1 stale
A newer source version or an age past a threshold marks SOURCE_STALENESS_STALE.
- 6 · Conflict analysis5 of 5 sources
Sources that disagree become a BundleConflict with every claim; never resolved silently.
- 7 · ContextBundle5 of 5 sources
Cited guidance and unresolved questions, stored by digest and never mutated.
Only non-blocking questions remain. The bundle goes to the executor with those questions attached and the stale sources labelled.
Outcome: Proceed with open questions. 5 of 5 sources reached the bundle; 0 blocking and 1 non-blocking unresolved questions; 0 conflicts.- sources[] · BundleSource
- Repository docsstaleness: FRESHtrust: UNTRUSTED_RETRIEVED
- ADRstaleness: FRESHtrust: UNTRUSTED_RETRIEVED
- Ticketstaleness: FRESHtrust: UNTRUSTED_RETRIEVED
- Runbookstaleness: STALEtrust: UNTRUSTED_RETRIEVED
- Knowledge connectionstaleness: FRESHtrust: UNTRUSTED_RETRIEVED
- cited_guidance[] · CitedGuidance {ref, section}
- 5 cited · advisory only, untrusted
- conflicts[] · BundleConflict
- none
- unresolved_questions[] · UnresolvedQuestion {question, blocking}
- ◐ blocking: falseRunbook: a newer version exists or it is past the age threshold; is it still current?
- Retrieved text is untrusted guidance. It can inform a plan; it cannot create policy, widen a grant or change a tool list.
- No copy of the knowledge base. Only what one change needs is fetched, by reference and digest. No mandatory vector database.
- The model never gets direct enterprise MCP access. The executor sees the bundle only; the resolver reads through pinned, read-only tools.
Text description
The resolver builds a small ContextBundle for one stage of one work unit. Stages: authorized sources; search and fetch under the principal's authorization; deduplicate by digest; redact secrets and PII; check freshness; analyse conflicts; emit the bundle.
The bundle has sources[] (BundleSource, with staleness, access_basis, trust), cited_guidance[] (CitedGuidance: ref, optional section), conflicts[] (BundleConflict), unresolved_questions[] (UnresolvedQuestion: question, blocking) and pinned_toolsets. Every source is TRUST_CLASS_UNTRUSTED_RETRIEVED.
Outcome rules used by this simulation (illustrative; the real bundle records the questions and the profile decides what blocks):
- A drifted tool inventory quarantines its connection. Nothing is read from it, and a blocking question is raised.
- A denied source is dropped. If it is the ticket, which carries the task, the question is blocking; otherwise it is open.
- A stale source stays in the bundle, labelled stale, with an open question.
- Conflicting sources produce a BundleConflict with both claims and a blocking question, because the resolver may not choose silently.
- Any blocking question gives Stop and escalate. Otherwise any open question gives Proceed with open questions. Otherwise Proceed.
Retrieved text is untrusted guidance and cannot create policy. There is no copy of the whole knowledge base and no mandatory vector database. The model never gets direct enterprise MCP access; the executor sees the bundle only. Simulated; nothing is connected to a running engine.
Mechanism
For each stage, a child workflow resolves context from the change, the task and acceptance criteria, the affected components, the resolved profile and the actor's authorisation. It reads repository documentation first, derives queries, and calls the knowledge port, which exposes three verbs: Search, Fetch and Resolve. Results are deduplicated by digest, redacted for secrets and personal data, ranked, and selected with a written reason. The resolver then flags stale or conflicting sources and lists unresolved questions. It stops at the stage budget.
Resolution is read-only. A planning model may help derive queries, but it runs under a read-only grant with no ability to write tools.
Identity and access
- By default a run uses the delegated access of the human who triggered the change, so the bundle can only hold what that person can see.
- Unattended runs use a service account whose effective scope is the intersection of its grant and a policy listing allowed spaces and projects.
- Each source records its access basis. Restricted sources are marked and their text is kept out of pull request descriptions.
- If a principal loses access, existing bundles remain immutable evidence but are not reused; the resolver fetches again under current authorisation or marks the source inaccessible.
Trust classes
| Input | Trust | May create enforceable authority |
|---|---|---|
| Retrieved knowledge, tickets, tool output | Untrusted | No; cited as guidance only |
| Files in the worktree | Repository authored | No |
| Signed skill | Advisory | No |
| Signed policy and kernel | Authoritative | Yes |
The bundle separates authored_constraints, which come from signed policy and are enforced, from cited_guidance, which comes from documents and is advisory.
Tool pinning and the bundle
Knowledge servers reached over MCP are approved read-only subsets. Their tool inventories are pinned by name and hash. Drift quarantines the connection until re-approved. Read-only is enforced by the server where possible, the pinned allow-list, and the broker's refusal of any non-read capability on a knowledge connection. The executor never gets enterprise MCP servers; it sees only the bundle, delivered as a read-only directory and a bundle tool.
Receipts and reproducibility
Each search and fetch produces a retrieval receipt that binds the principal, authorisation context, source version and content digests. Two searches can return different results across a crash, so each resolution has a generation: the first persisted result for an operation is the result for that generation, and a refresh opens a new generation instead of mutating a bundle.
Boundary table
| Party | Holds | Cannot do |
|---|---|---|
| Resolver | A read-only knowledge grant | Write to any source |
| Knowledge provider | Source credentials by handle | Widen the connection's scope |
| Executor | The finished bundle | Query enterprise systems directly |
| Cache | Authorisation-bound fetched documents | Serve a body to a different authorisation context |
Failure cases
- Unresolved question that blocks a change: reported back to the ticket instead of guessed.
- Source conflict: both claims are returned; the resolver does not pick silently unless a pack declares precedence.
- Tool inventory drift: connection quarantined, resolution fails closed.
- Stage budget reached: the bundle is returned incomplete with the gaps listed.