Frazer Context

Frazer Context decides what every agent session, every review, every plan check and every panel receives, and proves it. It is the platform the other products call: Fir’s sessions, Frazer Reviewer, the plan checks, the panels of decisions, Why on any line, Today’s summaries, Knowledge and search all ask Context, so they share one set of rules about what is current, what binds and what may be read. It holds your handbooks (what every agent is told) and toolboxes (what it may call), assembles each context with rules that put correctness before size, ranks and trims what does not fit, keeps what binds through every compaction, lets models of other families check the result, and writes a receipt of what was given.

Part	What it does
Handbooks and toolboxes	What every agent is told and what it may call, released in channels and delivered to every surface
Assemble	The context for a use: the correctness rules, the authority of each source, conflicts, references checked against the workspace, unknowns, In force (Agents and plans)
Retrieve and locate	Candidates from the link graph first (what the plan links, what covers the touched paths), then search; for a symptom, the files and line ranges a task needs
Rank	Rules first, then Frazer Rerank on what the rules allow, only when the candidates do not all fit
Summarize and prune	Each source at the level of detail its score per token earns: whole, pruned to the sentences the task needs, summarized, or a handle
Compact	Frazer’s compaction: what binds re-derived, the artifact trail computed, outputs kept as handles, only exploration summarized
Verify	Models of other families read the context cold; depth, what they read and strictness are settings
Receipts	What a context held, chained and exportable, so anyone can check it without Frazer

The platform every product calls

Every product asks for context through one contract:

Assemble {use, target, budget {tokens, latency_ms, cost}, policy?, lineage?, as_of?, parts?, explain?, idempotency_key}
  → {parts[], ranking, verify, usage {processed_tokens by step, cpu_us, cache}, receipt}

Use	Who calls	What it asks for
`session`	The Frazer harness and every harness door	The session context, In force, notices, compaction
`review`	Frazer Reviewer’s code, security and cold reviews	What is in force for the diff; the sources a finding cites
`plan_check`	The plan checks’ `links` and `analyze` stages	Authority, supersession, references and typed conflicts for a plan version
`panel`	The evidence pack of every decision	Decisions in force, precedents, history at the `lineage` level
`why`	Why on any line	Links, and the decisions then and now
`summary`	Today, programs, plan headers, notifications	A narrative’s citations and grounding; cards come from Fir’s rows
`knowledge`, `search`	Frazer Knowledge; Fir search and Find	Rules first, rerank, prune; the order of plans, records and code
`api`	Your own agents, through the API, MCP and SDKs	Rerank, prune, ground, locate, compact and verify on any text, and assembly over your Fir records

A use loads its profile: a versioned record of defaults (tiers, budget, parts, ranking on or off, the verify preset, the lineage default, cache scope). Context owns each profile’s floors (the rules always run; In force is never cut), and the product that calls owns its defaults within them.
One rule set, one ranker, one receipt format for every use. A product built on Context never re-implements authority, supersession, In force, permissions, references or receipts.
Products extend it with part kinds. A product, or you through a record type, may register a part kind with a JSON Schema, its authority rank, its freshness trigger and how it renders for each harness (the Reviewer’s prior findings, a decision’s evidence matrix, a team’s on-call note); the rules run on it like on any part, and the receipt names it.
Each use has a conformance suite in Frazer CI, and a product that builds on Context passes its use’s suite on every release. A change to the rule set, a profile, the renderer or the ranker ships behind a per-model eval gate, a soak and a canary.

Proof by what could go wrong. What Context returns is proved by the harm a mistake would do:

Class	What it covers	How it is decided	How it is proved
Binding	In force, supersession, authority, permissions, references, earlier values	Deterministic Rust; no model	Invariants and property tests in CI, the correctness eval, the conformance suites
Selection	Which sources, in what order, at which level of detail	Rules, then stored features, then Frazer Rerank	Eval gates with regression sets, measured per release
Narrative	Summaries, compaction narratives, explanations	Written by a model, every sentence cited and grounding-checked, labeled “derived, cited”	Faithfulness and coverage per route; never binding, never the source of a state or a number

