# Lab

## Part 1 — Purpose, Scope, and Operating Thesis

### 1. Purpose and Public-Good Function

1.1 The Future of Health Lab (“FoH Lab”) is a governed, AI-assisted, community-operated **standards, frameworks, and intelligence commons** whose purpose is to convert multi-stakeholder contributions into **structured, versioned, reusable objects** for the future of health under deterministic lifecycle rules, explicit reliance bounds, and correctionability.

1.2 The FoH Lab exists to reduce variance in **patient safety, clinical quality, public health readiness, data integrity, model integrity, and system resilience** by making health-relevant claims **machine-checkable where feasible**, audit-ready by design, and transparently correctable—without collapsing sovereignty, privacy, consent, due process, professional independence, scientific freedom, source protection, or regulated perimeters.

1.3 The operating thesis is continuous health intelligence with bounded reliance: health systems become safer and more resilient when clinical, epidemiological, operational, and AI-related claims are **evidence-bound, comparable, and correctionable**, while preserving lawful practice boundaries, patient protections, and the primacy of licensed clinical judgment.

1.4 The FoH Lab standardizes **how evidence is packaged, how claims are expressed, how conformance is tested, and how corrections propagate** across health stakeholders, enabling diligence compression and faster readiness cycles **without becoming** a provider, a payer, a regulator, a public health authority, or a clinical decision engine.

1.5 FoH Lab outputs are governance artifacts and evidence objects; they are **not medical advice**, not diagnosis, not prescribing guidance, not triage authority, not coverage/adjudication decisioning, not enforcement, and not a substitute for licensed professional judgment.

1.6 “Do-no-harm,” minimum necessary disclosure, handling-first design, and misuse prevention are overriding constraints; where publication could plausibly increase harm capability, staged release, handling elevation, or refusal/redirection is mandatory.

1.7 The FoH Lab is vendor-neutral and technology-neutral: it specifies governance invariants and testability; implementations may vary provided conformance claims are scoped, reproducible, time-bounded, and non-endorsing.

### 2. Full Scope of “Future of Health”

2.1 “Future of health” includes, without limitation, governed objects covering:\
2.1.1 **Clinical care delivery** (quality and safety governance; care pathways as documented objects; adverse event governance; continuity-of-care evidence patterns; escalation and handoff integrity).\
2.1.2 **Public health intelligence** (early warning governance; uncertainty discipline; reporting comparability; surveillance evidence packaging at lawful granularity).\
2.1.3 **Health security and preparedness** (pandemics; defensive biosecurity readiness; surge capacity evidence; continuity and scarcity protocols as governance objects; emergency mode clocks).\
2.1.4 **Pharmaceuticals and therapeutics** (pharmacovigilance governance; safety-signal packaging; quality and recall evidence patterns; anti-counterfeit supply chain integrity objects).\
2.1.5 **Medical devices and diagnostics** (validation patterns; post-market surveillance evidence; performance drift governance; clinical labeling and limitation cues).\
2.1.6 **Laboratories and testing systems** (sample chain-of-custody; QC comparability; assay drift evidence; inter-lab conformance objects).\
2.1.7 **Health data governance** (consent, purpose limitation, provenance, lineage, de-identification posture, re-identification risk controls, access governance, retention minimization).\
2.1.8 **Health AI and digital health** (model/tool provenance; lifecycle controls; bias and drift governance; human override evidence; deployment kill-switch and incident clocks; audit evidence packaging).\
2.1.9 **Hospital and health operations** (capacity, staffing, critical supplies, incident command evidence patterns; cyber and outage readiness; clinical continuity under disruption).\
2.1.10 **Mental health systems** (privacy-preserving measurement; safety governance; stigma-aware disclosure minima; crisis-safety guardrails).\
2.1.11 **Health equity and access** (comparability of metrics; barrier evidence; do-no-harm constraints; rights-preserving segmentation limits; accountability clocks).\
2.1.12 **Payer/insurance interfaces** (claims integrity patterns; coverage decision transparency frameworks; appeal clock objects—strictly non-executing).\
2.1.13 **Biomedical research integrity** (reproducibility objects; dataset lineage; preregistration/reporting comparability; publication correctionability; COI handling).\
2.1.14 **Environmental and climate-health interfaces** (heat, air quality, vector dynamics; uncertainty discipline; service disruption impacts; interdependency evidence).\
2.1.15 **Cyber and identity risk in health** (EHR integrity; ransomware resilience evidence; credential abuse defense; access recertification patterns).\
2.1.16 **Community health and communications integrity** (risk communication governance; misinformation/synthetic media defensive controls; trust and legitimacy objects; non-coercive transparency).\
2.1.17 **Cross-border interoperability** (records portability patterns; translation/equivalence objects; corridor overlays; lawful sharing constraints).\
2.1.18 **Supply chain and industrial capacity** (active ingredients, consumables, PPE, cold chain, critical devices; concentration risk; substitution risk; continuity evidence).\
2.1.19 **Emerging tech risk** (agentic AI in care settings governance; synthetic biology defensive governance; post-quantum readiness posture; integrity of clinical copilots).

