INSPEKTORIUM

Technical AI Governance & AI Assurance Research

INSPEKTORIUM investigates how requirements for AI systems can be translated into technical controls that can be tested, challenged and audited. Scientific Claim Forensics is its flagship application.

The idea in one picture

Twenty artifacts pass a check. Switch between baseline processing and the full control layer to see what each one lets through.

INPUT · 20 ARTIFACTS BASELINE PROCESSINGACCEPTED · 0BLOCKED · 0A01A02A03A04A05A06A07A08?A09A10A11A12A13A14A15A16?A17A18A19A20
0 / 12
Corrupted artifacts blocked
0 / 6
Clean artifacts accepted
0 / 2
Valid-looking but wrong — still passed
torn tile = corruptedcheck = clean? = valid-looking, semantically wrong

Internal experiment, not independent validation. The counts are the recorded pilot result; which individual artifacts the baseline caught is illustrative.

Pilot result. Twenty artifacts: twelve corrupted, six clean, two valid-looking but semantically wrong. Baseline processing blocked four of the twelve corrupted artifacts. The full control layer blocked all twelve, accepted all six clean artifacts, and still passed the two valid-looking but wrong ones.

The research question

How does a requirement for an AI system become something you can test?

INSPEKTORIUM does not claim that an AI system is generally safe. It examines specific properties of a workflow under defined conditions, and reports where the controls fail.

How the cycle works →

01

Requirement

02

Technical invariant

03

Control

04

Failure condition

05

Test

06

Measurement

07

Pass or fail

08

Known limitation

What exists today

Every capability carries its status.

Evidence-span validation

Answers are checked against the exact source spans they cite.

Implemented + tested

Artifact-integrity fault containment

Corrupted artifacts blocked in a controlled internal experiment.

Internal experiment

Semantic inference checking

Does the evidence warrant the inference, not just the citation?

Passed internally — not yet in public repo · Phase 8

General AI safety

Specific properties under defined conditions only.

Not claimed

The full status page →

Flagship application — Scientific Claim Forensics

Does the evidence actually warrant the claim?

A source can be genuine, correctly quoted, and still not support the conclusion drawn from it. Pick a leap and see which rung the evidence reaches, and which one the claim stands on.

What the source shows

“A blood marker fell after eight weeks of use.”

What the claim says

“Improves your health outcomes.”

Asserted by the claim
Patients actually do better
Not established
The marker predicts outcomes for patients
Established by the source
A marker changed

The source supports the lowest rung. The claim sits on the top one. The missing step is: the marker predicts outcomes for patients, and nothing in this source shows it. A citation to this source does not close the gap.

Schematic examples. The wording is invented to show the shape of each inference gap; it is not drawn from a case file.

Internal experiment — not independent validation

What the first pilot showed, including what it did not.

24 / 24

No accuracy gain

All three conditions answered every question correctly. A ceiling effect: the pilot cannot show a benefit either way.

4 → 12

Of 12 corrupted artifacts blocked

Baseline blocked 4, the full control layer blocked all 12, and all 6 clean artifacts were accepted.

2 / 2

Wrong but valid outputs still passed

The controls check structure, not meaning. Semantic correctness is not shown, and general AI safety is not claimed.

Run the experiment →

Roadmap

A finite path to v1.0.

INSPEKTORIUM v1 is deliberately bounded. Everything past the final validation gate is a separate program — not an open-ended promise.

Now

Implemented + tested

Current foundation

Evidence binding, provenance and deterministic fingerprints.

Phase 8

Passed internally — not yet in public repo

Deep Forensics

Semantic and inferential integrity: does the evidence warrant the inference?

Phase 9

In progress

Disagreement & review

Independent second opinion and structured disagreement between reviewers.

Phase 10

Roadmap

Reporting & operational finish

A canonical audit trail and release-integrity workflow.

Gate

Planned

Final v1 validation gate

One consolidated validation before release.

v1.0

Release

The v1.0 release

The bounded release. Nothing follows it inside v1.

There is no Phase 11. Anything beyond v1.0 is v1.x, v2, or a separate research program.

Code & reproducibility

Two halves of the same work.

On GitHub

Code

Method

Tests

Reproducibility — the public v0.1 kernel

On this site

The research program

Explanation & Q&A

Experiments & evidence

Status & roadmap

github.com/LAKITALKS/Inspektorium

Not all internal research code is public yet. The public repository is the narrow v0.1 evidence-binding reference kernel — the starting point of the research, not the whole of it.

CONTACT

Research enquiries and methodological exchange.

For research enquiries, methodological exchange and institutional correspondence:

Please make contact before sending confidential or sensitive material.