Service levels per use, designed for at the cell and published on Frazer’s status page: session 2 ms at the median and 10 ms at p99 without ranking, 20 and 60 ms with it; review 2 and 10 ms; plan_check 1 and 5 ms; panel 5 and 25 ms; why 3 and 15 ms; a summary narrative within 60 seconds of its trigger; the api rerank of 100 documents of 512 tokens in 60 and 150 ms; availability of 99.9 to 99.95 % a month by use. Degraded is never silent: without ranking the order falls back to stored features (“ranked by features: ranker unavailable”); without verify’s budget or panel it falls to the floor preset with a label; if Context is unreachable, the harness keeps the last receipt’s In force and marks the session degraded.

Tenants are isolated, and so are caches. Each organization’s index, caches and receipt chain live on one shard; memory and admission are accounted per organization, and the rerank endpoints queue fairly per organization and per use (sessions before reviews, reviews before plan checks, interactive calls before batches), so one organization’s burst cannot slow another’s sessions. Every cache key starts with the organization and, where content differs by reader, the permission class; Frazer’s model endpoints keep prompt caches per organization. Assembled contexts, rerank scores and summaries are cached by everything that shaped them, invalidated by a new record version, a notice, a permission change or a new ranker version, and every receipt records whether its assembly hit the cache and why a provider’s cache missed. The deterministic path, the rank orchestration, the receipts and the compaction driver are Rust; models run only for reranking and pruning, grounding, embeddings, narratives and verify.

Rank: rules first, then the model

Phase	What happens
1. Rules	Superseded and restricted candidates are excluded; a draft is placed below what it would replace; In force and the task go first and are never ranked; freshness and trust are labeled
2. Features	Stored facts score every remaining candidate: the link to the plan (`implements`, `governs`, `covers`), path and symbol overlap with the changed files, call-graph distance from the changed symbols, type and section, freshness, authority, size
3. Model	Frazer Rerank scores the top 50 by features against the task, only when they do not all fit the budget
4. Combine	The model’s score and the features combine so that, all else equal, a fresher or higher-authority source never scores lower; then packing by score per token

What is current and what binds is never a model’s call. Each candidate reaches the model with a one-line header that carries what a general reranker cannot know from text, and the query is a task key of at most 64 tokens (the item, the changed paths, the subjects), never the task’s prose:

[decision · accepted, in force · governs services/checkout-api/payments/** · must · ADR-0031 · as of main@48213]
ADR-0031: Idempotency keys on every call to the payments gateway ...

Ranking is needed only when candidates do not fit. A typical session’s sources fit its budget, so no model call is made; ranking runs for large plans and programs, related sources from search, Why answers that list many records, and Knowledge queries. explain shows each phase: which rule excluded what, each feature’s contribution and the model’s score.

Frazer Rerank

Frazer’s own reranker is a cross-encoder built for engineering work: code, plans and records. General rerankers rank by words, and text alone cannot say that a decision was superseded, that a runbook governs another service, that a must decision outranks a prefer document, which version the workspace is bound to, or which of nine sentences a task needs. Frazer Rerank reads the header, prefers the source that governs or covers the changed paths over one that only shares words, the section whose symbols the task touches, and the smallest part that answers. Rules keep supersession, permissions and In force out of its hands; it orders what is left.

Variant	For
`frazer-rerank-1`	Frazer endpoints, on the fleet or on your own GPU servers (the default)
`frazer-rerank-1-multilingual`	Records written in other languages
`frazer-rerank-1-edge`	Frazer-managed devboxes and servers; laptops call an endpoint
An adapter for your organization	Trained on your records only, when your organization turns it on

Where it runs, and its weights. Frazer Rerank runs only on Frazer endpoints: on the Frazer fleet, and as Frazer endpoints on your own GPU servers, from an encrypted artifact decrypted only on a node Frazer runs that passes attestation; on GPUs with confidential computing, the weights and your requests stay encrypted outside the trusted environment. Its weights are not downloadable. An offline laptop uses an open reranker on a local route.
What stays open: the rules, every format, receipts, a rerank route for any reranker, the recipes, the eval kit, and Frazer Rerank’s model card: what it is for, its data sources by kind, every eval result against the hosted rerankers, and its limits. No lock-in comes from the model: route ranking to another one and you lose only the engineering-tuned order, which the eval quantifies.
Each variant has a prune head: for every sentence of a candidate, the chance the task needs it, so the assembler can send “4 of 9 sentences” of a long section verbatim, with the whole section one handle away. Kept text is the source’s own words, so pruning never paraphrases a rule. Long documents are scored by their best window.
Trained on what happened. Fir knows which sources a session was given and cited, what it fetched later because it should have been sent, what the merged change touched, whether the change stayed merged, and what the Reviewer found against a source the session never got; these labels train Frazer Rerank, with superseded, stale, neighboring-path and draft sources as hard negatives.
Your data, your choice. Your sessions and records train only your organization’s own adapter, and only when you turn on constraints/context.trainOnOrgData (off by default); the adapter stays in your organization and is deleted with it. Contributing to the shared model is a separate opt-in that sends relevance labels, never text, and never for regulated data.
Default only by evidence. A new version replaces the default only when it beats it on Frazer’s engineering sets (code retrieval from merged pull requests in held-out repositories, records and decisions, long sections) without losing on public ones, and passes the set where a superseded decision must never rank above the current one. Its scores are calibrated to the previous version’s, so thresholds keep working; it ships through channels with rollback, and every receipt names the ranker version.
Interchangeable. The LLM gateway has a rerank route kind that speaks the common /v2/rerank request shape, so Frazer Rerank, your own reranker and a hosted one swap without changing a client.

Locate. context_locate {query, repository, budget} returns the files and line ranges a task needs for a symptom that text search cannot answer (“why does capture fail on empty carts”): Fir search for candidates, the code graph to expand them, Frazer Rerank to order them, at most 4 serial steps with parallel reads, and extractive output with anchors. It is in Fir’s default toolset and the api use, and the places it located enter the session’s receipt.

Summaries and pruning

Level	What is sent	When	Label in the context
Whole	The section verbatim	It fits and scores high	—
Pruned	The sentences the prune head keeps, verbatim, in order	A long section with a few needed sentences	“4 of 9 sentences · whole section: handle”
Summary	The record’s stored summary card and its checked narrative, with the version and digest it describes	A plan, program, milestone or long record the task needs to know about, not follow line by line	“summary of #41 v5 · card digest …”
Handle	Title, reason, tokens and a handle	It does not fit	“left out: no changed path”

Summaries exist for plans, phases, programs and milestones (a card from Fir’s rows and a short narrative), long record sections, decisions (their history at the lineage level, rendered without a model), code (file, module and symbol summaries, extractive first), sessions (handoffs and compaction narratives) and threads (the decisions and open questions of a review thread, quoted with their authors). Seven rules hold for every kind:

Facts come from rows; prose explains them. States, numbers, owners and dates are fields of a card or quoted verbatim; a narrative never states one that is not in its card or its cited source.
Extractive before abstractive. What a task must act on is sent in the source’s own words, whole, pruned or quoted, with anchors and line ranges.
Every sentence cites, and the grounding check passes before a narrative is stored; a sentence that fails is dropped, and a narrative that fails twice is replaced by its card with “In short: not available”.
Stamped and fresh. A summary records the digest it describes; when that changes, readers see “as of v4·3; changed since” and the card first, and the narrative is regenerated within 60 seconds of a material change.
Never binding. In force, the task, conflicts and unknowns are never summarized; compaction drops history blocks and keeps their handles.
The summarizer is chosen by measured faithfulness, per organization: the model with the fewest unsupported sentences on Frazer’s grounding check over your records, measured again monthly; a small open model on Frazer endpoints by default.
Levels are computed, not clustered. Rollups (phase, plan, program; file, module, repository) are computed from rows along the changed path, and a broad question is answered from the rollup at the right level.

Summaries are designed to be faithful in at least 99 % of the sentences shown to a person or a model, to cover at least 95 % of the facts their kind must mention, and to be read stale at most 2 % of the time.

Compaction

A compaction is structured, not prose. It replaces a session’s history with:

Part	How
In force, the task, unknowns, conflicts	Re-derived from Fir at the bound version, verbatim; never taken from the transcript
The person’s words (requests, corrections, preferences, what was ruled out); decisions taken under “you decide”; assertions and verdicts; notices and acknowledgments	Verbatim, from the session’s events
Files changed, with the workspace diff as a handle; commands with their last result and every failure and its fix	Computed
Steps	The latest list
Tool outputs, file reads, CI logs	Handles: the newest listed, older ones grouped with a query handle
Exploration: approaches tried and rejected, the current hypothesis	Written by a model in a short budget that the driver enforces by cutting at sentence boundaries; every statement cites events that must resolve, and the grounding check runs on it
Reads older than the file’s last edit, duplicate reads	Dropped and counted

Every provider’s own compaction summarizes what binds along with the rest, and the artifact trail is the weakest part of any model-written summary, so Frazer computes what a model gets wrong and keeps everything else one read away. A provider’s own compaction may run over exploration text only. Where a model supports turn-scoped system messages, the closing checklist goes in as one, so it never piles up and keeps the prompt cache. In each harness:

Harness	At compaction
The Frazer harness	Frazer’s compaction by default, or a fresh start seeded from Fir with the handoff where that works better for the model family
Claude Code	The managed instructions file says what a summary must keep; the session-start hook re-sends In force after compaction; the summary it writes is grounding-checked and stored
Codex	The session-start hook re-sends In force after compaction
Gemini CLI	In force is restored before each model request when compression dropped it
Your editor’s agent, or any MCP client	The server’s instructions tell it to call `get_session_context` again after a compaction
An agent built on a model provider’s API	A recipe: keep what binds through your provider’s compaction

When a compaction’s narrative cites an event that does not exist, it is rewritten once, then dropped for handles; an unsupported statement is removed and listed as a finding. Compaction is designed to keep In force obeyed after three forced compactions in at least 98 % of runs, and no single compaction may leave a session worse than continuing without it; it stays on by default for a model family only where the eval shows it wins.

Verify

Verify has three settings:

Setting	Values	Means
Depth: how deep	`off`, `light`, `standard`, `deep`, `exhaustive`	How many other model families, on which tier, at what effort, how many passes: the panel’s ladder (Decisions)
Reads: what is checked	`context`, `written`, `sources`, `compactions`	The assembled context at start and on material notices; model-written text (intents, notes, handoffs, plan edits, milestone drafts) against what it cites; the full text of cited sections; every compaction’s narrative
Strictness: what a finding does	`advise`, `ask`, `block`	A notice; an answer the session owes before its next layer; a block on the next layer until it is resolved

The deterministic checks always run and are not a setting.

Preset	Depth	Reads	Strictness	Default for	Report ready (p95)
`light`	One other family, fast tier	context, written	advise	R0, R1	designed for 10 seconds
`standard`	Two other families, balanced tier, a critic on a split	context, written	ask	R2, and any context with an unresolved conflict	45 seconds
`deep`	Three other families, two frontier and one open model on Frazer endpoints, strongest tier, a critic always	and sources	block	R3	3 minutes
`exhaustive`	Three other families, strongest tier, two passes	and compactions	block, with a sample of findings to the accountable person	By choice	10 minutes

Settings layer from organization to project, path, plan and session: a locked setting cannot be lowered below, a default one can, and a session may raise its own. Data policy wins: a project whose routes are org-only verifies with open models on its own Frazer endpoints, never with an outside provider. An unchanged context is never verified twice.

How a run works. Each verifier gets the assembled context and the rubric, never the session’s transcript or the other verifiers’ output. Members are of families other than the session’s model, each opinion is sealed before another is read, and a critic reads a split anonymized. The session starts at once with the deterministic context, and the report arrives as a notice; a layer waits for it only where strictness is block. Where verify reads written, a small model on Frazer endpoints checks each model-written statement against the sources it cites. Verify runs on Frazer Reviewer’s engine and keeps its own name.

Finding	Example	What happens
`contradiction`	A runbook step says shoppers “must pay again”; the plan says a timeout “returns 202”	A conflict with both quotes: the higher-ranked source is in force; equal ranks become an unknown and a decision row
`unsupported`	A handoff says “AC2 holds” with no citation	Shown to the session to cite or remove; at `block`, the layer waits
`misquote`	A summary or pruned part misstates its source	The part is replaced by the source’s verbatim text; the summary is marked stale
`missing`	The task needs a value no part holds	An unknown, with a question to the plan’s owner
`instruction_in_data`	A comment in a record tells the agent to skip tests	The part’s trust label is raised and the gateway’s injection check is told
`old_value`	An intent says 30 s where 20 s is in force	Below: the old-value check

Findings are stored as SARIF 2.1.0 and carry “found by k of n” and a calibrated confidence. Blocking is earned: at block, a question blocks at once, and other model findings block only once their kind is calibrated (the 95 % lower bound of its precision on its last 200 resolved findings is at least 0.8); a deterministic finding needs no calibration. Agreement between families ranks a finding but never blocks by itself. Budgets default to $1.50 a run and, per project-month, 10 % of the project’s session model spend with at least $250; when a budget is spent, verify falls to the floor preset with a label on every context it touches, never silently. The cold review of plans runs on the same engine (The planning flow).

Superseded text and the old-value check

Superseded text never comes as a source. History comes only through the lineage setting (off, reasons, brief, redline), never as In force, always marked as not in force, and dropped at compaction. Old values in a model’s input pull its answers back even when the current value sits right before the question, so by default no session sees an old value: work under a decision with a reversal in its history gets reasons (when and why it changed, and that reverting needs new evidence, with no earlier value), work that changes the decision and every panel member gets brief, and the superseded text itself comes only on request, one decision at a time. Each level, who sets it and how history is marked: History that models see. Every receipt records lineage {level, decisions}.

The old-value check is deterministic and runs before any model. Fir knows every typed subject’s current value and its earlier ones, so every model-written text (an intent, a plan edit, a note, a handoff, a pull request’s description) is checked before it is accepted, through the subject’s units and aliases. A value that equals an earlier value of a subject in force is a finding of kind old_value at the session’s strictness, with the decision and since when; the session fixes the text or cites the decision that allows it. When many sessions write the same old value, it becomes one exception group with one decision, usually “the code still holds the old value: change the constant, or reopen the decision”.

Demo (Pellwyn, Oct 17, product UI, demo data). The count line on Context: today at Pellwyn reads “4 need you (covering 54) · 13,900 calls · 2,070 assembled · 307 ranked · 9 of 9 uses within service levels · 1,000 pull requests”. The first group, old value of ledger.posting_timeout · covers 37: 37 sessions on pellwyn/payouts wrote 30 s; 20 s has been in force since Oct 15 by pellwyn/plans#311 §D1; ledger/client/timeout.go still says 30 * time.Second; one decision: open the pull request that changes the constant, or reopen the decision. The first catch was session s-2b84 on pellwyn/payouts#93: its intent for layer 2 said 30 s, the check flagged it before the layer opened, and v2 says 20 s and cites #311 §D1.

The rerank and grounding APIs

Frazer Rerank is also an API for your own agents and search, outside Frazer Context’s assembly.

Call	Unit	Price
Rerank with the prune head (`/v2/rerank`; `frazer-rerank-1`, `-multilingual`)	Processed tokens	$0.02 per million
Grounding check (`/v1/ground`): the claim and the cited text	Processed tokens	$0.02 per million
Batch (`batch: true`, a 12-hour window)	Processed tokens	$0.0134 per million
Locate (`context_locate`)	Its rerank and embedding tokens at the prices above; search is free	—
Assembly over your Fir records: rules, In force, receipts, notices, the old-value check, computed compaction	Call	$0, rate-limited

Processed tokens are query tokens × documents + document tokens, counted with the serving model’s own tokenizer, which every response names. A long document is split into windows (4,096 tokens by default) and scored by its best window. Special tokens the model adds and the header Frazer renders from a document’s own fields beyond its first 32 tokens are not counted.
The first 100 million processed tokens a month are free for every verified organization (a payment method or a verified domain), across rerank, prune, grounding and batch.
Before and after. ?estimate=true returns the processed tokens and the price before a call; every response returns them after, in the x-frazer-receipt header with the model version, the tokenizer, the price, the free tier left and the cache state. Budgets and hard caps per key and project pause calls at the cap with a typed error, never a silent cut, and failed calls are never billed.
Limits, published with the API: at most 1,000 documents and 600,000 processed tokens a request, and a query of at most 2,048 tokens; rate limits per organization by tier (the free tier 300 requests and 2 million processed tokens a minute; with a payment method, 2,000 requests and 10 million); Frazer endpoints on your own servers have no rate limit but their own capacity. Over a limit, 429 with Retry-After and the limit that applied.
Documents are data, never instructions: Frazer Rerank scores text and follows nothing in it. Keys used from many networks at once, or with a sudden jump in volume, are paused and your admins are told.

Demo: Pellwyn’s own triage agent, outside Frazer, calls /v2/rerank with 100 issues of up to 512 tokens and a 40-token query: 55,200 processed tokens, receipt rr-1c9e. Acme’s receipt rr-7b20 names frazer-rerank-1@1.0 and its tokenizer, 9,112 processed tokens, inside the free tier.

Open, no lock-in

Part	With your own models instead of Frazer’s	What you lose
Correctness rules, In force, receipts, conflicts, references, unknowns, the old-value check, the compaction’s computed parts	The same: they use no model	Nothing
Ranking	Any reranker on a `rerank` route, or none	The engineering-tuned order
Pruning and summaries	Your route; or whole sections and handles only	Tokens
The compaction narrative	Your route, or your provider’s compaction with Frazer’s instructions, then In force re-sent	Narrative quality on your model
Verify	Your routes as panel members, or your own reviewer through the API	Nothing structural
The grounding check	A route of kind `ground`	—

Session contexts, compactions and policies are JSON with a published JSON Schema per version, rendered as Markdown for models; receipts are in-toto statements, and each shard signs a Merkle root of the receipts it issued every second; findings are SARIF 2.1.0; spans follow OpenTelemetry’s generative AI conventions. Everything exports through the API and frazer context export. Context recipes show how to do each part with your own models.

How it changes

What	How it is versioned	How agents see it
The context format	`frazer.context.v1` with additive minor versions; a breaking change is v2 with twelve months of overlap	A JSON Schema per version; the receipt names it
The correctness rules, use profiles and renderer	Versioned, each rule with an ID and a reason, released behind a per-model eval gate, a soak, a canary and rollback	The receipt names each version; a notice when a rule that shaped a running session changes
Frazer Rerank	Model versions and adapters, behind the eval gate, scores calibrated to the previous version	The receipt names the ranker; `explain` shows its scores
Verify and compaction rubrics	Versioned with the review engine; precision measured per version before a kind may block	Findings carry the rubric’s version
Presets and defaults	Policy data; a change is a plan with a replay on the last 90 days	The policy page and `context_policy`

Commands and tools

frazer context resolve --repo acme/storefront --path services/payments --client codex
fir context --session s-81f2 --part 1 --explain

Command	What it does
`frazer context resolve`	What an agent would get for a repository, a path and a client
`frazer context rank`	Rank sources for a task, with each phase explained
`frazer context compact`	Compact a session’s history
`frazer context verify`	Verify a context or model-written text at a depth and strictness
`frazer context policy`	The verify, ranking and compaction policy in force for a scope
`frazer context export`	Export contexts, compactions, policies and receipts
`frazer context sync`, `frazer context doctor`, `frazer context uninstall`	Render your handbooks for the agent clients installed on this machine; check what they load; remove what Frazer wrote

MCP tool	Does
`context_resolve`, `context_skill`, `context_rule`, `context_release`	What applies to a target; a skill, a rule or a handbook release
`context_rank`	Rank candidates for a task, rules first, with `explain`
`context_locate`	The files and line ranges a task needs for a symptom, extractive, with anchors
`context_compact`	The computed parts of a compaction and its handles, for your own narrative
`context_verify`	A verify run at a depth, reads and strictness; returns the report
`context_policy`	The policy in force for a scope, with its version
`context_tools_find`, `toolbox_calls_list`	Tools in your toolboxes; calls made through them
`get_session_context`, `ack_context`	The session context and acknowledgments, in Fir’s default toolset

The context toolset is read-only by default; write tools create proposals and plans, never applied changes. Large toolboxes add find_tools and call_tool, so an agent never loads hundreds of definitions, and every call is first resolved against the caller’s tools and the tool’s signature: a tool that does not exist, or an argument it does not take, returns unknown_tool or unknown_argument with the closest real ones.

Context recipes: each part with your own models
Agents and plans: what a session receives and how In force is enforced
What agents get: what an agent needs, and how Frazer gives it
Decisions: the lineage setting
LLM gateway: routes, including rerank
Knowledge: the knowledge bases Context retrieves from