Technical reference

Documentation for engineers, integrators, and reviewers.

Two surfaces handle data differently: the local runtime deployed inside your platform, NGO, or workstation processes sensitive material, while the hub we host accepts only public-source facts, vetted pack metadata, anonymized aggregate signals, hash receipts, and consented contact metadata. Every card below opens its canonical page.

One-line glossary
Knowledge pack: the artifact. A versioned, downloadable bundle the hub serves.
Corridor pack: a knowledge pack scoped to one migration corridor (e.g. PHL-KWT).
Context pack: a knowledge pack when retrieval is loading it into a model prompt.
Vetted pack: any knowledge pack a curator has approved. The default for client pulls.
01 · Local runtime

What runs inside your deployment.

The harness, model, and packs that live on the platform's own infrastructure or the caseworker's own laptop. Raw chats, case files, IDs, and private documents stay there unless an authorized user creates a sanitized submission.

02 · Hub / host system

What we run, in the open.

The append-only public hub: vetted packs, the tools registry, anonymized signals, and the audit feed. Everything here is curator-vetted and reproducible from public inputs.

03 · Internal subsystems

Working pieces, in detail.

Reference pages the architecture overview links into. not entry points. Open these when a section above sends you here.

04 · Reproduce a release

Pull a pack. Verify the signature. Run the eval.

Every vetted pack release is reproducible from public inputs alone. The reproduce script lives in /tools/reproduce; it pulls the pack at a given hash, validates the curator signature, and re-runs the six evaluation suites against a clean Gemma 4 build. Same hash → same answer, every time.

See the harness →