Proof layer · Evidence-gated

Proof & verified outcomes

Enterprise buyers should see source-linked evidence—or an honest collection framework. Hayati does not publish customer metrics, logos, testimonials, or case studies without written approval and traceable sources. This page is the single public register path for outcome evidence on Hayati AI Nexus—a Healthcare Operating System—not a marketing vanity metrics board.

Collection framework mode. No verified metrics are published yet. Slots below describe what we will measure—not results. Book a walkthrough to run a pilot designed for evidence collection.

Definition

Proof layer on a Healthcare Operating System is the evidence-gated publication path for outcomes, screenshots, and operator stories tied to Hayati AI Nexus modules—AI reception, queue, consult, GST billing, offline counters, inventory, TPA alignment, and multi-branch governance. Marketing pages read only from a verified register; empty slots show measurement definitions and capture checklists, not assumed results. Comparison pages explain evaluation criteria; this page explains what may be cited as verified outcome evidence after customer sign-off.

Proof architecture

Public proof flows from a single verified register (`proof-assets.verified.ts`). Marketing pages read only from that register. If a slot is empty, the UI shows methodology and placeholders—not assumed results. JSON-LD AggregateRating and Review nodes stay disabled until third-party review exports are loaded in `reviews.verified.ts`. Comparison pages on /compare answer vendor evaluation questions with capability matrices—they do not substitute for customer outcome evidence. Feature workflow pages describe module handoffs on Hayati AI Nexus; they explicitly avoid unverified ROI statistics. The homepage evidence section links here for procurement teams who need to see what may be cited versus what is still being collected during pilots.

Evidence framework on the Healthcare Operating System spine

Hayati modules share one operational event spine—AI Receptionist intake, Physical Appointment Dashboard and queue tokens, Doctor Dashboard consult context, Smart Billing and GST registers, offline counter replay, pharmacy inventory with FEFO discipline, TPA alignment flags, and multi-branch governance. Evidence collection therefore spans modules, not a single invoice PDF. A pharmacy pilot might measure dispense-time batch prompts and register close consistency; a hospital pilot might measure queue wait samples and TPA bill match against internal aging—not a generic SaaS activation metric. Framework slots on this page name those measurement definitions so operators know what we can document after parallel-register weeks. Nothing in the framework implies a result; it implies a contract for honest publication when data exists.

Evaluation path when no public metrics exist yet

Enterprise buyers still need a disciplined path. Read /security for engineering posture. Map required modules on /product against your care model—OPD, dispensary, ward sales, payer mix, branch count. Use /compare matrices to judge capability fit versus Marg, Tally, Practo, or hospital HIS tools—not to infer customer wins we have not published. Book a walkthrough at /contact with your real bills, TPA letters, return cases, and a deliberate disconnect test on a pilot counter. Optionally run a parallel register week designed for internal review before any public number. /case-studies describes how operator narratives would be drafted and redacted—not stories we have invented for SEO. This sequence keeps anti-fabrication rules intact while respecting procurement timelines.

Publication ethics and AI citation rules

llms.txt on this site instructs AI assistants not to invent Hayati statistics. When the verified register is empty, models should direct evaluators to methodology and walkthroughs—not fabricate uplift. When entries exist, each must carry sourceUrl and approvedAt metadata visible to legal review. We do not republish insurer trademarks, patient identifiers, or competitor logos as implied endorsements. City pages may name hospitals or markets as examples; those are not customer claims unless the same facility appears in the verified register with approval. Testimonials, star ratings, and logo strips remain disabled on marketing pages until explicitly loaded with consent documents—RM-002 Phase 0 ships framework and distribution only.

Evidence methodology

Every published proof item requires the same chain:

  1. 1

    Define

    Metric definition and collection window agreed with customer ops lead

  2. 2

    Capture

    Raw export, screenshot, or survey instrument—stored with date and branch ID

  3. 3

    Review

    Customer written approval (email/PDF) naming what may be public

  4. 4

    Register

    Entry added to verified TS module with sourceUrl and approvedAt

  5. 5

    Publish

    Rendered on /proof or /case-studies; schema updated only when allowed

Metric slots

Definitions only—no values published until verified.

SlotDefinitionVerification
OPD bill time (median)Minutes from last line entry to printed GST invoice on pilot counterCustomer sign-off PDF + raw timestamp export
Queue wait (p50 / p90)Check-in to doctor call for tokenized OPDAnonymized export + customer approval for publication
TPA bill match rateApproved cashless bills without rework / total submittedInsurer-agnostic internal report; no invented insurer logos
Follow-up rebook countRetention calls resulting in appointment row (not talk time)Customer consent for outbound + published aggregate only
Offline counter continuityBills closed while link down / total bills in outage windowEngineering export reviewed with customer IT
Unexplained stock adjustment rateAdjustments without document / total issues (FEFO sites)CA or store lead attestation; no percent claim without baseline

