Sector Verticals

A trust substrate is only as credible as the verticals that ride on it. This chapter shows the substrate working under load, in production, in five sectors with very different regulatory profiles.

7.1 The substrate-and-vertical thesis

The case made through chapters 4 and 5 is that EATF is a substrate, not a product. A substrate has no native customer; its value is realised through verticals — sector-specific applications that clip onto the substrate, inherit its operational discipline, and expose a sector-specific surface to deployers.

flowchart TB
    classDef sub fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
    classDef vert fill:#fef3c7,stroke:#92400e,color:#78350f
    classDef plan fill:#e5e7eb,stroke:#6b7280,color:#374151,stroke-dasharray: 5 5

    subgraph Verticals[Partner-integration verticals]
      WQ[water-quality-ee <br> environmental]:::vert
      TA[tadf-v2 <br> building audit]:::vert
      MA[matx-hack <br> education]:::vert
      MED[medical advisory <br> planned]:::plan
      KYC[KYC / payments <br> planned]:::plan
    end

    subgraph Substrate[EATF / Aletheia substrate]
      SIG[Canonical signing <br> eatf sign / verify]:::sub
      LED[Audit ledger]:::sub
      VER[Public verifier]:::sub
      INV[Inventory + key mgmt]:::sub
    end

    WQ --> SIG
    TA --> SIG
    MA --> SIG
    MED -.-> SIG
    KYC -.-> SIG

    SIG --> LED
    SIG --> VER
    SIG --> INV

The three live verticals (water-quality-ee, tadf-v2, matx-hack) are documented below as case studies. The two planned verticals (medical, KYC / payments) are sketched in §7.6 to show how the substrate scales.

7.2 Vertical 1 — water-quality-ee (environmental monitoring)

Sector: Environmental monitoring; daily P(violation) bulletin for Estonian Terviseamet open data. Status: Live model + ML pipeline; substrate integration in preparation; bulletin publication scheduled. Reference: Reflection note 2026-04-19_aletheia-water-quality-verification-layers.md

Daily flow

sequenceDiagram
    autonumber
    participant T as Terviseamet open data API
    participant ML as water-quality-ee classifier
    participant E as EATF substrate
    participant Site as h2oatlas.ee public site
    participant Pub as Citizen / regulator

    T->>ML: Pull daily samples (XML, 5 domains)
    ML->>ML: Classify P(violation) per site
    ML->>E: Sign daily bulletin + model card hash
    E->>E: Hybrid sign, RFC 3161 timestamp, OCSP capture
    E-->>Site: Publish bulletin + .aep
    Pub->>Site: Read bulletin (incl. QR code)
    Pub->>E: Verify .aep offline against trust anchors
    E-->>Pub: Verification result

Why the substrate matters here

Water-quality classification has two distinct layers of verification, which the substrate-and-vertical model keeps cleanly separated:

• Integrity layer (substrate’s job): Did this bulletin actually come from the deployer? Has it been tampered with? Was it produced under the model card the deployer claims? — the substrate answers all three offline.
• Clinical / public-health validity layer (vertical’s job): Does P(violation) > 0.5 actually mean “do not swim”? Does the classifier generalise to next year’s data? — the substrate has no opinion. The model card and the deployer’s quality-management process are responsible.

The 2026-04-19 reflection note is the load-bearing prose for this distinction. The atlas adopts it.

Operational profile

Property	Value
Volume	~5 bulletins/day (one per domain) + 1 weekly model-card-revision signature
Algorithms	RSA-PSS-2048 + ML-DSA-65 hybrid
Block size	64 (batch-style)
Retention	5 years (public-health bulletin expectation)
Audience	Citizens (Estonian beach-goers), local authorities, Terviseamet itself

7.3 Vertical 2 — tadf-v2 (building audit)

Sector: Building audit / EHR submission for Estonian construction. Status: Live in production at tadf-audit.h2oatlas.ee since 2026-04-26; substrate integration in progress. Reference: Repository tadf-v2 and life diary 2026-04-26 entry on production rollout.