2.2 The scope includes health-relevant system-of-systems dependencies treated as health system risks requiring governed evidence and correctionable decision influence: critical infrastructure, water systems, pharma logistics, cloud/software supply chain, workforce availability, misinformation dynamics affecting care-seeking, and geopolitical disruptions affecting supply and staffing.

2.3 The scope explicitly separates (a) public claims, (b) operational constraints, and (c) regulated determinations; the FoH Lab operates only in (a) and governed representations of (b), and never performs (c).

2.4 Patient-identifying data is treated as a high-risk class by default; the Lab’s default posture is minimization, compute-to-data, and handling segregation.

### 3. Intended Users and Outcomes

3.1 The FoH Lab serves health system boards, CMOs/CNOs/CIOs, clinical governance committees, public health agencies, laboratories, manufacturers, regulators within mandate, payers within lawful scope, auditors/assurers, researchers, and builders by producing objects that are:\
3.1.1 Portable (profiles + deltas, not forks).\
3.1.2 Testable where claims are asserted (conformance suites).\
3.1.3 Correctionable (no silent edits; explicit supersession).\
3.1.4 Clinician- and examiner-operable (truth surface: current, superseded, contested, tested, admissible).\
3.1.5 Handling-aware (safe distribution at elected class; leakage tested).\
3.1.6 Reliance-bounded (who may rely, under what limits, for what duration).

3.2 Outcomes include improved safety governance, faster readiness cycles, reduced adverse variance, better comparability of evidence and models, stronger patient protections under modern AI and supply chain realities, reduced integrity risk from drift and misrepresentation, and reduced audit friction without centralizing control.

3.3 Outcomes expressly exclude substitution for clinical judgment, clinical governance authority, public health authority, payer adjudication authority, or regulatory authority.

### 4. Output Classes

4.1 Outputs include standards; frameworks; profiles/implementation guides; taxonomies/ontologies; defensive typology libraries; artifacts and method cards; conformance suites; conformance reports; release bundles; corrections/supersessions; interoperability mappings; learning modules; **Assurance & Evidence Packs (AEP-HEALTH)**; indices/metric definitions; and Future of Health Reports.

4.2 Outputs are objects with lifecycle state and registry pointers; documents are views.

4.3 Outputs that could be misconstrued as clinical directives must carry prominent reliance bounds, “non-clinical / non-prescriptive” labeling, limitations, uncertainty cues, review/expiry, and correction/dispute clocks.

***

## Part 2 — Boundary, Non-Executing Perimeter, and Firewall Doctrine

### 1. Boundary of the Lab

1.1 The FoH Lab provides governance infrastructure for identity/participation; records-first workflows; canonical registers and truth surfaces; handling-separated indexing and retrieval; publication/versioning/correction discipline; conformance and reproducibility operations; report desks and subscription channels; cloneable instance kits; and federation-safe interoperability scaffolding.

1.2 The boundary includes standards operations (object model, conformance, release discipline), intelligence operations (reports, evidence packs, correction clocks), and interoperability operations (mappings, plugfests) as governance infrastructure, not clinical practice, operations command, payer execution, or regulatory decisioning.

1.3 The boundary includes “truth surface operations”: making current/superseded/contested/tested/handling status reviewable from records, not narratives.

### 2. Two-Stack Firewall Alignment

2.1 The FoH Lab operates exclusively as public-good governance infrastructure: standards/schemas, evidence integrity, validity-by-record, handling and safeguards, conformance, release and correction discipline, and audit structures.

