LTREMATICA skills v3.3.0 IT Contact us
Software governance · a Claude Code plugin

Your teams build with AI. Now you can govern it.

AI agents already write production code in your organisation. What they cannot do is prove their work — to you, to an auditor, or to a regulator. This plugin makes AI-assisted delivery verifiable, EU compliance evidence automatic, and your engineering policy enforced — with every claim backed by evidence, starting with this page.

CRA Article 14 reporting obligations apply from 11 September 2026.

Three questions you will be asked
"Can we prove AI-written code was tested before it shipped?"
Yes A verification gate blocks any "done" claim until the tests have actually run — after the change, not before it.
"Are we ready for the CRA reporting deadline in September 2026?"
Answerable SBOM, vulnerability triage, incident-clock drafts and a gap report — regenerated from the codebase, not assembled the week before an audit.
"Are our engineering rules enforced, or just written down?"
Enforced Five gates run on every change. Where detection is exact they block; everywhere else they warn and say why.
13
Skills
3
Tracks
9
Ecosystems
1452
Automated checks
891
Blind judgements
Why now

Three liabilities. None of them announces itself.

Each one is silent until it is expensive. A production incident traced to unverified AI output, a regulator's information request, an audit finding — by the time any of them surfaces, the evidence you need either exists or it does not.

Delivery risk

AI output nobody verified.

An agent will report the work as done and the tests as passing — sincerely, and sometimes wrongly. Multiply that by every developer, every day. Without an enforced verification step, "done" means "the agent believes it", and that belief is what ships to production.

How delivery is assured →
Regulatory exposure

Deadlines with fines attached.

CRA vulnerability-reporting obligations begin 11 September 2026 for anyone shipping software into the EU, with fines up to €15 million or 2.5% of worldwide turnover. GDPR is already live. The AI Act is phasing in. The evidence these regimes demand is tedious to produce by hand — so it isn't produced, until it is suddenly urgent.

The regulatory clock →
Policy erosion

A rule nobody verifies is a preference.

Every change ships with a test. Migrations are reversible. Endpoints authorize. Your teams agreed to these — and they are checked, when at all, by whoever reviews the pull request and happens to remember. They do not fail loudly; they erode.

How policy is enforced →
The regulatory clock

The deadlines are not negotiable. The preparation is.

Five EU regimes now reach software directly. The dates below are fixed in law; the only variable is whether the evidence exists on the day someone asks for it.

2024-12-10
Cyber Resilience Act enters into force
The clock starts on everything below.
2025-06-28
European Accessibility Act applies
EAA/WCAG obligations are live for in-scope products. eaa-evidence covers the scan, the statement and the two thirds a scanner cannot reach.
2026-08-02
AI Act main obligations apply
Transparency duties and the high-risk regime are live. ai-act-evidence finds the AI system and checks the record exists — and deliberately never assigns a risk class, because that call is a legal one a named human must make.
2026-09-11
CRA Article 14 reporting obligations apply
An actively exploited vulnerability or a severe incident triggers a 24-hour early warning, a 72-hour notification and a final report. The two tracks anchor their final report on different events — the part teams get wrong under pressure — so cra-incident-reporting refuses to compute a deadline from the wrong anchor and reports it as pending instead.
2026-12-09
Revised Product Liability Directive — transposition deadline
Software is explicitly a product; liability arguments run on the release trail. pld-evidence keeps that trail — versions, safe use, withheld updates, substantial modification.
2027-12-11
Full CRA application
Annex I essential requirements, the technical file, the CE marking.

GDPR has no start date left to wait for. gdpr-evidence records what personal data a repository actually holds and the legal basis for each item — and then fails a build when a new personal-data column arrives without one.

Self-assessment · two minutes

Eight questions an auditor will ask you anyway.

Answer as things stand today, not as they should be. Nothing leaves this page: no form, no tracking — the count happens in your browser. And to be honest up front: eight answers are not an audit; they are the reason to run one.

Does every release have an SBOM regenerable from the code — not a six-month-old PDF?
Do dependency vulnerabilities get a documented triage, with dates and decisions?
In an incident, does a process — not a person under pressure — anchor the 24- and 72-hour deadlines to the right event?
Can you prove AI-written code was tested after its last change, not before it?
Do you know which personal data each repository holds, and on what legal basis?
Would your release traceability hold up against a product-liability claim?
Do your engineering rules block a non-compliant change — or comment on it afterwards?
Is a gap report on your regulatory position regenerable on demand, today?
The output, not the promise

