Demo walkthrough — Validation-as-a-Service
This page replays the live demo from the Class NK meeting on 28 May 2026 — for anyone who could not attend, or who wants to watch it again at their own pace.
The demo shows the Validation-as-a-Service agent chain processing a real noon report end-to-end, with each agent’s role surfaced visibly.
The scenario
A ship operator uploads a noon report to Class NK. Today, a Class NK surveyor opens it, checks it manually against CII / EU MRV / FuelEU rules, and either approves it or sends it back for correction.
The demo shows what happens when that workflow is run by an agent team with a human surveyor at the judgment point.
Step 1 — Intake agent receives the upload
The intake agent ingests the noon report, normalises the data format, and detects obvious problems (missing fields, wrong units, broken timestamps) before any downstream work begins.
Video timestamp: 0:00–1:30
What the agent surfaces: parsed data + format issues + confidence score. What the surveyor sees: nothing — this is fully automatic. What gets logged: the raw upload + the parsed structure + any rejections.
Step 2 — Validator agent checks against rules
The validator agent runs the cleaned data through the relevant rule sets:
- CII — Carbon Intensity Indicator calculation
- EU MRV — Monitoring, Reporting, Verification
- FuelEU Maritime — fuel consumption + emissions thresholds
- Class NK internal rules — if Class NK has additional checks beyond the international rules
For each rule, the agent records: rule reference, expected value range, actual value, pass/fail.
Video timestamp: 1:30–4:00
What the agent surfaces: rule-by-rule pass/fail with citations. What the surveyor sees: nothing for now — wait for anomaly detector. What gets logged: the full validation trace.
Step 3 — Anomaly detector flags suspicious entries
The anomaly detector looks for entries that pass the rule checks but look wrong — values that are within bounds but inconsistent with the vessel’s recent history, with other entries in the same report, or with physical plausibility.
Examples:
- Fuel consumption that passes CII checks but is 40% lower than the same vessel reported last week
- Sea state recorded as “calm” but speed-over-ground 30% below expected at reported RPM
- Port name spelling that matches no IMO port code
Video timestamp: 4:00–6:30
What the agent surfaces: anomalies with explanations. What the surveyor sees: still nothing — wait for casefile. What gets logged: every anomaly and its reasoning chain.
Step 4 — Casefile agent opens or updates the casefile
The casefile agent finds (or creates) the casefile for this vessel + reporting period. It attaches the noon report, the validation trace, and the anomaly findings. The casefile is now the single source of truth for this submission.
Video timestamp: 6:30–8:00
What the agent surfaces: a structured casefile with all linked evidence. What the surveyor sees: still nothing — only sees the casefile if escalated. What gets logged: every attachment and every link.
Step 5 — Escalation router decides if a human is needed
If everything passed and no anomalies were flagged: route to auto-approve and notify the client. If anomalies need a human judgment: route to the right surveyor based on vessel, region, and surveyor specialisation.
Video timestamp: 8:00–9:30
What the agent surfaces: routing decision + reasoning. What the surveyor sees: a notification with the pre-prepared casefile, only if the routing decision was to escalate.
Step 6 — Surveyor reviews (human in the loop)
The surveyor opens the casefile, sees the agent’s work surfaced clearly:
- Validation results with citations
- Anomalies with explanations
- Recommended action (“hold for clarification” / “request specific data” / “approve with note”)
The surveyor accepts, modifies, or overrides. Whatever they decide, the casefile records it.
Video timestamp: 9:30–12:00
What the surveyor does: makes the judgment call. Spends seconds, not minutes, because the work-up was done for them. What gets logged: the surveyor’s decision + reasoning.
Step 7 — Client notified with detail
The client receives a structured notification — approved or needs-correction — with the agent’s reasoning, the surveyor’s decision, and clear next steps if a correction is needed.
Video timestamp: 12:00–13:30
What the client experiences: a fast, transparent, citeable response. Not silence-then-decision; live progress + clear reasons.
Step 8 — Audit logger preserves the chain
Every step is in the audit log: the raw upload, the parsing, every rule check with its citation, every anomaly with its reasoning, the casefile structure, the routing decision, the surveyor’s call, the client notification. Reconstructable from first principles. Court-grade trail if ever needed.
Video timestamp: 13:30–15:00
Where the parts come from
Each agent in this chain rests on a skill that already runs in production for ship-operator clients. The orchestration layer is what makes them work together as a team — with handoffs, with memory, with audit, with a human at the judgment seat.
If a pattern like this ever ran inside Class NK, what Class NK would add is the rule set, the surveyor’s authority, and the relationships with clients. The orchestration is the substrate; the institutional expertise is what would make it valuable.
Source code
The agent definitions, skill code, and orchestration configuration are all available:
- Skills: github.com/metaweavehq — noon-report-cleaning, validate-vessel-data, veracity-validator
- Orchestration: LifeOS AI substrate
The code is source-available — anyone can clone, run locally, modify.