conceptual Architecture specification, not a built system. The registry data model, sealing, and scoring it relies on are implemented in this prototype and run in your browser; the federation layer around them is not built.
TargetSpace scores sealed probability distributions against rule-resolved outcome keys — not raw evidence. That makes a federated deployment possible in principle: raw longitudinal capture stays inside the participant’s or data holder’s enclave, and only sealed prediction hashes and distributions, resolved outcome keys, and aggregate score reports cross to the registry.
The four records in the pipe are the complete crossing set. Everything to their left is generated, stored, and consumed inside the enclave.
| Component | Status | Notes |
|---|---|---|
| Registry data model (runs, instances, sealed predictions, outcomes) | implemented | Running in-browser here, backed by local storage |
| Sealing — canonical hashing, seal-before-resolution refusal, tamper-evident ledger (hash-chained) | implemented | Running in-browser here; chain verifiable on the registry page |
| Scoring pipeline (skill, calibration, controls, gates) | implemented | Pure functions; running in-browser here |
| Local runner packaging (enclave deployment for data holders) | conceptual | Specified above; not built |
| Encrypted audit package with holder-held key | conceptual | Dispute-resolution path; not built |
| External timestamp witness | conceptual | Prototype witness is the local ledger chain itself |
Why federation is possible at all: in the TargetSpace protocol, the object of evaluation is the sealed prediction and its resolved outcome — not raw capture. A benchmark that scored transcripts or raw logs would have to move them; a benchmark that scores sealed distributions against rule-resolved outcome keys needs only the distribution, the key, and the hashes that prove when each existed. This page specifies how that property could be deployed; it does not claim that it has been.