Share signal, not evidence
A platform can communicate that a bounded signal exists without exposing the underlying data, identities, or content.
Turnkeeper Labs · Specification 001
Safety Exchange Protocol v0.1
A working draft for coordinating bounded safety signals without sharing raw evidence or transferring enforcement authority.
Working draft · Research specification · No live network
Custody boundary
Leavesbounded signal
- Signal type
- Severity band
- Provenance
- Sharing scope
- Local evidence pointer
Stayscustomer custody
- Raw content
- Identities
- Full logs
- Enforcement authority
Fig. 01 — Request only · receiving platform owns the outcome
Research question
What would a minimum-necessary exchange look like?
How can safety systems exchange the minimum necessary intelligence, preserve provenance and uncertainty, correlate observations over time, and support explainable human decisions without centralizing sensitive underlying data?
Protecting children online requires people and platforms to coordinate. Individual detectors identify observations. This specification studies the layer above them — the one that turns heterogeneous observations into structured, explainable, privacy-conscious case intelligence. Adjacent industry systems show parts of this problem space; none of them are Turnkeeper partners or integrations, and Turnkeeper does not currently operate a live cross-company safety-intelligence network.
Purpose
Coordinate without coercing.
Built for platforms that want to help each other keep people safer while consequential decisions stay in customer hands.
Request, not enforce
One platform asks another to consider an action. The receiving platform keeps full authority over any outcome.
Leave a review trail
Every exchange is logged so specialists can inspect what was shared, why, and what was decided by whom.
Scope progression
Local first. Federation only if it earns it.
Each phase has explicit exit conditions. Nothing advances because it is technically possible.
Local interoperability
Multiple detectors and sources inside a single customer-controlled environment. No cross-company raw-data exchange. Exit conditions: a common schema across at least three source types, explainable cases carrying provenance, measurable lift over the strongest single-source baseline, and raw content that never leaves the customer boundary.
Phase 1 · First mode
Bilateral federation
Two isolated nodes exchanging synthetic, de-identified, or narrowly approved signals. Exit conditions: enforceable sharing and consent terms, working revoke / correct / expire / audit paths, a measured false-link rate, and each participant deciding independently whether and how to investigate.
Phase 2 · Not started
Consortium network
Considered only after the first two phases succeed, and only with independent governance. Exit conditions: published participation rules with human-rights and security controls, no raw evidence access unless separately authorized, and demonstrated value without unacceptable privacy or due-process risk.
Phase 3 · Conditional
The network is optional. The protocol must create value in a local-only deployment before asking any company to participate in cross-company exchange.
How an exchange works
A request with a bounded effect.
Each exchange follows the same sequence so reviewers can reconstruct what happened and why.
Detector emits a candidate signal
A source system produces an observation with its own provenance: what produced it, when, and under which model or rule version.
Gateway normalizes and minimizes
The signal is normalized to a common schema, calibrated, minimized to the fields needed, and signed. Raw evidence stays local.
Evidence layer correlates into a case
Signals are linked into a tenant-scoped case where contradictions and exculpatory observations are preserved rather than discarded.
Specialist reviews the case
A person reviews the hypothesis alongside counterevidence and records a disposition with reasoning.
Exact-effect authorization is issued
If any action follows, it is bound to an exact reviewable effect. The customer platform executes it and owns the outcome.
Optional gated contribution
Only privacy-minimized, eligible signals may be submitted to a governed exchange — for another participant's separate local review, never for automatic action.
Working signal contract
Properties the envelope has to guarantee.
The schema is a draft. The properties below are the part we are actually testing.
Extensible taxonomy
Usable across harm domains without forcing every participant into one fixed taxonomy.
Explicit provenance
Producer, model or rule version, and calibration travel with the signal.
Separated dimensions
Confidence, severity, and policy relevance are distinct fields, never one blended score.
Time-bounded and revocable
Signals expire and can be corrected or withdrawn after they are sent.
Contradiction-friendly
Exculpatory and conflicting observations are first-class, not silently dropped.
Local evidence pointers
References point at evidence held in the producer's boundary instead of transferring it.
Explicit sharing scope
Every signal declares whether it is local only, bilateral, or eligible for a governed exchange.
Signed and auditable
Signatures and logs let reviewers reconstruct what was shared and by whom.
safety-signal.d.ts0.1-draft
// SafetySignal · schema 0.1-draft · truncatedtype SafetySignal = { signal_id: string; // uuid schema_version: "0.1-draft"; producer: { org_ref: string; system_ref: string; model_version: string; }; observed_at: string; // ISO-8601 subject_refs: Array<{ type: "pseudonymous_ref"; value: string }>; harm_domain: string; signal_type: string; score: number; // 0.0–1.0 calibration: { method: string; reference_set?: string }; severity: "low" | "medium" | "high"; evidence_ref: string; // local pointer — never inline content privacy_class: string; sharing_scope: "local_only" | "bilateral" | "consortium"; retention_ttl_days: number; provenance: string[]; // derivation steps signature: string; // detached};Fields are shown truncated for readability. Subject references are pseudonymous, evidence references are local pointers rather than content, and sharing scope is explicit on every signal so nothing travels further than it was authorized to travel.
Correlation principles
Rules for combining observations.
Correlation is where a coordination layer either strengthens human judgment or quietly replaces it.
Never treat a shared signal as proof
An incoming signal is an observation to investigate, not a finding about a person.
Do not collapse evidence too early
Keep the underlying observations distinguishable instead of flattening them into a single verdict.
Model dependence between detectors
Detectors trained on overlapping data are not independent votes and must not be counted as such.
Measure entity-link confidence separately
How confident we are that two observations concern the same subject is its own quantity.
Allow contradiction and correction
Cases must accept later evidence that weakens or reverses an earlier interpretation.
Use temporal context
Recency, sequence, and decay change what a set of observations can support.
Require proportionality
The strength of a recommended effect must match the strength and class of the evidence.
Keep humans accountable
High-impact decisions stay with named people who can explain them afterward.
Mechanics
Four invariants of every exchange.
Signal binding
A recommendation is bound to an exact, reviewable effect so it cannot silently expand in scope.
Authority separation
The protocol carries no enforcement power. It only helps a platform make an informed, owned decision.
Provenance logging
Metadata about the request, the signal class, and the response is retained for later review.
Customer-owned outcome
The responding customer controls whether and how to act. Turnkeeper does not decide on their behalf.
Public artifacts
From local signal to local review.
The protocol carries provenance, purpose limits, evidence tiers, and expiry. The protocol never carries raw messages, direct identities, or automatic enforcement.
- Working draft and schemaOpen the draft →
Read the contract, field definitions, and the boundary conditions in the public repository.
- Synthetic fixtures and validatorsExplore the SDK →
Inspect positive and negative examples that make the contract testable before live exchange.
- Machine-readable schemaOpen safety-exchange-2026-08-08.schema.json →
Inspect the typed envelope used by fixtures and validators.
Boundaries
What the protocol is — and is not.
Is
A sponsor-informed applied research specification, published as a working draft.
A privacy-minimizing interoperability contract for bounded safety signals.
A proposed path from research toward deployable infrastructure.
A structure for provenance, uncertainty, review, and audit.
A request format that keeps enforcement authority with the receiving customer.
Is not
A global reputation database or ungoverned sharing authority.
A data broker or a warehouse for raw private messages.
Automatic punishment because another company sent a signal.
A replacement for a customer's internal safety stack, policy, or legal process.
A claim that every research prototype is production-ready.
A surveillance mechanism for raw content or identities.
Help shape a safer way for platforms to coordinate.
We are testing the contract against real review workflows with design partners. If your team coordinates safety signals across systems, we would like to learn from you.