# Lab ### Part 0 — Charter Identity, Authority, and Invariants 1. **Instrument nature.** This Charter is the constitutional governance instrument for the Future of Water Lab (the “FoW Lab”), establishing a governed, AI-assisted, community-operated standards, frameworks, and intelligence commons for water security, service continuity, basin cooperation, and public health protection under strict non-authoritative limits. 2. **Charter invariants.** The following invariants are mandatory for any FoW Lab instance (“FoW Instance”) claiming conformance:\ 2.1 **Two-stack firewall alignment:** governance-only core; execution external.\ 2.2 **Non-executing perimeter:** no operations dispatch, tariff setting, rights allocation, permitting, inspections, enforcement, or emergency command.\ 2.3 **Validity-by-record:** standing arises only from record-valid acts and registered current pointers.\ 2.4 **Handling classes & staged release:** Public-Safe / Controlled / Restricted with leakage prevention.\ 2.5 **Correctionability:** no silent edits; explicit supersession; diffs; dependency propagation.\ 2.6 **Conformance & reproducibility discipline:** tests, vectors, reports, validity windows for material claims.\ 2.7 **Competition-safe mode & anti-capture controls:** COI, recusals, influence caps, procurement neutrality.\ 2.8 **Bounded reliance:** intended use, prohibited use, limitations, uncertainty, expiry.\ 2.9 **Critical infrastructure protection:** no weaponizable vulnerabilities; refusal/redirection; Restricted-by-default for vulnerability-adjacent artifacts.\ 2.10 **Rights and equity:** Indigenous stewardship and community rights, FPIC-aligned engagement, and do-no-harm service safeguards are first-class.\ 2.11 **Sovereignty and privacy:** minimize data movement; maximize artifact mobility; purpose binding and minimization by default.\ 2.12 **Public health integrity:** advisories and communications integrity objects must include uncertainty cues, remedy paths, and anti-panic safeguards. 3. **Precedence.** In the event of conflict:\ 3.1 Invariants prevail over overlays and local customizations.\ 3.2 Handling and critical-infrastructure safety prevail over publication convenience.\ 3.3 Registered records prevail over off-platform statements.\ 3.4 Supersession chains prevail over static copies and cached renders. 4. **Non-endorsement.** No participation, output, conformance report, or FoW publication constitutes certification, regulatory approval, water-rights adjudication, or official advisory unless explicitly recorded as a designated act by a competent authority with stated scope and validity window. 5. **Non-allocator posture.** The FoW Lab does not allocate water rights, set allocation rules, or decide inter-sector distribution; it publishes governance-grade objects that competent authorities may use within lawful mandates. *** ### Part 1 — Purpose, Scope, and Operating Thesis 1. **Purpose and public-good function.** The FoW Lab converts multi-stakeholder contributions into structured, versioned, reusable objects for the future of water under deterministic lifecycle rules, explicit reliance bounds, and correctionability. 2. **Operating thesis.** Water systems become safer, more equitable, and more investable when hydrologic, infrastructure, quality, affordability, and governance claims are expressed as testable, auditable, and correctionable objects—without collapsing sovereignty, Indigenous and community rights, privacy, due process, procurement neutrality, competition safety, or regulated perimeters. 3. **Scope of “future of water.”** “Future of water” includes, without limitation, governance-grade objects covering:\ 3.1 Water supply security (surface/groundwater availability, storage, drought risk, contingency planning).\ 3.2 Demand and allocation evidence (sectoral demand, leakage/non-revenue water, conservation effectiveness, equity impacts), without allocating rights.\ 3.3 Watersheds and basins (transboundary cooperation, governance overlays, allocation instrument semantics, dispute pathways).\ 3.4 Water quality and safety (source water protection, contaminant monitoring governance, advisory evidence patterns).\ 3.5 Wastewater and reuse (treatment reliability, reuse governance, discharge integrity, circularity evidence objects).\ 3.6 Stormwater and urban flooding (drainage capacity, pluvial risk, green/gray infrastructure performance evidence).\ 3.7 Water infrastructure integrity (asset condition semantics, failure modes, maintenance governance, capex prioritization evidence).\ 3.8 Utility operations and service continuity (pressure/flow reliability, outage response evidence, customer vulnerability safeguards).\ 3.9 Agricultural water and irrigation (efficiency evidence, soil moisture governance, salinization risk, food-water link objects).\ 3.10 Industrial water and critical manufacturing dependencies (chip fabs, hydrogen, mining, cooling water; permitting interfaces as governance objects).\ 3.11 Ecosystems and environmental flows (minimum flows, habitat protection, nature-based solutions performance evidence).\ 3.12 Climate and disaster risk (drought, flood, wildfire-ash impacts, sea level intrusion, compound events; non-stationarity cues).\ 3.13 Groundwater governance (aquifer accounting, depletion risk, recharge programs, rights evidence and enforcement boundaries).\ 3.14 Desalination and alternative supply (energy-water coupling, brine governance, reliability and cost transparency objects).\ 3.15 Contamination events and emergency water (boil-water advisories, alternative supply logistics at safe granularity).\ 3.16 WASH and last-mile resilience (schools, clinics, informal settlements; safeguarding and equity evidence).\ 3.17 Water-related finance and procurement (project comparability, O\&M resilience evidence, performance-based contract semantics).\ 3.18 Digital water and sensing (metering governance, SCADA boundaries, cybersecurity posture objects, data minimization).\ 3.19 Public health interfaces (pathogen governance, chemical exposure governance, communications integrity patterns).\ 3.20 Rights, equity, and Indigenous stewardship (FPIC-aligned governance objects, community remedy pathways).\ 3.21 Pollution and industrial discharge interfaces (permit semantics, monitoring integrity, incident evidence patterns).\ 3.22 Urban growth and land-water coupling (demand growth governance, siting and zoning interfaces as non-executing objects).\ 3.23 Conflict, displacement, and humanitarian water continuity (bounded-reliance continuity packs; do-no-harm safeguards). 4. **System-of-systems dependencies.** Scope includes dependencies treated as water system risks: energy grids, telecom/5G/6G, cloud and software supply chain, chemical supply chains, geopolitics/sanctions, commodity shocks, and synthetic media/disinformation dynamics affecting public trust and emergency behavior. 5. **Water as critical infrastructure.** The FoW Lab treats water as a critical infrastructure and societal stability substrate requiring correctionable decision influence across emergency management, finance, public health, agriculture, energy, and urban systems. 6. **Intended users and outcomes.** The FoW Lab serves utilities, basin authorities, ministries, regulators (within mandate), municipalities, emergency management, public health bodies, operators, engineers, auditors/assurers, researchers, infrastructure financiers, MDB/DFIs, NGOs, and community/Indigenous stewards by producing objects that are portable, testable, correctionable, and examiner-operable. Outcomes include faster safer decisions under drought/flood/contamination, improved reliability and affordability, stronger public trust, investable project comparability, and measurable integrity of resilience and continuity claims. 7. **Output classes.** The FoW Lab produces and maintains, without limitation:\ 7.1 Standards; frameworks; profiles/implementation guides; taxonomies/ontologies.\ 7.2 Defensive typology libraries; artifacts and method cards.\ 7.3 Conformance suites; conformance reports; release bundles.\ 7.4 Corrections/supersessions/withdrawals/pointer freezes.\ 7.5 Interoperability mappings; learning modules; clinics; guild credentials.\ 7.6 Assurance & Evidence Packs (**AEP-WATER**).\ 7.7 Future of Water reports and subscription editions with dependency banners.\ 7.8 Objects have lifecycle state and registry pointers; documents are views. *** ### Part 2 — Boundary, Non-Executing Perimeter, and Firewall Doctrine 1. **Boundary of the Lab.** The FoW Lab provides governance infrastructure for identity/participation, collaboration workspaces, forms-first records workflows, canonical registers and truth surfaces, handling-separated indexing and retrieval, publication/versioning/correction discipline, conformance and reproducibility operations, report desks/subscription channels, cloneable instance kits, and federation-safe interoperability scaffolding. 2. **Two-stack firewall alignment.**\ 2.1 The FoW Lab operates exclusively as public-good governance infrastructure: standards/schemas, evidence integrity, validity-by-record, handling and safeguards, conformance, release/correction discipline, and audit structures.\ 2.2 Execution occurs only outside the Lab in lawful institutional processes and delivery stacks (utilities/operators, engineering firms, EPCs, labs, regulators within mandate, emergency responders, financiers, procurement bodies).\ 2.3 Integrations are limited to interoperability mappings, compatibility notes, conformance-tested connectors, and evidence packaging patterns; they do not widen the Lab into an operator, allocator of rights, regulator, certifier, or enforcement tool. 3. **Non-executing perimeter.**\ 3.1 The FoW Lab does not operate infrastructure, dispatch crews, set tariffs, allocate water rights, issue permits, enforce compliance, conduct enforcement inspections, or direct emergency operations.\ 3.2 The FoW Lab does not publish actionable vulnerabilities or exploitation guidance (SCADA intrusion playbooks, sabotage vectors, site-specific weaknesses).\ 3.3 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.** Requests increasing harm risk (sabotage enablement, contamination tactics, cyber intrusion, rights evasion, discriminatory service denial playbooks) are refused or redirected into defensive governance outputs (controls, safe detection patterns, audit checklists, conformance suites, incident clocks). Sensitive legitimate contexts follow staged release: public-safe abstract first; controlled/restricted content purpose-bound, expiry-bound, and logged. 5. **Emergency neutrality rule.** The FoW Lab does not issue operational orders during crises; it may publish bounded-reliance decision-influence objects with explicit uncertainty and remedy paths. *** ### Part 3 — Validity-by-Record, Registers, Current Pointers, and Designated Acts 1. **Validity-by-record.** Standing arises only from record-valid acts executed through FoWLP workflows and reflected in canonical registers, current pointers, and supersession chains. 2. **No standing for informal dissemination.** Off-platform statements have no standing unless represented as record-valid objects with mandatory metadata, handling election, provenance/rights attestations, and registry pointers. 3. **Canonical registers and truth surface.** Each FoW Instance maintains, at minimum, registers for:\ 3.1 Object identity and lifecycle state.\ 3.2 Current pointer and supersession chain.\ 3.3 Conformance suites and conformance report registry.\ 3.4 Handling elections, staged release state, distribution logs, and expiry enforcement.\ 3.5 COI disclosures, recusals, influence cap states, sanctions, appeals, and reinstatements.\ 3.6 Report edition registry with dependency banners and contestation propagation.\ 3.7 AI provenance and tool enablement records where AI is used in governed workflows.\ 3.8 Security and incident register (stop-the-line, leakage tests, remediation records). 4. **Designated acts.** Minimum Designated acts include:\ 4.1 Adoption/recognition as Current.\ 4.2 Release publication and current-pointer movement.\ 4.3 Issuance of conformance claims and conformance reports for external reliance.\ 4.4 Issuance of AEP-WATER intended for external reliance (audit/procurement/disclosure/contractual).\ 4.5 Sanctions/revocations/reinstatements; withdrawals; emergency reliance constraints; pointer freezes. 5. **Dual recording and mismatch lock.** Where required, Designated acts are anchored by dual records (authority record + anchoring record as elected). Any mismatch in authority basis, scope, object ID/version, or pointer status renders the act **Inoperative (Mismatch)** until reconciled by recorded decision; dependent objects and reports display visible warnings. 6. **Local-only standing.** Deployments without required dual recording must label relevant acts **Local-Only Standing** with explicit portability limits. *** ### Part 4 — Definitions, Glossary, and Domain Lexicon 1. **AEP-WATER.** A sealed Assurance & Evidence Pack expressing bounded-reliance determinations for water security, quality posture, continuity posture, basin cooperation posture, affordability safeguards, and critical dependencies without leaking protected inputs. 2. **Water Security Posture.** Evidence-bound description of availability and reliability under stress (supply, storage, demand, contingency options), including uncertainty and expiry. 3. **Quality Posture.** Evidence-bound description of monitoring integrity, contaminant governance, advisory readiness, and public health interfaces, without publishing weaponizable tactics. 4. **Continuity Posture.** Evidence-bound description of service continuity (pressure/flow reliability, outage response readiness, mutual aid posture, critical dependency exposures) with correction clocks. 5. **Basin Cooperation Overlay.** Profile expressing governance deltas for transboundary coordination, dispute pathways, consent boundaries, and portability labels. 6. **Affordability Safeguards.** Objects expressing do-no-harm service continuity, subsidy/transfers evidence patterns (if addressed), and grievance/remedy clocks without targeting exploitation. 7. **Critical Infrastructure Safety.** Publication and handling discipline ensuring outputs do not increase attack surface or enable sabotage. 8. **Non-stationarity cues.** Mandatory uncertainty language for hydrologic and climate domains: scenario bands, confidence fields, time-validity, and drift obligations. *** ### Part 5 — Canonical Object Model, IDs, Lifecycle States, and Release Semantics 1. **Objects, not documents.** Authority attaches only to a versioned object with lifecycle state and registry pointer; documents are views. 2. **Immutability and edition rules.** Releases and report editions are immutable; changes occur only via corrections/supersessions/withdrawals with diffs, migration notes, and dependency propagation. 3. **Canonical object families.** The FoW Lab maintains, at minimum:\ 3.1 **STD-WATER (Standards):** normative invariants for monitoring minimums, reporting semantics, continuity claims discipline, advisory communications integrity, and dependency disclosure.\ 3.2 **FRM-WATER (Frameworks):** governance/control frameworks for utilities, basins, quality posture, and resilience investment comparability.\ 3.3 **PRF/IG-WATER (Profiles/Implementation Guides):** overlays as deltas not forks (utility class, basin type, jurisdiction, WASH settings).\ 3.4 **TAX/ONT-WATER (Taxonomies/Ontologies):** hazards, contaminants, assets, controls, outcomes, dependencies; drift-tested.\ 3.5 **TYP-WATER (Typology Libraries):** defensive typologies for incident classes, fraud/abuse classes, procurement red-flags at safe granularity, and communications integrity patterns.\ 3.6 **ART-WATER (Artifacts/Method Cards):** rubrics, checklists, audit cards, scenario cards, model/dataset cards.\ 3.7 **AEP-WATER (Assurance & Evidence Packs):** sealed determinations for drought readiness, contamination response posture, asset integrity posture, affordability safeguards, basin agreement posture.\ 3.8 **CS-WATER / CR-WATER (Conformance Suites/Reports):** harnesses, vectors, signed results, validity windows.\ 3.9 **REL-WATER / COR-WATER (Release Bundles / Corrections):** immutable bundles and governed change objects.\ 3.10 **RPT-WATER / SUB-WATER (Reports / Subscription Channels):** immutable editions with dependency banners.\ 3.11 **MAP/IOP-WATER (Mappings/Interoperability Profiles):** crosswalks to asset management, water service, resilience, and environmental standards with equivalence limits and testable transformations.\ 3.12 **WGC-WATER / RM-WATER / DR-WATER / CFW-WATER:** charters/role markers/decision records/calls for work.\ 3.13 **CONSENT-WATER / TRANSP-WATER:** consent and transparency elections (right-to-know posture, confidentiality elections, community notice posture). 4. **Object ID rules.** Object IDs are deterministic and stable:\ 4.1 **Format:** `FoW......` with optional overlay suffix `+` and handling marker `@A|B|C`.\ 4.2 **Major:** breaking semantic/normative change; requires migration notes and conformance vector refresh.\ 4.3 **Minor:** additive compatible change; requires diffs and updated validity notes.\ 4.4 **Patch:** corrective change; requires explicit correction record and diff.\ 4.5 **Non-reuse:** IDs may not be reused for different meaning. 5. **Mandatory metadata and deterministic blockers.** Publishable objects require: scope/exclusions; handling election; intended use; prohibited use; reliance bounds; limitations/uncertainty; expiry/review; correction/dispute path with clocks; provenance/rights; COI link; dependency graph; jurisdiction label; and harm-prevention statement. Missing mandatory metadata blocks publication; prohibited-use statements are mandatory where sabotage/cyber/rights-evasion risk is credible. *** ### Part 6 — Records-First Governance, Roles, Authorities, and Due Process 1. **Record-valid acts.** All governance and lifecycle actions occur only through record-valid acts: onboarding, COI, handling elections, working group chartering, role markers, releases, reports, conformance submissions, corrections, disputes/appeals, waivers, sanctions, reinstatements, and publication. 2. **Human authority rule.** AI drafts and structures only; standing arises from human-authorized recorded acts under valid role markers and acceptance gates. 3. **Minimum governance spine.** Each FoW Instance maintains, at minimum:\ 3.1 Records & Register Officer.\ 3.2 Handling & Safety Officer.\ 3.3 COI & Neutrality Officer.\ 3.4 Conformance Lead.\ 3.5 Editorial Lead (Publication Desk).\ 3.6 Dispute Resolution Panel Lead (rotation rules).\ 3.7 Security & Integrity Officer (stop-the-line authority).\ 3.8 Basin & Rights Steward (transboundary governance, dispute pathways, consent boundaries).\ 3.9 Public Health & Advisory Integrity Steward (risk comms discipline, uncertainty cues, remedy pathways).\ 3.10 Utility Continuity Steward (continuity posture semantics, dependency disclosures). 4. **Separation of duties.** No single actor may originate, independently verify, and publish the same high-reliance claim without independent review; waivers require scope, compensating controls, and expiry. 5. **Decision Records.** Pointer moves, reliance-bearing conformance reports, reliance-bearing AEP-WATER issuance, sanctions, and withdrawals require Decision Records stating rationale, scope, limitations, and remedy path. 6. **Due process clocks.** Minimum clocks apply unless stricter overlays are elected:\ 6.1 Triage within 72 hours (or sooner for integrity incidents).\ 6.2 Response window normally ≤ 14 calendar days.\ 6.3 Routine resolution target ≤ 30 calendar days, extendable by recorded reason and interim reliance constraints.\ 6.4 High-impact corrections target ≤ 72 hours from confirmation; leakage triggers immediate stop-the-line.\ 6.5 Quarterly correction cycle for drift reconciliation, deprecations, and release notes. 7. **Stop-the-line authority.** Integrity incidents trigger pointer freezes, publication pauses, access revocation, recall attempts where feasible, and a recorded remediation plan with clocks. *** ### Part 7 — Handling, Staged Release, Distribution Logs, and Critical Infrastructure Safety 1. **Handling classes.** Public-Safe (A), Controlled (B), Restricted (C), with deny-by-default for Restricted. 2. **Handling inheritance and down-classification.** Bundles inherit highest handling; down-classification requires recorded decision and safety review; public-good extracts preserve IDs, pointers, and lineage. 3. **Distribution logs.** Controlled and Restricted distributions require logged recipient class, purpose, timebox, and revocation conditions; Restricted requires watermarking and two-person approval. 4. **Water misuse taxonomy.** High-risk misuse categories include: sabotage enablement; contamination tactics; SCADA exploitation; disclosure of site-specific vulnerabilities; bypassing rights/permits; coercive service denial playbooks; re-identification of customers or sensitive sites; and destabilizing rumor amplification during advisories and shortages. 5. **Refusal and redirection.** Misuse-category requests are refused or redirected into defensive outputs (controls, safe detection patterns, audit checklists, conformance suites, incident clocks) without operational enablement. 6. **Leakage prevention.** Handling separation must hold across indices, retrieval, assistants, embeddings, exports, cached previews, and connectors; cross-class reconstruction is prohibited. 7. **Leakage testing.** Mandatory per release, quarterly per instance, and after model/provider/index/embedding/connector changes; failures trigger stop-the-line and corrective records. *** ### Part 8 — Competition-Safe Mode, COI, Neutrality, and Anti-Capture 1. **COI disclosure and recusal.** COI disclosures and recusals are mandatory, recorded, and auditable. 2. **Influence caps.** Default cap: no single organization controls more than 20% of reviewer/maintainer role markers for an object family or release cycle; sponsor concentration thresholds trigger compensating controls. 3. **Competition-safe meeting protocol.** Multi-vendor contexts require prohibited-topic gates, agenda templates, minutes discipline, and explicit neutrality posture. 4. **Procurement neutrality.** Outputs remain vendor-neutral and evidence-based; procurement use requires explicit reliance bounds and must not be used as exclusionary market power absent competent authority and due process. 5. **Misrepresentation.** False claims of certification/endorsement/official status trigger takedown, public clarification, sanctions, and appeal rights. *** ### Part 9 — Conformance, Reproducibility, Plugfests, and Drift Governance 1. **Conformance discipline.** High-reliance claims require conformance suites and signed conformance reports with validity windows; conformance is bounded, non-endorsing, and time-limited. 2. **Conformance suite minimum specification.** Each CS-WATER includes: claim scope; normative references; harness requirements; vectors (gold/negative/adversarial); pass/fail thresholds; handling constraints; and replay instructions. 3. **Conformance report minimum specification.** Each CR-WATER includes: suite ID/version; environments; toolchain identifiers; results; exclusions; observed failure modes; and validity window. 4. **Replication cells.** Replication cells rerun suites across environments; independence required for high-reliance claims; failures trigger notices, pointer freezes, withdrawals, or remediation clocks. 5. **Plugfests.** Plugfests validate multi-implementation interoperability across:\ 5.1 AEP-WATER schemas and portability labels.\ 5.2 Aggregated telemetry semantics and handling inheritance (no attack-surface exposure).\ 5.3 Asset-condition semantics and integrity receipts for O\&M reporting.\ 5.4 Drought/flood indicator definitions with non-stationarity cues.\ 5.5 Contaminant governance reporting semantics and advisory integrity objects.\ 5.6 Basin cooperation overlays (dispute clocks, consent boundaries, notice obligations).\ 5.7 Assistant safety boundaries (refusal correctness; leakage resistance). 6. **Drift governance.** Drift testing governs ontology drift, indicator drift under climate non-stationarity, mapping equivalence drift, assistant refusal drift, and model/tool drift; material drift triggers remediation clocks and may freeze pointers. 7. **Deprecation and migration.** Deprecations require successor pointers, migration notes, and runway. *** ### Part 10 — Identity, Participation, Guild System, Credits, and Competence 1. **FoW Passport.** Each contributor holds a FoW Passport capturing expertise (hydrology, engineering, public health, utility ops, basin governance, Indigenous stewardship, finance), jurisdictions, languages, and COI disclosures; authority arises only from role markers. 2. **Authentication and authorization.** SSO/MFA with step-up for Controlled/Restricted actions; RBAC+ABAC using role marker, handling class, jurisdiction, purpose, timebox, and device posture; Restricted is deny-by-default. 3. **Work units.** Guilds, working groups, review pools, replication cells, clinics, and publisher rooms are recognized work units; outputs gain standing only via record-valid workflows and gates. 4. **Credits and anti-gaming.** Verification and replication credits outrank drafting; caps apply; reviewer rotation prevents concentrated influence; clawbacks apply for misconduct. 5. **Competence tracks.** Tracks include: Water Security Analyst, Basin & Rights Steward, Utility Continuity Steward, Quality/Advisory Integrity Steward, Conformance Engineer, Interop Engineer, Editorial Lead, Handling/Safety Specialist with renewal obligations. 6. **KPIs.** Minimum KPIs include membership growth; verification throughput; correction responsiveness; conformance coverage; dispute-clock performance; handling compliance; integrity incident rate; and publication dependency hygiene. *** ### Part 11 — Assistive AI, Intelligence Operations, and Content Studio 1. **Handling-separated indices.** The FoW platform maintains handling-separated indices; cross-class reconstruction is prohibited. 2. **Assistive AI boundaries.** AI may draft/structure; AI may not approve, operate infrastructure, dispatch resources, issue official advisories, set tariffs, allocate rights, or make regulatory determinations; AI may not produce weaponizable outputs. 3. **AI provenance.** AI-assisted publication requires recorded model/provider identifiers, version pins, tool enablement, relevant prompt classes, and configuration sufficient for reproducibility and drift accountability. 4. **Content studio.** Templates for standards, profiles, taxonomies, AEP-WATER, conformance objects, and reports; semantic changes require correction/supersession objects, not silent edits. 5. **Constitutional forms.** Record-valid acts are executed via constitutional forms; AI may prefill only from authorized indices under handling rules. *** ### Part 12 — Water Security Lane (Supply, Drought, Alternative Sources) 1. **Lane scope.** The FoW Lab publishes comparability primitives for availability, reliability, resilience, affordability, and quality, including uncertainty cues and correction clocks. 2. **AEP-WATER security packs.** AEP-WATER patterns cover drought readiness, storage adequacy, demand management integrity, alternative supply governance (reuse/desalination), and emergency supply continuity—without revealing exploitable vulnerabilities. 3. **Non-stationarity discipline.** Security artifacts must include scenario bands, confidence fields, expiry windows, and drift obligations. *** ### Part 13 — Water Quality, Contaminants, and Public Health Interface Lane 1. **Lane scope.** The FoW Lab publishes governance-grade objects for monitoring, sampling integrity, lab chain-of-custody patterns, advisory decision evidence patterns, and communications integrity. 2. **Non-weaponizable rule.** No contamination enablement or evasion guidance; typologies and controls are defensive and safe. 3. **AEP-WATER quality packs.** AEP-WATER patterns cover monitoring posture, advisory readiness posture, and remediation evidence with bounded reliance. *** ### Part 14 — Utility Operations, Asset Integrity, and Service Continuity Lane 1. **Lane scope.** The FoW Lab publishes reliability evidence patterns (pressure/flow continuity, outage response readiness, NRW/leakage governance), maintenance governance, and lifecycle O\&M evidence semantics. 2. **Asset integrity comparability.** Crosswalks support asset management and resilience standards with equivalence limits; conformance suites validate reporting semantics and integrity receipts. 3. **Mutual aid and surge readiness.** Governance objects may express mutual aid posture and surge capacity readiness without directing operations. *** ### Part 15 — Basin Governance, Rights, Equity, and Indigenous Stewardship Lane 1. **Lane scope.** The FoW Lab publishes objects for basin agreements, allocation governance overlays, dispute pathways, consent boundaries, notice obligations, and remedy pathways—at safe granularity. 2. **Rights safeguards.** Indigenous stewardship and FPIC-aligned engagement objects are first-class; outputs enabling rights evasion or inequitable deprivation are prohibited. 3. **Transboundary integrity.** Corridor/basin overlays include portability labels and non-equivalence warnings to prevent over-claiming interoperability. *** ### Part 16 — Stormwater, Flooding, Coastal Intrusion, and Nature-Based Solutions Lane 1. **Lane scope.** The FoW Lab publishes comparability primitives for pluvial/fluvial/coastal flooding, drainage performance, seawater intrusion governance, and nature-based solution performance evidence. 2. **Evidence discipline.** Nature-based solutions require lifecycle maintenance evidence, uncertainty disclosures, and bounded reliance claims. 3. **Plugfest posture.** Plugfests validate indicator definitions and reporting semantics for flood and stormwater objects. *** ### Part 17 — Digital Water, Telemetry, Cyber Boundaries, and Privacy 1. **Telemetry posture.** The FoW Lab publishes safe telemetry semantics (aggregated, purpose-bound) and interoperability profiles for meters, SCADA summaries, asset registries, and incident logs—without exposing attack surfaces. 2. **Cyber and critical infrastructure safety.** Vulnerability-adjacent artifacts default to Restricted handling; Public-Safe extracts focus on controls and governance, not exploitability. 3. **Privacy and minimization.** Digital water artifacts require minimization, retention elections, purpose binding, and re-identification risk statements as publication gates. *** ### Part 18 — Publication Discipline, Reports, Subscriptions, Templates, and Standing Claims 1. **Publication as governed act.** Publication is record-valid and assigns standing, handling, reliance bounds, expiry, and correction clocks; informal dissemination is non-authoritative. 2. **Edition immutability.** Reports and subscription editions are immutable; updates occur only via corrections/supersessions with diffs and migration notes. 3. **Dependency banners.** Publications propagate dependency status (current/superseded/contested/withdrawn) and display reliance constraints where dependencies are contested or withdrawn. 4. **Subscription channels.** Subscription channels are governed distribution objects specifying audience eligibility, purpose binding, handling constraints, retention rules, and auditability. 5. **Communications integrity.** Public communications must match register truth and conformance evidence; materially misleading claims are integrity incidents requiring corrective publication. *** ### Part 19 — Security, Auditability, Retention, DR, Observability, Cost Governance, Remedies, and Wind-Down 1. **Audit logs.** Immutable audit logs cover access, retrieval, submissions, lifecycle transitions, distributions, publications, and administrative changes; legal hold is supported. 2. **Retention and minimization.** Retention is handling- and jurisdiction-specific; Restricted emphasizes minimization and verified destruction where lawful; Public-Safe archives remain permanent for released editions. 3. **Disaster recovery.** DR preserves register integrity, current pointers, and correction lineage; restore drills are recorded. 4. **Supply chain integrity.** Component inventory, vulnerability clocks, and secure release practices are mandatory; integrity threats trigger stop-the-line. 5. **Cost governance.** Quotas and budgets apply; rate limiting and anomaly detection enforced; no pay-to-publish influence; standing arises from record-valid acts, not spend. 6. **Remedies and appeals.** Disputes and appeals follow clocks; contestation propagates; remedies include corrections, supersessions, withdrawals, pointer freezes, role revocations, and corrective publications. 7. **Integrity incidents.** Integrity incidents include leakage, misrepresentation, prohibited enablement, records tampering, COI concealment, and handling violations; incidents trigger stop-the-line and public-safe incident abstracts where lawful. 8. **Termination and wind-down.** Wind-down preserves permanence for Public-Safe releases, current pointer lineage, and correction history; Controlled/Restricted materials follow retention/legal-hold and minimization rules with verified destruction where lawful; a final status notice publishes portability limits. *** ### Charter-Level Binding Baselines 1. **Governance-only:** standards, frameworks, evidence packs, conformance, correctionability, publication discipline. 2. **Non-executing:** no operations dispatch, tariff setting, rights allocation, permitting/enforcement, inspections, or emergency command. 3. **Validity-by-record:** only registered objects and acts have standing. 4. **Correctionability:** explicit lineage and contestation propagation; no silent edits. 5. **Critical infrastructure safety:** staged release, leakage testing, refusal/redirection for sabotage/cyber misuse. 6. **Rights + equity:** affordability and Indigenous/community stewardship safeguards are first-class invariants. 7. **Firewall doctrine:** strict separation from operators and regulators; interoperability only. --- # 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-water/lab.md?ask= ``` 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.