2.2 Execution occurs only outside the Lab in lawful institutional processes and licensed delivery stacks (clinics/hospitals, laboratories, pharmacies, manufacturers, public health agencies, insurers, regulators within mandate).

2.3 Integrations are limited to interoperability mappings, compatibility notes, conformance-tested connectors, and evidence packaging patterns; they do not widen the Lab into a provider, payer, regulator, surveillance authority, or clinical decision engine.

2.4 Separation-of-duties applies: no role marker may simultaneously author a high-reliance conformance determination and execute patient-impacting operational decisioning for the same object family.

### 3. Non-Executing Perimeter

3.1 The FoH Lab does not provide medical diagnosis, treatment recommendations, triage decisions, prescribing guidance, or patient-specific care instructions.

3.2 The FoH Lab does not operate quarantine orders, eligibility determinations, benefits coverage decisions, claims adjudication, enforcement decisioning, or supervisory decisioning.

3.3 The FoH Lab does not publish actionable biosecurity misuse instructions, pathogen optimization techniques, weaponization guidance, or evasion recipes; security-relevant content is defensive, handling-aware, and purpose-bound.

3.4 The FoH Lab does not publish re-identification techniques, doxxing methods, model inversion recipes, or patient linkage procedures.

3.5 All outputs are informational artifacts and must include intended use, prohibited use, limitations and uncertainty cues, expiry/review dates, and correction/dispute paths with clocks.

### 4. Refusal and Redirection Discipline

4.1 Requests that increase harm risk (biosecurity misuse, self-harm enablement, re-identification, discriminatory exclusion playbooks, unsafe clinical directives, fraud facilitation) are refused or redirected into defensive, governance-grade outputs (controls, safe validation suites, governance checklists, incident clocks).

4.2 Sensitive legitimate contexts (clinical validation drills, regulator testability, controlled research) follow staged release: public-safe abstract first; controlled/restricted derivatives gated, purpose-bound, expiry-bound, and logged.

4.3 Redirection outputs must not materially increase offensive capability and must preserve patient protection and lawful confidentiality.

***

## Part 3 — Validity-by-Record, Registers, and Dual-Logging for Designated Acts

### 1. Validity-by-Record

1.1 Standing arises only from record-valid acts executed through FoHLP workflows and reflected in canonical registers and current pointers.

1.2 Informal statements, emails, screenshots, or drafts have no standing unless represented as record-valid objects with required metadata, handling election, provenance/rights attestations, and registry pointers.

1.3 The truth surface must be auditor- and clinician-operable: decision influence is reconstructable from records, not narratives.

1.4 Authority scoping and reliance scoping are mandatory: objects must specify who may assert, who may rely, under what limits, and for what period.

### 2. Canonical Registers and Truth Surface

2.1 Each FoH Instance maintains canonical registers for: object identity and lifecycle state; current pointer and supersession chain; conformance suite and report registry; handling elections and distribution logs; COI disclosures and sanctions/appeals; report edition registry with dependency banners; integrity incidents and stop-the-line actions; emergency declarations and expiry records.

2.2 Registers must expose, at minimum, a public-safe status surface: Current / Superseded / Withdrawn / Contested / Expired, plus conformance posture and handling class.

### 3. Dual-Logging for Designated Acts

3.1 For designated acts requiring cross-institution force-and-effect, validity is anchored by dual records: GRF Council Register record and NSF protocol anchoring.

3.2 Minimum designated acts include: recognition as current; release publication and pointer movement; conformance claims/reports; issuance of AEP-HEALTH intended for external reliance (audit, procurement, regulated submissions, assurance programs); sanctions/revocations/reinstatements; withdrawals/emergency reliance constraints.

3.3 Mismatch lock applies: disagreement between register and anchor renders the act Inoperative (Mismatch) until reconciled; dependent objects must display warnings.

### 4. Local-Only Standing

4.1 Deployments without dual anchoring must label designated acts Local-Only Standing and may not claim cross-node standing.

***

## Part 4 — Canonical Object Model for Health Standards and Intelligence

### 1. Objects, Not Documents

1.1 Authority attaches only to a versioned object with record-valid lifecycle state and a registry pointer; pages are views.

1.2 Releases and report editions are immutable; updates occur only through corrections/supersessions with diffs and migration notes.

1.3 Dependency graphs must be reconstructable and publishable at appropriate handling, enabling contestation and supersession propagation.