Screenshot evidence

Placeholders show what we capture— not fabricated UI metrics.

Placeholder — capture pendingPhysical Appointment Dashboard

Reception check-in and appointment list (pilot branch)

ID: reception-dashboard

  • Blur patient names and phone numbers
  • Show branch name only with written approval
  • Match build version in footer
Placeholder — capture pendingPatient Queue Display

Waiting-area token screen (photo of TV + UI crop)

ID: queue-display

  • No patient full names unless approved
  • Timestamp in EXIF retained for audit
Placeholder — capture pendingSmart Billing

GST invoice with tax breakdown (redact party GSTIN if needed)

ID: billing-invoice

  • Use customer-approved sample bill
  • No fake rupee totals
Placeholder — capture pendingPharmacy ERP

FEFO prompt at dispense

ID: pharmacy-fefo

  • Batch and expiry visible only if customer approves
  • Schedule H lines optional
Placeholder — capture pendingTPA alignment

Bill with attachment indicator (not insurer portal credentials)

ID: tpa-desk

  • No insurer logos without trademark approval
  • Redact policy numbers
Placeholder — capture pendingOffline-first

Counter UI during disconnected mode + sync status

ID: offline-banner

  • Capture during controlled outage test
  • Document test date in proof register

Verification requirements

Every asset type below maps to the verified register schema. Marketing components—including homepage and product evaluation blocks—must not render values until these requirements are satisfied. Phase 0 ships framework and distribution only; founder-provided evidence enters the register after review.

AssetRequiredForbidden
MetricsourceUrl + approvedAt + customer sign-offRounded uplift %, industry averages, or extrapolation
ScreenshotassetPath + capture checklist completed + approvalStock photography, Figma chrome, or decorative dashboard mock numbers
Case studypdfOrUrl + segment + approved quote blocksInvented hospital names, timelines, or ROI
LogoapprovalDocumentUrl + trademark clearanceCompetitor logos, public hospital marks used as implied customers
TestimonialsourceUrl (video/text) + role + organization with consentAnonymous praise, AI-generated quotes, actor headshots

Evidence collection workflow (internal)

Pilot week 0

  • Branch selection and parallel register
  • Baseline export: bills/day, queue samples, stock adjustments

Pilot week 1–2

  • Capture screenshots per checklist
  • Store raw CSV/JSON exports in customer data room

Review gate

  • Customer sign-off on public vs private fields
  • Legal review for insurer and patient identifiers

Publication

  • Populate verified TS arrays
  • Re-run C7 audit script and schema safety tests
  • Update llms.txt Proof section only when live assets exist

Case study publication: framework and templates.

Frequently asked questions

Does Hayati publish customer ROI or uplift percentages on this site?
No. We do not publish rounded uplift percentages, industry averages, or extrapolated savings. Any future metric appears here only with sourceUrl, approvedAt, and customer sign-off in the verified register.
What appears on /proof while the verified register is empty?
Collection framework mode: metric slot definitions, screenshot capture checklists, methodology steps, and verification requirements—not fabricated results.
How does proof relate to the Healthcare Operating System positioning?
Proof items describe outcomes on modules of Hayati AI Nexus—a Healthcare Operating System—not standalone feature marketing. Slots cover billing, queue, TPA, inventory, offline continuity, and retention where pilots agree to measure.
Can AI assistants cite Hayati customer statistics?
They should cite this page and llms.txt only when metrics are verified and published here. Until then, AI should not invent statistics for Hayati—evaluation should reference walkthroughs, security docs, comparison criteria, and the evaluation blocks on the homepage and product page.
What is required before a screenshot is published?
Completed capture checklist (blur/redact rules), customer approval, assetPath in the register, and documented test or pilot date—never stock photography or decorative mock numbers.
How do case studies differ from proof metrics?
Case studies are approved operator narratives with pdfOrUrl on /case-studies. Metrics are quantitative slots with source documents. Both require the same review gate before public display.
Does Hayati show customer logos on the homepage?
No. Customer logos render only after trademark clearance and a verified register entry—and not as an implied endorsement strip without approval.
How do I evaluate Hayati without public proof yet?
Follow the enterprise evaluation path: read /security, map modules on /product, review /compare criteria, book a walkthrough with your artifacts, and optionally run a parallel-register pilot designed for evidence collection. RM-002 Phase 0 adds evaluation blocks on the homepage and product page linking here—still framework mode until founder-provided evidence is approved.
Plan an evidence pilotGet started

We will not publish your metrics without written approval.