Context integrity infrastructure
Context that earns its place.
AI systems increasingly act on external context that changed after it was retrieved. FreshContext sits between context acquisition and agent action and evaluates whether what is arriving is still fresh, attributable and coherent enough to rely on — returning a signed, ledger-backed verdict rather than a ranked list.
- status
- valid
- verdict_id
- 8fd9ead8…2fa5584b
- engine_version
- 0.5.1
- signature_version
- FRESHCONTEXT_HA_PRI_V4
- key_id
- fc-2026-09-ceced1ab
- verification_method
- ed25519
- reasons
- []
A real record from the live ledger, checked by the verifiers that ship in the npm package rather than by us.
Where it sits
Between acquisition and action.
FreshContext does not fetch for you and does not replace the model. It judges candidate context on the way in, and leaves evidence behind that someone else can check.
| Stage | Component | What it produces |
|---|---|---|
| Candidate context | evaluate_context, adapters, your own payload |
Signals with a source, a timestamp and a claim |
| Evaluation | Core, Source Profiles, decay-adjusted relevancy | Freshness, confidence, provenance, failure honesty |
| Verdict | Decision layer | Use, cite, refresh, verify, background, watch or exclude |
| Attestation | Ha-Pri v4 signing, D1 verdict ledger | An Ed25519-signed record with a verdict_id |
| Verification | /v1/verify, published key document, offline verifiers |
A third party’s own yes or no |
Proof, not promises
Check it without asking us.
Every verdict written to the ledger is signed with Ed25519. The public half of the key is published, and both verifiers ship inside the npm package — so verification needs no account, no API key and no call to FreshContext.
Published signing key
/.well-known/freshcontext-signing-keys.json
serves the active key and every retired one. Keys are append-only, so a rotation
never invalidates a verdict signed under an older key.
Offline verifiers
scripts/verify-offline.mjs (Node, standard library) and
scripts/verify_offline.py (Python, no dependencies at all) are both
in the published tarball. Method and worked examples in
VERIFYING.md.
Ledger lookup
POST /v1/verify resolves a verdict_id against the stored
record and reports which method answered it. Legacy records verify through the
HMAC path and say so; new records are Ed25519 and independently checkable.
Specification and schema
The FreshContext Specification is MIT-licensed, and
freshcontext.schema.json is
served at the identifier it declares.
State of the system
What runs today.
One list, with the evidence attached. Anything not on it is on the open surfaces list instead.
| Surface | State | Evidence |
|---|---|---|
Context evaluationevaluate_context over caller-provided context |
live | npm package, demo |
| MCP interface 22 registered tools; 21 read-only reference adapters |
live | Client setup |
| Ed25519 attestation every new ledger record signed HA_PRI_V4 |
live | Key document |
Verdict ledger and lookup/v1/verify, D1-backed |
live | VERIFYING.md |
| Edge deployment Cloudflare Workers, KV cache, atomic rate limiting, 6-hour cron |
live | api.freshcontext.dev |
| Open specification envelope format, decay model, adapter contract |
live | Specification, JSON Schema |
Use it
Run it through MCP, or call the engine directly.
The published package is the shortest path. Core does not depend on being reached through MCP — that is the seam that keeps this a primitive rather than a single-integration tool.
npx -y freshcontext-mcp@latest
For Claude Desktop, Codex, or any MCP stdio client. Prefer a global install?
npm install -g freshcontext-mcp@latest.
https://api.freshcontext.dev/mcp
Standalone
live Its own context-integrity service, which is how it runs at api.freshcontext.dev.
MCP layer
live Evaluating and governing context around MCP-enabled workflows. The path in this repository.
SDK and API
seam Integrity primitives consumed programmatically, with no MCP in the path. The Core import boundary supports it.
Embedded or white-label
seam Core as a subsystem of another platform, under its branding. Nothing in Core assumes the FreshContext name.
Only standalone and MCP are exercised in production. The rest are integration seams the architecture supports — not shipped configurations, and not claims.
Open surfaces
Built substrate, unbuilt interface.
Stated in future tense because none of it ships today. A defect in the core is a liability; an unbuilt surface is a choice. These are choices, and each one already has something under it.
| Surface | Existing substrate | Remaining work |
|---|---|---|
| Safety harness | Decisions and warnings already emitted per signal, with reasons | The pass / warn / refresh / quarantine / block state machine. quarantine and block appear nowhere in the codebase. |
| Control plane | The verdict ledger is the data contract it would read from | The interface over it. There is no dashboard. |
| Integrity telemetry | Per-verdict evaluation records with timestamps | Historical state, incident history, upstream degradation tracking |
Tracked in full in the repository roadmap, split into production core, expansion surfaces and research frontier.
Get in touch
Technical walkthrough, integration, or architecture review.
Questions about the evaluation model, the attestation path, or how FreshContext would sit in an existing stack are welcome.
Strategic partnership and acquisition discussions: corpdev@freshcontext.dev. Vulnerability reports: security@freshcontext.dev.