### 2. Canonical Object Types

2.1 STD-FoH Standards (normative invariants: safety, privacy, consent, provenance, handling, disclosure minima, correction discipline).\
2.2 FRM-FoH Frameworks (governance/control frameworks; bounded reliance).\
2.3 PRF/IG-FoH Profiles / Implementation Guides (jurisdiction/provider overlays; explicit deltas; no forks).\
2.4 TAX/ONT-FoH Taxonomies / Ontologies (conditions, interventions, safety events, operational states, threats; drift-tested).\
2.5 TYP-FoH Typology Libraries (defensive: adverse event typologies, fraud typologies, outbreak pattern typologies at safe granularity).\
2.6 ART-FoH Artifacts (method cards, checklists, clinical model cards, dataset cards, validation rubrics, assurance-case cards).\
2.7 AEP-HEALTH Assurance & Evidence Packs (sealed determination artifacts: validation, safety, performance, uncertainty, correction clocks; bounded reliance).\
2.8 CS-FoH / CR-FoH Conformance Suites / Conformance Reports (tests, vectors, harness notes; signed results; validity window).\
2.9 REL-FoH / COR-FoH Release Bundles / Corrections-Supersessions.\
2.10 RPT-FoH / SUB-FoH Reports / Subscription Channels (edition immutability; handling-aware distribution).\
2.11 MAP/IOP-FoH Mappings & Interoperability Profiles (equivalence limits; warnings; testable transformations).\
2.12 WGC-FoH / RM-FoH / DR-FoH / CFW-FoH Working Group Charters / Role Markers / Decision Records / Calls for Work.\
2.13 CONSENT-FoH / TRANSP-FoH Consent and Transparency Elections (patient consent patterns; purpose limitation; supervisory confidentiality posture).\
2.14 IDX-FoH Index and Metric Definitions (safety indices, readiness indices, quality indices, equity indices; assumptions and limits).\
2.15 SAFE-FoH Safety Posture Objects (non-prescriptive safety assertions; inspection/validation evidence patterns; hazard cue libraries).

### 3. Mandatory Metadata and Release Blockers

3.1 Publishable objects require: scope/exclusions; handling election; reliance bounds; expiry/review; correction/dispute path + clocks; provenance + rights attestations; COI link; dependencies/compatibility; jurisdiction label; safety and do-no-harm statement; misuse risk statement; and non-clinical-use labeling where applicable.

3.2 Missing mandatory metadata blocks publication.

3.3 Prohibited uses must be explicit where misuse risk exists (patient-specific clinical use, biosecurity misuse, re-identification, discriminatory targeting, coercive surveillance).

3.4 High-risk objects require additional gating: independent review, leakage testing, and restricted distribution logs.

***

## Part 5 — Records-First Governance, Roles, and Due Process

### 1. Record-Valid Acts

1.1 All lifecycle and governance actions occur only through record-valid acts (onboarding, COI, handling, WG chartering, releases, conformance, corrections, disputes, waivers, sanctions).

1.2 Assistive AI may draft and structure; standing is conferred only by human-authorized recorded submission under valid role markers.

1.3 High-reliance objects require multi-role review (records, handling, conformance, and where relevant licensed clinical safety review) prior to publication.

1.4 Waivers record scope, duration, compensating controls, and remediation clocks; waivers auto-expire unless renewed.

### 2. Minimum State Machines

2.1 Standards/Frameworks/Taxonomies: draft → review → candidate → accepted → published → maintained → superseded/withdrawn.\
2.2 AEP-HEALTH: drafted → verified → issued → monitored → corrected/superseded → archived/expired.\
2.3 Releases/Reports: assembled → gated → reviewed → approved → published → monitored → corrected/superseded → archived/expired.\
2.4 Conformance: submitted → triaged → verified → accepted/rejected → registered → referenced → archived/expired.\
2.5 Disputes/appeals: filed → triaged → responded → resolved → remedied → closed; contestation propagates.

### 3. Due Process and Clocks

3.1 Decisions require Decision Records with rationale, scope, limitations, and remedies.

3.2 Integrity incidents may trigger stop-the-line: publication freeze, access revocation, recall attempts where feasible, and mandatory public-safe change abstracts.

3.3 Clocks apply to dispute triage, response windows, emergency notices and expiry, conformance expiry, correction publication windows, and post-incident review publication.