Audit flow

sequenceDiagram
    autonumber
    actor A as Auditor (human)
    participant T as TADF web app
    participant LLM as Anthropic Claude (LLM helpers)
    participant E as EATF substrate
    participant DB as TADF DOCX renderer
    participant V as Inspector / regulator

    A->>T: Open audit, enter findings
    T->>LLM: Request narrative draft, photo caption, legal-ref ranking
    LLM-->>T: Diff-reviewed suggestions
    A->>T: Accept/reject diffs
    T->>DB: Render DOCX report
    T->>E: Sign DOCX + photo hashes + model_id + policy_id
    E-->>T: .aep package URL
    T->>A: Download report + verifier link
    A->>V: Submit report (with QR for verifier)
    V->>E: Verify .aep offline
    E-->>V: Verification result

Why the substrate matters here

Building audit has explicit legal-effect requirements: the report goes to Estonian Ehitisregister (EHR) and may be cited in construction disputes. A signed .aep next to the rendered DOCX gives the inspector — and any future court — a verifiable chain from the audit’s outputs to the deployer’s identity, the model version that produced AI-assisted captions, and the policy version in force at signing time.

The hard rule, enforced in TADF code: the AI does not write the audit’s conclusions (sections 11 and 14 — Kokkuvõte and Lõpphinnang — are auditor-only). Any AI assistance is on advisory sections, with diffs the auditor explicitly accepts. The substrate signs what the auditor approved, not what the AI proposed.

Operational profile

Property	Value
Volume	Dozens of reports per week per auditor; ~10 tenants currently
Algorithms	RSA-PSS-2048 (hybrid PQC pilot in 2026 H2)
Block size	16 (default)
Retention	7 years (Estonian construction practice)
Audience	Inspectors, EHR, courts, building owners

7.4 Vertical 3 — matx-hack / MATx Teacher (education)

Sector: Math education; differentiated worksheets and AI-assisted feedback for Estonian basic-school teachers. Status: Live demo at matx-hack.h2oatlas.ee; presidential hackathon submission 2026-05-08–09. Reference: Repository matx-hack and the BKT study guide deployed at matx-hack.h2oatlas.ee.

Per-student feedback flow

sequenceDiagram
    autonumber
    actor T as Teacher
    participant App as MATx Teacher app
    participant BKT as BKT engine (web/lib/bkt.ts)
    participant LLM as LLM (feedback prose)
    participant E as EATF substrate
    actor P as Parent / student

    T->>App: Generate differentiated worksheet
    App->>BKT: Score student against micro-skills
    App-->>T: Render worksheet (PDF)
    T->>App: Scan completed sheet (V2-Omni planned)
    App->>BKT: Update P(L) per micro-skill
    App->>LLM: Compose feedback prose (Estonian)
    App->>E: Sign feedback + BKT state + curriculum version
    E-->>App: .aep with parent QR
    App-->>T: Teacher reviews, sends to parent
    T-->>P: Feedback (text + audio if TTS planned)
    P->>E: Verify provenance (QR scan)

Why the substrate matters here

Education is a high-risk sector under Annex III of the EU AI Act (point 3 — evaluation of learning outcomes that determine access to educational opportunities). MATx therefore lands on the high-risk regime by default, which means Articles 12 and 13 apply. The substrate gives:

• Article 12 (record-keeping): every piece of feedback emitted to a parent is a signed event in the per-student audit ledger. A parent’s question — what did the system tell my child this term? — is a single ledger query with an offline- verifiable answer.
• Article 13 (transparency): the bound model card explains how the BKT engine works; a parent fetching a verifier URL sees both the feedback content and the system documentation hash.

Operational profile

Property	Value
Volume	~20–25 students per teacher × ~30 feedback events per term
Algorithms	RSA-PSS-2048 (hybrid PQC after 2026 hackathon)
Block size	16
Retention	School policy + parental consent; typical 5 years
Audience	Parents, students, school inspectors