The report you put in front of an auditor.

This is the real shape of /compliance-status output, on a sample repository. Only three outcomes exist — present, gap, not applicable — each with a pointer or a reason. "Looks fine" is not an outcome this tool produces, and every gap arrives already routed to the skill that closes it.

/compliance-status · sample repository · 2026-08-25
SBOM (CRA)
present
compliance/sbom/ · v2.4.1 · 2026-08-15
Vulnerability scan & triage
present
0 open · last scan 2026-08-20
Annex I gap report
gap
never generated → cra-evidence
Personal-data map (Art. 30)
gap
2 columns without a legal basis → gdpr-evidence
DPIA screenings
present
3 screenings · latest 2026-07-30
Data-subject rights
gap
export exists, erasure path missing → gdpr-evidence
Accessibility (EAA/WCAG)
not applic.
no frontend in this repository
CVD policy (Annex I Part II)
present
SECURITY.md · .well-known/security.txt
Incident record
present
no open Article 14 clock

The report always carries the two dates that make this urgent rather than theoretical: CRA Article 14 reporting obligations apply from 11 September 2026, and full CRA application arrives on 11 December 2027.

What you get

Thirteen skills, three tracks, one contract.

Installed once by your platform team, active in every repository. Each track answers one of the three liabilities above — and every output is evidence a third party can check, never a self-assessment.

Track 01 · Delivery assurance

Harness

Your AI tooling fails through invisibility — so it is audited and measured.
  • harness-auditInventories the ten surfaces a repository hands an agent. Present, gap or not applicable — the entry point.
  • claude-md-authoring · subagent-authoringThe agent's standing policy and its supporting cast, written as policy rather than folklore.
  • harness-eval · model-routingProves a capability actually fires — and puts a number on what each task should cost.
  • verification gateThe hook that blocks a "done" claim while the tests are stale. The one step that cannot be skipped.
For the CTO: your AI investment, measurable instead of anecdotal.
Track 02 · Regulatory evidence

Compliance

Compliance fails through friction — so the evidence is generated where the work happens.
  • cra-evidenceSBOM, release-to-release diff, vulnerability triage drafts, Annex I gap report.
  • gdpr-evidenceThe personal-data map, the legal basis per item, the Article 30 record rendered from it.
  • cra-incident-reportingThe Article 14 clock: 24h, 72h, final report. Drafts each one; submits nothing.
  • ai-act-evidence · pld-evidence · eaa-evidenceThe AI Act record, the product-liability release trail, the accessibility dossier.
  • adr-managementArchitectural decisions recorded when they are made, not reconstructed for the auditor.
For the board: the dossier exists before anyone asks for it.
Track 03 · Policy enforcement

Mandates

A mandate nobody verifies is a preference — so five gates run on every change.
  • tests-with-changeEvery change ships with a test. A fact about the diff — it blocks.
  • reversible-migrationsDatabase changes can be undone. An empty rollback blocks too: it reads as reversible and reverses nothing.
  • authz-coverageRequest handlers show authorization. A heuristic — it warns, and says so.
  • + two moreA well-formed change record, and a shipped migration nobody quietly edited afterwards.
For engineering leadership: the rules hold at 6pm on a Friday too.

What your teams actually see

No dashboard, no new tool to log into. The agent your developers already use simply refuses to declare victory without proof. Here it has just edited a source file and claimed the work is done — and the gate holds the claim until the test suite has run against the code as it now stands.

A gate that blocks on guesswork gets switched off within a week — and takes the checks that did work with it. So a check may only block where its detection is exact; everything else warns. That restraint is why this survives contact with a real engineering organisation.

claude — verification gate
$ composer test PASS 42 passed $ …agent edits app/Invoice.php… assistant: Done. Fixed the invoice bug. ⛔ BLOCKED — verification gate You claimed this work is done, but the tests are stale. Run the test suite and report the actual output: composer test $ composer test
Governance

Claude drafts. Humans approve. Nothing is ever "fine".

The contract that makes this safe to put in front of a regulator: the AI produces evidence and drafts, and accountability stays with named people. This is not a limitation we accepted — it is the design.

Accountability stays human

No artifact — ADR, SBOM, gap report, audit, regulatory filing — is ever marked Accepted, Compliant or Validated by Claude on its own initiative. Everything ships Proposed or Draft until a named person says otherwise.

Evidence, never assertion