### 4. Minimum Governance Spine

4.1 Records & Register Officer; Handling & Safety Officer; COI & Ethics Officer; Conformance Lead; Editorial Lead; Dispute Resolution Panel.

4.2 Health-specific minimum roles for high-reliance work include: Clinical Safety Steward (licensed clinical reviewer), Privacy & Consent Steward, Security & Handling Steward, and Public Health Steward (as applicable).

4.3 Separation-of-duties: no single role may originate, independently verify, and publish the same high-reliance claim without independent review.

***

## Part 6 — Handling, Safety, Staged Release, and Patient Harm Prevention

### 1. Handling Classes

1.1 Public-Safe / Controlled / Restricted handling with access gates, distribution logs, staged release rules, expiry enforcement, and leakage testing.

1.2 Handling inheritance applies to bundles and derivatives; down-classification requires recorded decision and safety review.

1.3 Restricted handling is deny-by-default and must be purpose-bound, time-boxed, and auditable.

### 2. Health Misuse and Harm Taxonomy

2.1 High-risk misuse includes: patient re-identification and linkage; discriminatory exclusion playbooks; unsafe clinical advice; biosecurity misuse; fraud facilitation; coercive surveillance; model inversion/attribute inference; leakage of sensitive operational vulnerabilities; and manipulation of public health signals.

2.2 Assistants are prohibited from reconstructing restricted content or generating instructions that materially increase harm capability.

2.3 Dual-use content must be handling-elevated, rewritten into defensive controls, or withheld with a public-safe extract where feasible.

### 3. Staged Release and Public-Good Extracts

3.1 Controlled/Restricted work must yield public-safe extracts where feasible: safety controls, validation patterns, uncertainty and limitation cues, and governance checklists.

3.2 Infeasibility is recorded with rationale and review date.

### 4. Leakage Testing

4.1 Leakage testing is continuous and event-triggered (model/provider change, index rebuild, connector change); failures trigger stop-the-line.

4.2 Minimum adversarial suite includes boundary probing, prompt injection, indirect reconstruction, and handling segregation regression checks.

***

## Part 7 — Conformance, Reproducibility, Plugfests, and Drift Governance

### 1. Conformance Discipline

1.1 High-impact safety, performance, privacy, or consent claims require conformance suites and signed conformance reports; conformance is bounded and non-endorsing.

1.2 Releases claiming interoperability, validation, or safety behavior are gated unless backed by conformance evidence or time-boxed plans with interim reliance limits.

1.3 Conformance reports must declare scope, environments, exclusions, and validity windows; failures must publish at least a public-safe summary and remediation clocks.

### 2. Replication Cells

2.1 Replication reruns suites across sites/configurations; independent verification required for high-reliance claims; failures trigger notices, freezes, withdrawals, and remediation clocks.

### 3. Plugfests

3.1 Plugfests validate interoperability across health data schemas, consent signals, evidence packs, model card formats, audit logs, and safe transformation mappings with explicit equivalence limits.

### 4. Drift Testing

4.1 Drift governance covers ontology drift, mapping equivalence drift, assistant refusal/safety drift, and AI lifecycle drift (data drift, performance drift, policy drift).

4.2 Material drift triggers reliance tightening and status changes on the truth surface with propagation to dependent objects.

***

## Part 8 — Identity, Participation, Guild System, Credits, and KPIs

### 1. Participation Identity and Authority

1.1 “FoH Passport” captures expertise, jurisdictions, roles (clinical governance, public health, lab/diagnostics, security, privacy, ethics), and COI; authority arises only from role markers.

1.2 Capability progression records verified contributions, replication history, conformance participation, and integrity compliance.

### 2. Authentication and Authorization

1.3 SSO/MFA with step-up for controlled/restricted actions; RBAC+ABAC using role marker, handling class, purpose, timebox, and device posture; restricted is deny-by-default.

### 3. Guild System and Work Units

1.4 Guilds, Working Groups, Review Pools, Replication Cells, Clinics/Sessions (safety, privacy, AI assurance, public health reporting), and Publisher Rooms.

### 4. Credits, Anti-Gaming, and KPIs

1.5 Credits accrue only on accepted record-valid outcomes; spending does not buy influence or standing.

1.6 Verification/replication credits outrank drafting; reviewer rotation prevents concentrated influence; clawbacks apply for misconduct.

