Your setting.
A scoped research system.
A scoped deployment study
Define the reference corpus, model and infrastructure requirements, held-out evaluation and failure cases, then agree data and release terms. Privacy and escalation depend on the chosen configuration. Signed records support inspection.
Discuss deploying Photon against a defined reference corpus and model configuration. This is a collaboration around a research system, with dependencies, access and licensing reviewed for the proposed setting.
The grounded core runs where your data already lives.
The grounding engine, the fact registry, and the receipt signer run on one machine you control. When the engine answers from your records or abstains, your documents, your queries, and your answers stay on that box. You hold the signing key and publish only the public half — so anyone can verify a receipt without ever seeing the data behind it.
We turn your ground truth into a record the engine answers from — or abstains — instead of guessing.
A pack is your own domain facts — a product catalog, an SOP or compliance ruleset, an approved-vendor list, a parts database, a drug formulary, a legal-citation corpus, an internal wiki — turned into a grounded registry. Every entity is bound to a source record you designate as ground truth. When someone asks about your facts, the engine answers from that record, flags a near-miss (“did you mean…”), or abstains. It’s the same machinery that grounds public genes, CVEs, RFCs, chemistry and clinical-trial records on our live demo.
Every answer is designed to sign itself.
Each answer carries an ed25519 receipt — the question, the answer, and the sources — signed by a key you control. Anyone you share it with can re-verify it against your published public key — with one small verifier file, offline, no callback to us or to you, and any tampering is rejected, because the signature is bound to the exact answer. It’s an audit trail for what your AI said and why, without exposing the data underneath. You can watch this exact mechanism run on our public demo today →, where the receipt loop is verified live end-to-end.
Choose evaluation and failure cases for the setting.
A deployment study begins with a specific corpus and use case, explicit failure conditions, privacy configuration and release terms. A catalog entry does not establish suitability for a high-stakes setting.
Four steps, one domain at a time.
We scope your facts
You bring the ground-truth source — a catalog, a ruleset, a corpus. We map what a grounded record looks like for your domain.
We build the pack
Your facts become a grounded registry with near-miss and out-of-registry detection, validated against held-out examples from your own data — so the engine answers from source or abstains.
You deploy on your hardware
The grounded core runs on one machine you control — the registry, the receipt signer, and a mid-brain model. We scope the hardware with you, and you generate the signing key.
Every answer is receipted
Answers ship with a signed, re-verifiable receipt against your published key — a checkable trail for every response.