Skip to main content

​
What Health Clinic Layer 1 is

Health Clinic Layer 1 is where you check whether an entity’s foundation is healthy enough to earn a final trust score. It shows two things on one page: a readiness board that summarizes what is already known about the entity, and a Daily Core scan you can run once a day to refresh that picture.View in app: open veracity.super-intelligent.ai/entities, pick the entity, and open Health Clinic from the Command Center — Layer 1 is the top of that page. Opens per entity, sign-in required.Layer 1 is about foundation and final trust score readiness. Supporting provider signals live in Layer 2 and are shown separately.

​
What you can do here

  • Read the readiness summary. The top of the board gives you four counts at a glance: total readiness rows, how many are ready for review, how many have a follow-up to work, and how many are blocked or in conflict. A “Read-only synthesis” tag is always visible so you know nothing on the page runs by looking at it.
  • Expand technical details when you need proof. Details are collapsed by default. When you need source-by-source proof, ownership, or timestamps for a specific row, use Show technical details. Expanding never runs anything.
  • Run the Daily Core scan. Once per day per entity, you can run a fresh scan. When it finishes you see the scanned time, the pass / warning / critical / skipped counts, and a Final trust score readiness receipt telling you whether the snapshot was stored.
  • Come back later and still see the proof. If a scan has already run today, reloading the page keeps showing the same scan result and receipt. You do not have to re-run it to see what happened.

​
Why the Layer 1 page behaves the way it does

  • Read-only synthesis is a deliberate promise. Nothing on Layer 1 changes state by being looked at. The board summarizes what’s already known — it doesn’t fetch fresh data, ping the entity, or record that you viewed it. The “Read-only synthesis” tag exists so you can send this page to a client or teammate without worrying that a stray click ran something. The only action that does run work is the Daily Core scan button, and it’s explicit about it.
  • Collapsed by default, expandable on demand. Most of the time, four counts (total, ready-for-review, follow-up, blocked/conflict) tell you everything you need to triage. The per-row technical details underneath are there for the moments when a client asks “why is this in follow-up?” or an auditor needs a timestamp — so they load only when you ask. This keeps the top of the page scannable and the technical proof one click away, without making you choose between the two.
  • Four counts, chosen on purpose. Total tells you scale. Ready for review tells you where a human decision is queued. Follow-up tells you where work is currently open. Blocked/conflict tells you where the page is stuck and can’t proceed without an upstream fix. These four together cover the whole state space at a glance — anything not in one of the last three buckets is already fine.
  • The Daily Core scan runs once a day, per entity, on purpose. A single fresh scan is enough to refresh the readiness picture; running it repeatedly the same day wouldn’t change the answer and would burn quota. The button is quota-bounded so you can’t accidentally exhaust it, and if a scan has already run today, the page shows you that scan’s result instead of asking you to run again.
  • Receipts, not activations. When the Daily Core scan finishes, you get a receipt that tells you whether the final trust score snapshot was stored. A stored snapshot is proof that the run happened and its result was persisted — it is not the same thing as activating a final trust score. Activation is a separate decision, not a side effect of storing.
  • Reload-proof by design. If you close the page and come back — or if someone else on the team opens the same entity later that day — the linked scan result and its receipt still show. That’s because the page looks first for the in-memory result of a scan you just ran, and if that’s absent, it looks for a stored same-day scan and renders that instead. You never end up staring at a “run it again” empty state when a valid scan already exists.
  • Provider signals sit in Layer 2, not here. Layer 1 is the foundation-and-readiness view; anything about supporting provider signals is intentionally separated so this page stays focused on the go/no-go picture. When Layer 2 is ready, it will appear as its own surface — Layer 1 will not sprout provider detail underneath.

​
What it does not do

  • It does not verify the entity or mark it approved.
  • It does not activate a final trust score on its own — the receipt only tells you the snapshot was stored.
  • It does not run supporting provider signals or change anything downstream.
  • Expanding technical details, reloading the page, and viewing the board never trigger work.
Status: In-flight · Layer: 1 (foundation health and final trust score readiness)