1.7 KPIs include membership growth; verification throughput; correction responsiveness; conformance coverage; dispute-clock performance; handling compliance; drift detection timeliness; integrity incident rate; time-to-assurance reductions.

***

## Part 9 — Intelligence, Assistants, Content Studio, and Constitutional Forms

### 1. Handling-Separated Intelligence Surfaces

1.1 Handling-separated indices govern retrieval and summarization; cross-class reconstruction prohibited.

1.2 Recycling pipelines convert deliberations into candidate objects only through governed workflows with handling inheritance.

### 2. Assistive AI Boundaries

1.3 Assistive AI drafts and structures; it does not diagnose, prescribe, triage, adjudicate coverage, or confer standing.

1.4 Tool allowlists, logging, human override, kill-switch evidence, and drift tests are mandatory for high-impact contexts (clinical copilots, surveillance analytics, safety event triage support, coding automation).

1.5 AI outputs must carry uncertainty cues and must respect handling elections and prohibited-use constraints.

### 3. Content Studio and Normalization

1.6 Templates exist for standards, profiles, taxonomies, evidence packs, conformance objects, and reports.

1.7 Normalization may not silently change meaning; semantic changes require correction/supersession and dependency banners.

### 4. Constitutional Forms

1.8 Constitutional forms implement record-valid acts; AI may prefill; standing arises only upon accepted submission under valid role markers.

***

## Part 10 — Health Lanes and Deployment Expressions

### 1. Instance Types

1.1 FoHLP supports deployable FoH Instances for: providers/health systems, laboratories, public health agencies, manufacturers, payers (governance-only interfaces), researchers, and regulators within mandate—each with sovereignty controls, handling policy, and firewall posture.

1.2 Each instance declares scope, lawful basis posture, handling policy, and conformance election.

### 2. Clinical Safety and Quality Lane

1.3 Publishes governance-grade validation and safety evidence patterns (adverse events, pathway governance, model monitoring) without patient-specific instruction.

1.4 High-impact AI objects require provenance, drift tests, human override evidence, incident clocks, and explicit non-clinical-use labels unless lawfully mandated otherwise by an executing authority outside the Lab.

### 3. Public Health and Preparedness Lane

1.5 Publishes reporting comparability, early warning governance, uncertainty discipline, and emergency mode artifacts; non-enforcement posture.

1.6 Sensitive surveillance contexts require controlled/restricted handling and explicit lawful-basis metadata.

### 4. Operations Continuity Lane

1.7 Publishes continuity and resilience evidence patterns for hospitals and critical services (capacity, staffing, supply integrity, cyber/outage readiness) without exposing exploitable vulnerabilities.

### 5. Research Integrity Lane

1.8 Publishes reproducibility objects, dataset lineage, preregistration comparability, correctionability patterns, and COI handling.

***

## Part 11 — Sovereign Data Zones, Compute-to-Data, Federation, and Interoperability Rails

### 1. Sovereign Data Zones

1.1 SDZ-Local, SDZ-Federated, SDZ-Hybrid supported; default minimize patient data movement and maximize lawful minimization.

### 2. Compute-to-Data Jobs

1.2 Jobs declare inputs, tool allowlists, output constraints, logging, and handling inheritance; outputs pass governance gates before indexing/publication.

### 3. Federation

1.3 Federation is metadata-first; controlled/restricted content federates only by explicit authorization with distribution logs and consent posture.

### 4. Interoperability Alignment

1.4 The Lab may publish interoperability profiles and mappings (e.g., clinical data exchange, terminology equivalence, audit evidence packaging) with explicit equivalence limits and testable transformations; execution remains external and lawful.

***

## Part 12 — Security, Auditability, Retention, DR, Observability, and Cost Governance

1.1 Immutable audit logs cover access, retrieval, submissions, lifecycle transitions, distributions, publications, and admin changes; legal hold supported.

1.2 Retention is handling- and jurisdiction-specific; restricted emphasizes minimization and patient protection; deletion/destruction attestations are record-valid where applicable.

1.3 DR preserves register integrity and correction lineage; restore drills recorded; integrity checks mandatory post-restore.

1.4 Component inventory and vulnerability clocks aligned to handling class; integrity threats trigger stop-the-line and mandatory notices at appropriate handling.

1.5 Quotas, anomaly detection, and rate limits apply; no pay-to-publish influence.

