Open Wellbeing ProtocolPublic capability demosDeveloper docs
Focused preview · Reviewed demo corpus

A knowledge and screening layer for wellbeing products

From health context to an auditable screen.

Query the graph, screen candidates, trace every decision to its evidence.

Explore the scenarios View endpoint map
1partner write
0silent recommendations
3proof-oriented flows
screening.exchange.json deterministic
RequestPOST /v1/screen
{
  "subject": {
    "medications": [{ "raw_name": "sertraline" }]
  },
  "goals": [{ "code": "sleep" }],
  "candidates": [
    { "raw_name": "5-HTP" },
    { "raw_name": "magnesium glycinate" }
  ]
}
200 OK
NO · Q1 clash5-HTP
excluded_risk
DEFER · Q4 clearanceMagnesium glycinate
deferred_coverage
proof_receiptsha256:e75645…30adtrace attached
01

Content-addressed

Every response carries the corpus id. Pin it per request.

02

Fail-closed

Unknown input and missing context show as gaps or defers, never guesses.

03

Self-describing

Live OpenAPI, closed enums, typed error codes.

04

Proof-oriented

Decision traces, receipts and replay gates, all checkable offline.

Three focused demonstrations

Three workflows, run end to end

Each shows an endpoint chain, a real exchange, and what it proves.

01 / 03

Screen a candidate stack without pretending to recommend.

A partner sends structured context, a goal, and reviewed candidate names. OWP returns a decision proof for each candidate—and keeps selection structurally empty.

1
GET/v1/meta

Load closed vocabularies

2
POST/v1/screen

Run the screen

3
GET/v1/trust

Read the trust posture

Screening request
POST /v1/screen
X-Corpus-Version: live-web@2026-06-28
Content-Type: application/json

{
  "subject": {
    "age": 44,
    "sex": "female",
    "reproductive_status": "not_pregnant_not_trying",
    "medications": [
      { "raw_name": "sertraline", "raw_value": "50", "raw_unit": "mg" }
    ],
    "conditions": { "items": [], "completeness": "explicit_none" },
    "allergies": { "items": [], "completeness": "explicit_none" }
  },
  "goals": [{ "code": "sleep" }],
  "candidates": [
    { "raw_name": "5-HTP" },
    { "raw_name": "magnesium glycinate" }
  ]
}
Verified live capture
{
  "schema_version": 2,
  "mode": "A",
  "screening_id": "scr_0b6d75…9827",
  "results": {
    "selected": [],
    "excluded": [{
      "variant": "5-HTP",
      "state": "excluded_risk",
      "admissibility_proof": {
        "admissibility": "NO",
        "deciding_question": "Q1_clash"
      }
    }],
    "deferred": [{
      "variant": "magnesium_glycinate",
      "state": "deferred_coverage",
      "admissibility_proof": {
        "admissibility": "DEFER",
        "deciding_question": "Q4_clearance"
      }
    }]
  },
  "proof_receipt": {
    "trace_digest": "sha256:e75645…30ad",
    "verified_evidence_id": "vei_33836e…be14"
  }
}
Fixed, non-identifying live demo

The browser can request only this curated scenario. The server controls the path and payload; partner credentials are never exposed here.

Fail-closed by design

Missing detail or insufficient reviewed evidence produces DEFER—not a guess.

Deterministic identity

The same parsed request, corpus, and verified-evidence identity return the same screening ID.

Proof-carrying output

Each candidate includes a four-question admissibility proof and a structurally replayable trace.

Reproducibility at the boundary

Pin what you tested.
Detect what changed.

Send the corpus label you integrated against. If the serving corpus has moved, OWP returns a conflict rather than silently changing the meaning of the response.

Request headerX-Corpus-Version: live-web@2026-06-28
Response identitycorpus_id: sha256:08201334…d65116
Mismatch behavior409 corpus_version_conflict

Partner surface

Sixteen endpoints, one write

Demo liveProvenance labeledPromotion gated

Discover & pin

Discover the partner surface, read every closed vocabulary, and bind an integration to a corpus.

GET/v1

The front door to every partner-visible section of the API.

Demo live
GET/v1/meta

Every closed vocabulary, mandatory notice, and corpus stamp.

Demo live
GET/v1/openapi.json

The live machine contract for the partner plane.

Demo live

Knowledge graph

Resolve shared concepts, traverse bounded relationships, and open one entity-level knowledge card.

GET/v1/taxonomy

Canonical concepts, units, definitions, and surface-name synonyms.

Demo live
GET/v1/taxonomy/graph

Codes-only nodes and typed edges with provenance counts.

Demo live
GET/v1/graph/query

A bounded breadth-first traversal from one or more canonical roots.

Demo live
GET/v1/entities/{id}/dossier

A kind-aware knowledge card for any canonical graph node.

Demo live
GET/v1/goals/{code}/dossier

A convenience alias for the universal entity dossier.

Demo live

Evidence & trust

Inspect evidence rows, the grading method, signed promotion authority, replay state, and deployment trust.

GET/v1/methodology

Certainty ladder, study ceilings, adjustment rules, gates, and census.

Demo live
GET/v1/evidence/{family}

Paged, allow-listed evidence rows with a provenance label on every row.

Provenance labeled
GET/v1/evidence/{family}/{row_id}

A single allow-listed row and its verifier-derived provenance state.

Provenance labeled
GET/v1/evidence/dossier/{claim_id}

One synthesis, its worksheet, effects, and sources in a single chain.

Provenance labeled
GET/v1/evidence/{family}/{row_id}/receipt

Signer identity, hashes, signature presence, and re-verification result.

Authority gated
GET/v1/grade/{claim_id}/replay

Re-run the GRADE arithmetic and compare stored with replayed output.

Authority gated
GET/v1/trust

The serving corpus, signer set, effective trust identity, and receipt counts.

Demo live

Screening

The only partner-callable write: structured context in, deterministic proof-carrying screen out.

POST/v1/screen

Structured profile, goals, and candidates in; proofs, gaps, and a receipt out.

Demo live

Operator ingestion, document normalization, and review writes sit outside this partner contract by design.

The honest boundary

Focused enough to demonstrate. Not presented as general availability.

The partner surface is useful today in curated scenarios. Corpus coverage and governed evidence promotion are still expanding, and the API exposes that state rather than masking it.

✓

Ready to demonstrate

Stable strengths in a focused pilot

  • Self-describing partner contract and closed vocabularies
  • Versioned taxonomy, graph traversal, and entity dossiers
  • Deterministic, proof-carrying candidate screening
  • Explicit gaps, provenance labels, and trust posture
  • Strict separation between partner and operator capabilities
↻

Still being governed

Coverage and authority are expanding

  • Broader nutrient and use-case coverage across the corpus
  • Human methodology review for new evidence packages
  • Expansion beyond the first three signed, verified evidence chains
  • Grade replay remains gated to rows whose promotion authority verifies
  • Wider rollout after scenario-level integration evidence
01Reviewed corpusBroad, labeled, still incomplete
02Human methodology sign-offScenario and evidence specific
03Signed promotionThree integration chains complete
04API verificationReplayable in the live demo release; general availability unclaimed

A useful next step

Bring one real workflow.

We will map your inputs to the partner vocabulary, choose the smallest relevant endpoint chain, and define the evidence and safety boundary before a pilot begins.

Review the three scenarios Open the complete API docs

Pilot input

  1. 01Your product workflow
  2. 02One representative payload
  3. 03The decision your team needs to support