The local sample is synthetic
The walkthrough uses made-up member data. It is product evidence, not a customer result or clinical validation.
Trust / Evidence before assertion
Trust is a boundary you can inspect.
Knownset separates calculated facts, model interpretation, and customer-approved action. This page says what the current synthetic sample demonstrates—and what it does not.
DEMONSTRATEDVISIBLE IN THE CURRENT SYNTHETIC SAMPLETARGET BOUNDARYREQUIRES DEPLOYMENT-SPECIFIC VERIFICATIONNOT CLAIMEDEVIDENCE IS NOT PRESENT OR APPROVED
01 / Demonstrated
What the current sample can prove.
These are deliberately narrow claims. Each one can be inspected without relying on a customer logo, certification badge, or outcome statistic.
Four sample tools are read only
They can report capabilities, a daily summary, current insight cards, and the sources already attached to an insight.
Facts and interpretation are separated
The sample keeps calculated values in deterministic code and presents interpretation as a distinct, bounded layer.
Actions stop for confirmation
The product pattern prepares a proposed change for review. It does not present a model suggestion as an already-applied action.
02 / Target operating boundary
Four owners. No invisible handoff.
The deployment target assigns responsibility at each transition. A buyer must still verify that the implemented deployment matches this boundary.
- 01Approved source context
Consent, provenance, and freshness travel with the data made available to the product.
- 02Deterministic fact
Code owns calculated values, normalization, and known limitations.
- 03Bounded interpretation
A model can explain supplied context inside an approved purpose; it does not become the source of record.
- 04Customer-confirmed action
The customer owns programming and the member-facing review before a meaningful change is applied.
03 / Not claimed
Absence of evidence is not a trust badge.
These statements are intentionally excluded from Knownset's public case until current, scoped evidence is available and approved.
- No claim of SOC 2 certification, HIPAA compliance, or clinical validation.
- No claim of a public hosted API, general production availability, or broad provider coverage.
- No claim of customers, revenue, retention, health outcomes, or operating-cost savings.
- No claim that a synthetic walkthrough proves a customer's deployment posture.
04 / Buyer diligence
Questions the architecture should answer.
Use these as the start of a technical review, not as a substitute for deployment-specific evidence.
Whose data can a request read?
The target boundary derives organization and person context from the signed-in server session rather than accepting identity from model-authored arguments.
What owns a calculated health fact?
Deterministic code owns calculations and normalization. A model may explain a supplied fact, but should not silently recompute or replace it.
Can a suggestion change a member record?
The operating pattern separates a proposal from a confirmed write. The customer keeps the program and the member-facing confirmation workflow.
What should a buyer verify before production?
Connector status, data rights, retention, subprocessors, incident response, regional needs, rollback, support, and the exact controls in the buyer's deployment.
Continue the review
Inspect the exact sample boundary.
The developer page shows the implemented local tools, access boundary, evidence trace, and current availability.
Open developer evidence