***

## Part 13 — Neutrality, COI, Competition-Safe Mode, Misrepresentation, Sanctions

1.1 COI disclosures, recusals, reviewer rotation, influence caps, and transparent register states are mandatory.

1.2 Competition-safe agenda templates and minutes discipline apply in multi-vendor contexts; prohibited topic gates apply where antitrust risks exist.

1.3 Misrepresentation triggers takedown of claims, clarification notices, role/credit revocation, conformance suspension, and sanctions ladder with appeal rights.

1.4 No output may be marketed as “clinically approved,” “medically endorsed,” or “regulator endorsed” absent record-valid standing and authorized scope.

***

## Part 14 — Change Control, Conformance Claims, and Standing Claims

1.1 Revisions publish as protocol releases with diffs and migration notes; nodes declare version and conformance scope (core | core+reports | core+federation | core+lanes).

1.2 “FoHLP-Conformant” requires passing suites for object model/metadata gates, register integrity, handling segregation, immutability/correction discipline, audit logs, editorial governance, and federation invariants if enabled.

1.3 Claims auto-expire unless renewed; failures must be published with remediation clocks.

1.4 Standing claims specify scope, date, validity window, exclusions, and portability labels.

***

## Part 15 — Patient Rights, Consent, Equity, and Do-No-Harm

1.1 Human rights, informed consent, privacy, and non-discrimination are first-class invariants.

1.2 High-risk analytics require explicit lawful basis and recorded approvals; default is aggregation, minimization, and compute-to-data.

1.3 Patient-facing contexts require stricter disclosure minima, limitations cues, and clinician override posture; coercive or deceptive transparency is prohibited.

***

## Part 16 — Biosecurity Defensive Posture and Sensitive Domains

1.1 Defensive-only posture applies to biosecurity-relevant topics; no misuse guidance is published.

1.2 Sensitive material follows staged release with controlled/restricted handling, purpose-binding, expiry, and distribution logs.

1.3 Non-circumvention: requests to bypass safety, law, containment, or ethical constraints are refused.

***

## Part 17 — Rights, Licensing, Liability, and Reliance Bounds

1.1 Publication requires rights attestations; unclear rights block release.

1.2 Outputs are informational artifacts; not medical advice, not operational commands, not coverage determinations, not legal determinations.

1.3 Reliance bounds, expiry, uncertainty cues, and correction paths are mandatory and must be prominent for high-reliance objects.

***

## Part 18 — Disputes, Remedies, and Transparency Minima

1.1 Disputes may be filed for any object; clocks are mandatory; contestation propagates.

1.2 Remedies occur via correction/supersession/withdrawal with traceable lineage; silent edits prohibited.

1.3 Public-safe truth surface includes current/superseded/contested status, conformance status, and known limitations without leaking sensitive data or operational vulnerabilities.

***

## Part 19 — Interoperability with Nexus Rails and External Standards

1.1 FoHLP interoperates as governance-only infrastructure under One Rail, Two Stacks: evidence packs, conformance, correctionability, validity-by-record; execution remains external and lawful.

1.2 The Lab may publish mappings to relevant external standards and health interoperability practices with explicit equivalence limits and testable transformations; no execution, adjudication, or enforcement is performed by the Lab.

***

## Part 20 — Adoption, Effective Date, and Survival

1.1 Effective upon record-valid adoption and publication of the initial current pointer in the canonical register.

1.2 Instances claiming conformance publish scope, overlays, handling policy, and conformance status.

1.3 Validity-by-record, handling obligations, audit integrity, correction lineage, non-executing perimeter, patient rights safeguards, and defensive biosecurity posture survive amendments and wind-down to the maximum extent lawful.

***

### Binding Baselines

B.1 **Governance-only:** standards, frameworks, evidence packs, conformance, publication discipline.\
B.2 **Non-executing:** no diagnosis, no prescribing, no triage, no coverage adjudication, no enforcement.\
B.3 **Validity-by-record:** only registered objects and acts have standing.\
B.4 **Correctionability:** explicit lineage, contestation propagation, no silent edits.\
B.5 **Patient safety:** refusal/redirection, staged release, leakage testing, defensive-only biosecurity posture.\
B.6 **Firewall doctrine:** strict separation from clinical practice, payer decisions, and regulatory action.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-health/lab.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.