7.5 Cross-vertical observations

After three live verticals, three patterns emerge:

Pattern 1 — The substrate is uniform; the verticals are not

Every vertical uses the same eatf sign / verify primitives, the same RSA-PSS + ML-DSA-65 algorithm choice, the same canonical CBOR payload format. What differs across verticals is:

• Metadata schema (mid semver pattern, custom deployer fields).
• Policy surface (what the agent is permitted to do).
• Disclosure surface (who reads the verifier UI; how the QR codes appear in publications).
• Block-size tuning (real-time vs batch).

This is what substrate is supposed to mean: a uniform foundation that vertical-specific decisions parameterise rather than fork.

Pattern 2 — Diff-reviewed AI is the hard rule

Every live vertical enforces the same rule: AI proposes; the human disposes. The .aep Evidence Package binds the accepted output, not the AI’s raw output. Diffs are explicit, the human’s acceptance is itself signed, and the substrate has no opinion on whether the human should have accepted.

This is also the right framing for the EU AI Act’s Article 14 (human oversight): the substrate gives auditable approval events; the quality of approval is the deployer’s governance work.

Pattern 3 — The verifier URL is the integration point

Every vertical exposes a public verifier URL — h2oatlas.ee/verify/..., tadf-audit.h2oatlas.ee/verify/..., and similar. The verifier UX is uniform across verticals: a citizen, parent, regulator, or court fetches the URL, sees a structured “valid / invalid + reasons” response, and can drill down to the model card and policy version if they want. This uniformity is more important than it looks: it gives a sector-non-specialist (a beach-goer, a parent, a junior inspector) a consistent experience across deployments they might encounter.

7.6 Planned verticals

Two verticals are sketched but not yet onboarded.

Medical advisory

Status: Seed; depends on a domain co-founder. Why staged late: The medical sector has the strongest regulatory profile of any vertical the atlas considers — MDR / IVDR overlay on top of EU AI Act Annex III high-risk. The integrity-vs-clinical-validity separation argued in chapters 5 and this chapter is the load-bearing claim for the procurement story: the substrate proves this advisory came from this clinician under this model and policy; it does not prove the clinical content is correct. Conflating the two is the sector’s most common procurement-pitfall.

The first concrete deployment, when it lands, will likely be an advisory note signing flow — a clinician produces an AI-assisted draft note, accepts the diffs, the substrate signs the accepted text plus the model card and clinical policy in force. The clinician remains the responsible authority; the substrate makes the chain auditable.

KYC / payments

Status: Backlog; downstream of Visa CLI’s authorize rail. Why staged late: Payments is the highest-stakes substrate deployment and the one where soft-fail discipline (chapter 6 §6.3) matters most. We want the substrate to be very mature before exposing it to PSD2 / SCA / AML overlap.

The pattern: an AI agent proposes a payment; the Visa CLI’s authorize step is the action firewall (chapter 4 §4.4); on authorization the substrate signs the PaymentIntent + reasoning trace + policy version; the resulting .aep is logged to the audit ledger and (for high-stakes payments) to a regulator-accessible endpoint.

7.7 What this chapter set up for chapter 8

Each vertical exposes its own open problems. Chapter 8 collects the cross-vertical ones — Article 10 data quality (water-quality classification fitness; medical training-data representativeness), Article 14 oversight (every vertical), 30-year retention (medical, construction), agent-of-agent delegation (KYC payment chains), privacy-preserving evidence (medical and financial both want it).

The substrate is an enabler for the next decade of trustworthy-AI engineering. The verticals are where that trustworthy-AI engineering actually happens.

7.8 Outgoing links

• → Chapter 8 · the open problems each vertical surfaces.
• → Per-vertical repositories:
  • water-quality-ee
  • tadf-v2
  • matx-hack
• → aletheia-ai partner-integration READMEs for each vertical’s onboarding spec.