Every report states one of exactly three outcomes per item — present, gap, or not applicable — each with a pointer or a rationale. "Looks good" is not an output this plugin produces; where it appears, it is a bug.

Nothing is filed automatically

Nothing here transmits to an authority, emails, or posts to a reporting platform. It writes the text and computes the clock. Submission is an organizational act performed by a named human, and every draft says so on its first line.

Not applicable is a real outcome

Where a question genuinely does not apply — a migration tool with no rollback step, a framework the gates cannot see — the report says so, and says why. A report that never says "not applicable" is a report that has started inventing findings to look useful.

A team cannot dress a bypass up as a pass

A repository can lower a gate's severity, never raise one — and a lowering is printed as a lowering. A team that switched a gate off must not be able to produce output that looks like a team that passed it. That property survives config edits by design.

Proof · the part most vendors skip

Every figure on this page is machine-verified.

A governance product that asserted its own quality would be its own counterexample. So this page is held to the same contract as everything else: 1452 automated checks across 23 suites run on every pull request, on two operating systems — and a script re-derives every number published here from its source and fails the build when a copy disagrees. It exists because we shipped three stale numbers in a single week.

$ scripts/run_suites.sh > results.tsv 1452 checks · 23 suites · gates, evidence scripts, the hook, the installers — all of it $ scripts/check_published_facts.py --suite-results results.tsv --site index.html OK: every published figure agrees with its source.
We audit our own product the way we audit yours

Whether each skill activates when it should is tested blind: 891 blind judgements so far — three independent judges per prompt, no tools, one pinned model. A 2-of-3 split is recorded as FLAKY and never rounded up: the disagreement is the finding.

And it caught us

One round found that the incident-reporting skill would not have engaged on "attackers got into our build server" — a textbook severe incident under the CRA. All three judges missed it, for the same documented reason. The fix was a few words; the point is that we found it by measurement, before a customer did.

Capacity claims get measured too

We claimed our own catalogue was near its ceiling — then noticed the claim was derived from nothing, and built the instrument instead: 600 selection judgements across 200 row-instances, four arms. Adding three skills cost zero routing regressions, twice. The claim died; the number replaced it.

The ledger keeps its failures

Every validation round is recorded, including the discarded ones and the rounds that found a real gap. The clean final state is the least informative part of that record, so it is not the only part we keep.

Honest about scale, too. Ten prompts per skill judged three ways is a smoke test for gross failures, not a benchmark — and the ledger says so itself. It has found real defects in material its authors had read carefully several times, which is the entire argument for running it at all.

Adoption

One decision, two commands, no new infrastructure.

This is a Claude Code plugin — it rides the tooling your developers already use. No server to run, no data leaving your repositories, no per-seat dashboard. Your platform team installs it; the skills, the gates and the verification hook are active from the next session.

Step 1 · A 30-minute call

Understand

You tell us how your teams use AI today and which regimes apply to you. No slides from our side: the call ends with the repository chosen for the pilot audit.

Step 2 · Pilot audit

Measure

The harness audit and the first /compliance-status run on one of your repositories. Out comes a real baseline: present, gap or not applicable — the same shape as the report above.

Step 3 · Decision

Decide on evidence

You decide on the gap report of your own code, not on a demo. If you proceed, installation is the two commands below — active from the next session.

$ claude plugin marketplace add <your-private-repository-url>
$ claude plugin install oltrematica-skills@oltrematica

Delivery is from a private repository dedicated to your contract: the URL is provided when the engagement starts. It is the same channel through which the 3.x releases have already shipped to our first customers in production.

Week one

Audit

Say "audit our harness" in any repository. Ten surfaces, each reported present, gap or not applicable — a baseline you can put in a steering-committee deck the same day.

Week two

Evidence

Run /compliance-status. The regulatory position — CRA, GDPR, AI Act, PLD, EAA — inventoried per repository, with each gap routed to the skill that closes it.

Ongoing

Enforcement

The gates run on every change, in CI if you wish. The verification hook holds every "done" claim to a fresh test run. From here on the evidence accumulates as a side effect of normal work.

Works with what you run
PHP Node Python Go Rust Ruby Java / Kotlin .NET Elixir

Nine ecosystems for test-command detection, and thirteen migration tools for the reversibility gate — including the two that have no rollback at all, which are reported as not applicable rather than as a gap. Proprietary licence; delivery is from a private per-customer repository. Talk to Oltrematica about an engagement.