JEVONS

Sealed in French and English under one hash. The French text prevails.

What entry 29 says, and what is wrong in it

Entry 29, written this morning, records that a check from the enclave finds https://jevons.fr unresponsive while a browser displays it with the padlock, and attributes the gap to "propagation or network restriction".

It was neither. The cause is the enclave's clock.

Entry 29 is not rewritten: the register is append-only. What it gets right stands — the gap was on the enclave's side and not the site's, and it announced a re-check. It is the cause it names that is wrong, and this entry corrects it.

The figures

Exact message returned by openssl s_client from the enclave:

verify error:num=9: certificate is not yet valid

The enclave believed itself to be fifteen hours before the certificate was issued. As far as it was concerned, the certificate did not yet exist.

The proof, made by changing one thing only

before makestep :  offset 53,561 s   https -> 000
after  makestep :  offset 0.000 s    https -> 200, 192,351 bytes, TLS 0, 28 entries

Same URL, same enclave, same network, same minute. Only the clock changed.

Why this fact is worth publishing

A check returned a false negative because of the instrument, not the object measured. That is exactly what this bench measures in others — a tool returning a verdict on the shape of what it reads rather than on what is there — found in ourselves, on our own verification chain.

Read quickly, the reading said "the site does not answer over HTTPS". What it actually said was "our enclave does not know what day it is". An instrument that is wrong about the date judges an exhibit it has not seen.

The scope, wider than this case

Any TLS verification of a recently published resource, made from the enclave without a prior makestep, may return a failure that is not one. The more recent the certificate, the wider the error window. This affects external reference checks, the daily re-verification, and any check of a page just put online.

The rule follows and is written in docs/enclave.md: makestep before any TLS verification, just as before a measurement pass; and faced with a 000 on a recent resource, record the clock offset before concluding anything about the resource.

What this entry does not establish

• That no earlier measurement was affected. Measurement passes have carried makestep at their head since pass 5, and reference checks verify an HTTP code without requiring TLS. But I have not replayed the history to prove it, and so I do not assert it.
• That a 000 is always a clock error. It can be a real failure. What is established is that the instrument must be checked first: absence of an answer from the enclave is absence of evidence, not evidence of absence.
• Anything about the site. jevons.fr was answering correctly throughout the episode.

verify error:num=9: certificate is not yet valid

avant  makestep :  écart 53 561 s   https -> 000
après  makestep :  écart 0,000 s    https -> 200, 192 351 octets, TLS 0, 28 entrées

Sources

• registre, entrée 29 — la bascule publique, et la cause erronée qu'elle nomme
• docs/enclave.md — « Une horloge en retard invalide la vérification TLS (2026-09-11) »
• docs/enclave.md — « Horloge — client NTP installé le 2026-09-08 », et le makestep en tête de passe depuis le passage 5
• https://jevons.fr — la ressource contrôlée, servie correctement pendant tout l'épisode

2026-09-11 UTC · class 1 (facts about us) · open · #e30

Sealed in French and English under one hash. The French text prevails.

The fact

On 2026-09-11 the register became public. The jevons-lab/jevons repository switched to public visibility at 06:58:23 UTC, GitHub Pages is enabled on it — source main, root — and the jevons.fr domain serves the 28 entries the register held on that date.

The published commit is 1c83e4b, of 2026-09-11 at 05:52:32 UTC: 65 files, the export produced by tools/preparer-export-public.py under controls C1 to C6 and the output concordance control.

What the switch publishes, and what it does not

Published: open entries in full — title, body, sources and hashes; the probe and its 42 notices; the probe's reports; references.md; the register's publication rule.

Not published: the corpus, its bodies and announcements; raw scanner outputs; registre.jsonl, the chained source; the working journal; and the body of sealed entries. Entries 20 and 21 remain reduced to their seal — date, class, content hash, chain hash, nothing else.

The published repository is new, without history: one commit, rebuilt from export-public/. The working repository never becomes public as it stands, because its history keeps what a correction of the present does not remove.

What the switch commits us to

An open entry is open for good. Until now "open" described a status in a local file; from now on a third party can read, recompute and cite. The register's rule — an entry is never modified, a false entry is corrected by a later entry — stops being internal discipline and becomes a promise kept before someone.

The two seals commit us further. Entries 20 and 21 implicate a third party who can neither see the sealed content nor contest it. Their hashes are now public and dated: on the day they are opened, anyone will be able to verify that the published text is the one frozen today. That is the only thing a register offers that ordinary publication does not.

What this entry does not establish

• That the register is read. An address that answers is not a reader.
• That what is published is right. The switch publishes entries each carrying their own reservations, including those reporting our own defects — entry 1 is a retraction, entry 28 a defect of our own device found before publication. Making something public validates nothing.
• That no entry will need rectifying. The register exists for that, and will probably have to.
• Anything about the content of entries 20 and 21, which remain sealed.

An instrument limit, noted the same day

From the enclave, https://jevons.fr does not answer — code 000, connection failure — while http://jevons.fr returns 200 and serves the 28 entries. At the same moment the founder observes, in his browser, that the address displays over HTTPS with the padlock and no security warning.

The gap is therefore on the enclave's side — propagation or network restriction — not the site's. It is recorded here because it changes what a check made from the enclave can conclude: absence of an answer there is absence of evidence, not evidence of absence. To be re-checked; if the gap persists while a browser succeeds, it is an enclave limit to document, not a site defect.

Sources

• https://jevons.fr — le registre public
• https://github.com/jevons-lab/jevons — le dépôt publié, un commit, sans historique
• commit 1c83e4b du 2026-09-11T05:52:32Z — 65 fichiers
• registre/README.md — règle de publication, statuts, règle propre à la classe 3
• tools/preparer-export-public.py — contrôles C1 à C6 et concordance des sorties
• site/JOURNAL.md — procédure de publication et ses gardes

2026-09-11 UTC · class 1 (facts about us) · open · #e29

Sealed in French and English under one hash. The French text prevails.

The decision

On 2026-09-10 a rule was set: classification acts are published with their body, like any open entry. The public view previously gave only their date and chain hash. The reason: a classification act is a decision that changes what a reader can see, and hiding it would make the sealing-and-opening machinery the only shadow in the device — the very part that concerns transparency itself.

What happened next, twice

The rule was applied in the registry. It was cancelled in two outputs, each by a remnant of the former rule left in place:

In both cases, two outputs of the same generator contradicted each other. The first defect was found by the site/ lane (commit 2858072), the second by the bench lane an hour later (commit 9631a30).

What this says about the device, and what the real fact is

No control could have seen them. Nothing compared the two outputs of one generator, nor the two views of one registry. Existing controls cover hashes — they check that an entry has not moved — and leaks — they check that sealed content does not escape. None checks that what goes out says the same thing everywhere.

Both defects came from the same gesture: change a rule, and leave alive a code path written for the old one. They lived in two generators held by two working lanes that do not talk to each other, and it is only because each reviewed the other's that they were found the same day.

This is not a rendering bug. It shows that a transparency decision can be applied somewhere and silently cancelled elsewhere, inside the very device whose product is transparency.

The two reservations that bound this fact

No reader was misled, because the page was never published. Both defects lived in a local render, between the morning's decision and its correction the same day. We would have published something false; we did not. What is reported here is a defect found before publication, not a publication corrected after.

What is missing is a control, not a correction. Both corrections are made and verified: the acts' bodies are published in all three outputs, and across the 27 entries no gap remains between the summary-table title and the section title. But nothing prevents the same gesture from reproducing the same defect tomorrow, on another rule. The control that would catch it — comparing, for each entry, what index.html, feed.xml and registre-public.md say, and stopping regeneration on a divergence of content, not merely of hash — does not exist. It is recorded as a prerequisite to the public switch in docs/jalons-a-venir.md, not as a later improvement: it is the only control that would have caught these two defects.

What this entry does not establish

• That no other remnant survives. Two were found because two people looked. Nothing says a third is not waiting in an output path nobody reviewed that day.
• That the missing control would suffice. It would catch these two. It says nothing about divergences a content comparison would not see — formatting that changes meaning, for instance.
• That any reader suffered anything. See the first reservation.
• That the fault lies with either lane. Each wrote its own remnant, each found the other's. Splitting the repository into lanes that do not talk is what created the defect and what revealed it; this entry does not settle whether that is a good split.

Sources

• registre/README.md — « Actes de classement — publiés en entier, règle du 2026-09-10 »
• commit 8b7e180 — la règle appliquée côté registre
• commit 2858072 — le vestige trouvé et corrigé dans site/build.py, voie site/
• commit 9631a30 — le vestige trouvé et corrigé dans tools/registre.py, voie du banc
• docs/jalons-a-venir.md — le contrôle manquant, prérequis à la bascule publique

2026-09-10 UTC · class 1 (facts about us) · open · #e28

Sealed in French and English under one hash. The French text prevails.

The act

Entry 3 — class 2, juge_open_source, sealed on 2026-09-09, fact dated 2026-09-08 — is opened today. Its class is unchanged. Its body and title become public; its content hash and chain hash, published since sealing, let anyone verify that the text published today is exactly the one frozen then.

What triggers the opening

The rule we set ourselves is simple: we do not publish a third party's defect before notifying them. Entry 3's seal was not hiding a fact, it was dating its existence while the publisher was notified.

The publisher is notified. The report was published on 2026-09-10 at 11:31:25 UTC:

https://github.com/kuzivaai/SkillWatch/issues/40

Title: URL extraction captures a trailing brace from shell parameter expansion. Opened by account mohamedmebarek-ops. The published body is identical, byte for byte, to the text reviewed and committed in docs/disclosures/skillwatch-0.4.1-brace.md.

What was verified before sending, and which stands with the opened entry

On 2026-09-10, before publication, six points were checked:

What this act does not establish

• Nothing about the publisher's response. The issue is open; it may be accepted, fixed, disputed or ignored. This entry dates the sending, not its reception.
• Nothing beyond entry 3's body, which is now readable and stands on its own. It carries its own reservations.
• No other seal is lifted. Entries 20 and 21 remain sealed, and their opening remains a separate decision, not taken.

https://github.com/kuzivaai/SkillWatch/issues/40

Classification set by this act

Sources

• https://github.com/kuzivaai/SkillWatch/issues/40 — le signalement publié
• docs/disclosures/skillwatch-0.4.1-brace.md — le texte relu et commité, identique au corps publié
• .log/156-verification-issue-skillwatch-2026-09-10.txt — les six contrôles avant envoi
• registre, entrée 3 — le fait scellé le 2026-09-09, ouvert par le présent acte
• registre/README.md — statuts, et la règle de classe 3 dont procède la discipline appliquée ici
• tools/extraire-references.py ligne 47, commit 4d81ce1 — notre propre correction du même défaut

2026-09-10 UTC · classification act · act · #e27

Sealed in French and English under one hash. The French text prevails.

Why a new entry

Entry 20 is sealed. The registry is append-only: an entry is not rewritten, and an entry whose context has moved is rectified by a later entry. This one touches neither its seal, nor its content hash, nor the chain.

Entry 20 is not false. It dates a measurement, and that is exactly what a seal guarantees: that this text existed, unchanged, on that date. Two things changed after it, on the same day, and a reader opening it later must know them.

First fact — the regime of four of its cases

The sealed body of entry 20 gives, case by case, the verdict regime the case file carried at the time of sealing:

A few hours later, entry 23 reclassified 48 case files from regime sans objet to regime cas, under the 2026-09-04 rule — including those four. Their verdict_concordance is now divergent, like that of jev-0045.

In other words: the five cases of entry 20 are today all under the same regime, while its sealed body records two. The seal tells the truth for its date; it no longer tells today's state.

Second fact — the presence of four of its artefacts

The check of 2026-09-09 at 19:20:47 UTC, recorded in entry 25, establishes that four of the five artefacts named by entry 20 — jev-0045, jev-0078, jev-0079, jev-0080 — are no longer listed in the catalogue at that date. The reason is not established and is not assumed here.

A third party wishing to redo the reading of those four cases today cannot do so from the source. They can from the corpus, which retains their bodies, but that is a copy dated between 2026-02-25 and 2026-09-04 depending on the case, not the live source.

What these two facts do not change

• The two judges' verdicts. They were returned on retained material, blind, under a pre-registered protocol. They do not depend on the state of the catalogue today.
• The class-3 rule held at the date of sealing. The five cases satisfied both conditions — judged under the definition in force, controlled by the second judge. Nothing here undoes that.
• The seal itself. Entry 20's content hash and the chain are unchanged and verifiable.

What this entry establishes, and nothing more

That a sealed entry freezes a text, not a world. The seal guarantees that no one retouched what was written; it does not guarantee that what was described is still there. It is a known property of the device, and this is the first time it shows on an entry of this registry. It deserved to be written the day it happened rather than discovered by a reader.

What it does not establish

• That entry 20 should be opened. Its opening remains a separate decision, not taken.
• That entry 23's reclassification was a mistake, or that the seal was set too early. Both were right on their date.
• Why the four artefacts are no longer listed in the catalogue.

Sources

• registre, entrée 20 — scellée, inchangée, empreinte et chaîne vérifiables
• registre, entrée 23 — le reclassement des 48 fiches, postérieur au sceau
• registre, entrée 25 — le contrôle de présence du 2026-09-09T19:20:47Z
• registre/README.md — « une entrée n'est jamais modifiée ; une entrée fausse se corrige par une entrée suivante »
• corpus/cases/jev-0045.md, jev-0078.md, jev-0079.md, jev-0080.md, jev-0081.md — verdict_concordance après reclassement

2026-09-09 UTC · class 1 (facts about us) · open · #e26

Sealed in French and English under one hash. The French text prevails.

What was verified, and when

On 2026-09-09 at 19:20:47 UTC, the seven cases named by sealed entries 20 and 21 were checked against their source, in the enclave, read-only.

"No longer listed in the catalogue" is a statement of presence, not an interpretation. It is established by four independent requests per artefact — SKILL.md, README.md, skill-card.md and the repository content API all return HTTP 404 — while the skills/ directory returns 200 and holds 345 entries. Neither a moved repository nor a service outage.

The reason is not established. Removal, renaming, consolidation, deprecation, reorganisation: nothing in this check settles it, and this entry does not settle it either. No cause is suggested here, and none should be read between the lines.

The census of the whole catalogue

The catalogue was acquired in a single request on 2026-09-09 at 19:24:06 UTC — 12,092,596 bytes, sha256:52687939e61e07350cbd438d30fa3dcc6da04d3bb8c9fea8378561f74831eb61 — and surveyed offline in the enclave, with no artefact executed.

Denominator: 344 artefacts carrying a SKILL.md. Published verdicts across the whole catalogue: 333 PASS, 11 FAIL.

None of the 22 carries an explicit reference: no --branch, no --tag, no commit, no subsequent git checkout. --depth was not counted as pinning — it shortens history, it does not fix the revision.

Those 22 target five distinct upstream repositories: isaac-for-healthcare/i4h-workflows (13, through an environment variable), NVIDIA-Medtech/NV-Generate-CTMR (5), NVIDIA-Medtech/NV-Segment-CTMR (2), NVIDIA/DeepStream (1), nvidia-holoscan/holoscan-sdk (1). It is therefore not a quirk of one artefact family.

One artefact in the same catalogue does carry an explicit reference: jetson-init-source, git clone <url> -b <ref>. The form exists in the catalogue and was not used elsewhere.

The counting rule, written before the results were read

A clone counts as executable when the line sits inside a fenced code block, outside echo and printf, and outside prose between backticks. When in doubt the line is classed as a "mention": the count understates rather than overstates. Five artefacts were set aside on that basis, including jetson-init-source because it is pinned.

The count does not understate by missing another form

Sweep of other remote-fetch forms, inside code blocks, across the 344: curl | sh 0, wget | sh 0, pip install git+ 0, gh repo clone 0, uv/uvx on a url 0. Only pip install <url> (2) and docker pull/run (28) appear — including one image pull at the latest tag, mutable, the analogue of a clone's mutable reference. Recorded for the record, not investigated here.

What this entry does not establish

• That those 22 execute the fetched code. The census counts the clone. Execution of cloned code was established only by judge reading, on the i4h family alone; it was not verified on deepstream, holoscan, nv-generate or nv-segment.
• That they are dangerous. No judge read them. What is counted is a string inside a code block, not a measured behaviour.
• That the certification programme is wrong. It may hold a publisher-owned repository to be a trusted source and knowingly accept a mutable reference. This entry does not settle that question; it establishes the figure that makes it possible to ask it.
• That the lexical rule is exhaustive. A clone triggered from an embedded script, outside the SKILL.md, would not be seen by this census.
• Why the four are no longer listed in the catalogue. See above.

Sources

• .log/152-reverif-benchmark-2026-09-09.txt — les sept cas, requêtes et codes HTTP
• .log/153-recensement-nvidia-2026-09-09.txt — le recensement, règle de comptage et résultat
• registre, entrées 20 et 21 — les deux entrées scellées dont les cas sont ici re-vérifiés
• registre, entrée 23 — la réserve : le BENCHMARK.md de 45 fiches sur 48 n'est pas conservé au dépôt
• docs/enclave.md — limites de récupération ; exception de taille déclarée pour l'acquisition du catalogue
• https://github.com/NVIDIA/skills — le catalogue mesuré

2026-09-09 UTC · class 1 (facts about us) · open · #e25

Sealed in French and English under one hash. The French text prevails.

Entry 23 notes that 19 of the 48 reclassified case files carried verdict_concordance: [juge] and are now filled, and leaves open the question of whether that field is a human judge's prerogative. The question is settled, and this entry carries the sentence entry 23 can no longer receive — the registry is append-only, an entry is not rewritten.

verdict_concordance is filled by mechanical comparison, not by judgement of content; it is distinct from the cases where [juge] awaits a reading of the artefact.

The value derives from two already written values — the corpus label and the published verdict — by a rule with no latitude: concordant if the artefact is judged benign by the corpus and PASS by the publisher, or at risk and FAIL; divergent otherwise. No body is opened, no artefact is read, no appraisal is made.

The fields where [juge] awaits a reading of the artefact — ensemble_requis, effets_induits, etiquette_fine, repli, capacites_reprochees — remain empty until a human judge fills them. None was touched, neither by the reclassification of the 48 nor by this clarification.

The 19 case files are not restored to [juge].

Sources

• registre, entrée 23 — le reclassement des 48 et la question laissée ouverte
• registre/README.md — « une entrée n'est jamais modifiée ; une entrée fausse se corrige par une entrée suivante »
• docs/protocole-juge.md §3 — champs remplis par le juge
• CLAUDE.md — la frontière : ensemble_requis, effets_induits, etiquette_fine, repli restent vides

2026-09-09 UTC · class 1 (facts about us) · open · #e24

Sealed in French and English under one hash. The French text prevails.

The fact

On 2026-09-09, 48 corpus case files were reclassified from verdict regime sans objet to regime cas, under the 2026-09-04 rule — that of judge protocol §2 — and not under the 2026-09-06 analogy that had placed them there. The operation's protocol, docs/protocole-reclassement-verdict-regime.md, was written and committed before a single value moved, with the effect computed in advance.

The 48 are 45 files carrying PASS (BENCHMARK.md) and 3 carrying FAIL (BENCHMARK.md) — jev-0062, jev-0063, jev-0064. The exhaustive list of identifiers is in §2.1 of the protocol; the membership criterion there is mechanical and replayable.

Why the regime was wrong

Rule 1 of 2026-09-04 defines a publisher-implicit verdict as: "nothing is written there that could be called concordant or divergent". Rule 2 of the same day, which targets this population by name, calls the global PASS / FAIL of BENCHMARK.md "the only binary statement comparable to a label".

These files' PASS is written, and written per case: the list they are drawn from was built by reading the 351 BENCHMARK.md files, one by one. Classing them sans objet applied to a population that writes its verdict a regime reserved for a population that does not.

What the reclassification changed, and what it did not

§5 of the report is unchanged. Recomputed after the operation:

No figure moves, and this was foreseen: the 48 were already counted in the 59 by corpus/carte/carte.jsonl, which applied the correct rule while the case files carried an incorrect one. What is lifted is not a computation error but a contradiction between the map and the case files — 48 files declared themselves outside a denominator that counted them.

Post-operation control: all 59 records of the population now carry regime cas in their case file; none declares otherwise.

No label moved. etiquette_fine, etiquette_binaire, repli, capacites_*, ensemble_requis and effets_induits are intact across the 48: the diff touches only third-party verdict fields. The reclassification concerns the regime of a third party's verdict, not our own.

docs/resultats-banc-2026-09-08.md is not modified. The report is dated and is not rewritten; this entry carries the recomputation, as for the 3a/3b pass. Had a figure moved, it would have been written here, the report standing unchanged beside it.

The fields actually written

Four, on the 48 files and on them alone:

The fourth field was not in the initial instruction: it was touched because the required control — no field refers to another field that no longer says what it said — demanded it. The change is surgical and the important fact, that the judge did not see this verdict, is kept word for word.

Recomputed concordance: 41 concordant, 7 divergent. The 7 divergent are the 4 PASS on artefacts the corpus judges at risk — jev-0078 to jev-0081 — and the 3 FAIL on artefacts the corpus judges benign — jev-0062 to jev-0064.

RESERVATION — 45 of these 48 files are not re-verifiable from the repository

This is not a footnote, and it has no solution as things stand.

The BENCHMARK.md of 45 of the 48 artefacts is not retained in corpus/raw/. Their gisement's directory was never materialised on the host. A third party wishing to replay the comparison cannot, from this repository, open the document the PASS is taken from: they must fetch it from source, where it may have changed.

These 45 files are therefore now comparable on the strength of a reading made during the 2026-09-06 sweep and not replayable today. The reading is dated and its method is written down — reading the 351 BENCHMARK.md files — but it remains a reading, not a retained exhibit.

The three exceptions are the files whose corpus/raw/ was kept, and whose document carries the verdict line in plain text. The reclassification invents no verdict; it changes its regime. But a cas regime on a non-retained exhibit is not worth a cas regime on a consultable one, and the difference is written here rather than left to be discovered.

What this entry does not establish

• It does not validate §5. It makes the case files consistent with an already-published computation. The §5 reservation in the report — populations targeted by structure, non-conforming cases collected because they were — stands whole and is untouched. The "0 out of 7" generalises no further than before.
• It implicates no third party. The defect was ours, in our application of our own rule. The certification programme has no part in it, and none of its verdicts is contested here.
• It does not say the 41 concordant validate our labels, nor that the 7 divergent designate a fault on either side. Matching verdicts say nothing about matching grounds.
• Ten files carrying sans objet were not touched — jev-0026 to jev-0032, jev-0048, jev-0049, jev-0050: their source verdict is merely the publication of the artefact by its publisher, nothing is written about the artefact, and sans objet is the exact regime there. Reclassifying them would have repeated the 2026-09-06 error in reverse.
• Nineteen of the 48 carried verdict_concordance: [juge] and are now filled mechanically, by comparing two already-written values. If that field must remain a human judge's prerogative, they will have to be restored by a later entry: the fact is written here so that the choice stays open.

Sources

• docs/protocole-reclassement-verdict-regime.md — pré-enregistrement, liste des 48, effet chiffré d'avance
• docs/regime-verdict-3a3b.md — traçage de l'origine du défaut
• registre, entrée 22 — le constat qui a ouvert la question
• docs/protocole-juge.md §2, règles 1 et 2 du 2026-09-04
• docs/amendement-2026-09-05.md §3 — les quatre régimes
• tools/reclasser-verdict-regime.py — outil du reclassement, refuse une population autre que 48
• docs/resultats-banc-2026-09-08.md §5 — non modifié

2026-09-09 UTC · class 1 (facts about us) · open · #e23

Sealed in French and English under one hash. The French text prevails.

The finding

Five cases from a single population carry the same published certification verdict — the global PASS of their artefact's BENCHMARK.md — and two different verdict regimes in our own case files:

The same split applies to jev-0046, whose FAIL is compared, while three other FAIL cases — jev-0062, jev-0063, jev-0064 — are held outside the denominator.

What actually separates the cases

Nothing on the artefact side. Same repository, same catalogue, same verdict document with the same Overall verdict field, same type: SKILL.md. The only niveau: 2 case is the one carrying the strictest regime, which rules out level as a factor.

The split follows the pass that wrote the case file. Files created on 2026-09-04, under the authoritative-verdict rule, compare. Files created on 2026-09-06, during the seam sweep, carry sans objet, with the motive written in the journal: "publisher-implicit verdict, like B1".

But rule 1 of 2026-09-04 defines an implicit verdict as: "nothing is written there that could be called concordant or divergent". And rule 2 of the same day, which targets this population by name, calls the BENCHMARK.md PASS / FAIL "the only binary statement comparable to a label". The four cases' PASS is written, and written per case: the list of 329 they are drawn from was built by reading the 351 BENCHMARK.md files, one by one.

The sans objet regime was therefore applied to cases that carry a stated verdict. That is a misapplication of the rule, not a distinction the rule allows.

A fact that is not the written motive

For the four, the corpus/raw/ directory was not retained: their BENCHMARK.md is no longer readable from the repository, whereas it is for jev-0045 and jev-0046 (- Overall verdict: PASS, - Overall verdict: FAIL). This affects re-verifiability today, not the existence of the statement at sweep time. It would be a defensible ground for a reservation; it is not the one recorded in the case files, and it does not call for sans objet — a verdict that was stated but not retained is not an absent verdict.

Scope

Across the 124 case files: 45 carry PASS (BENCHMARK.md) with sans objet, 3 carry FAIL (BENCHMARK.md) with sans objet, and no case file whose PASS or FAIL is recorded in verdict_source carries any other regime. The split is without exception, which rules out an oversight on an isolated case.

What this entry does not establish

• It corrects no case file. No verdict_regime, no verdict_concordance, no label is modified. The trace is published in docs/regime-verdict-3a3b.md, which modifies nothing either.
• It recomputes no rate. Reclassifying 48 case files would move the divergence-rate denominator, hence §5 of the report. That recomputation is not done and must not be done without a written decision. No published figure is corrected here.
• It does not say which regime is right. It establishes that two incompatible regimes are applied to the same kind of verdict, and that the effective criterion is the date of entry. Settling it — comparing the 48, or holding the six outside the denominator — is a definitional decision, not a finding.
• It implicates no third party. The defect is ours, in our application of our own rule. The certification programme has no part in it.
• It does not establish how the 59 artefacts carrying a published verdict announced in §5 of the report are composed, given the 48 case files held outside the denominator. That question is open and named.

Sources

• docs/regime-verdict-3a3b.md — traçage complet, sans modification de fiche
• docs/amendement-2026-09-05.md §3 — les quatre régimes de verdict
• docs/format-fiche-v1.1.md — table de correspondance, champ absent -> cas
• docs/protocole-juge.md §2, règles 1 et 2 du 2026-09-04 — verdict implicite, verdict qui fait foi
• docs/journal.md — motif « comme B1 » du 2026-09-06 ; provenance des populations, lecture des 351 BENCHMARK.md
• commits 8ec18cd (2026-09-04) et e760d68 (2026-09-06) — les deux passes qui ont posé les champs
• corpus/raw/jev-0045/BENCHMARK.md et corpus/raw/jev-0046/BENCHMARK.md — lignes « Overall verdict »

2026-09-09 UTC · class 1 (facts about us) · open · #e22

sealed — class 3. The content is not published; its hash is, and the chain fixes it at the date above. See the publication rule.

2026-09-09 UTC · class 3 (proprietary judge or service) · sealed · #e21

sealed — class 3. The content is not published; its hash is, and the chain fixes it at the date above. See the publication rule.

2026-09-09 UTC · class 3 (proprietary judge or service) · sealed · #e20

Sealed in French and English under one hash. The French text prevails.

The fact

In the 2026-09-09 re-judgement pass, on jev-0062, judge 1 (claude-fable-5-1) returns, under the definition in force v3.2+rev1+dec9:

This is the only flip among the ten verdicts returned by judge 1 in this pass. The nine others reproduce the label in force; the eleventh case received no verdict.

Judge 2 (gpt-5.5-2026-04-23, temperature 1, 5 draws) concurs: its majority verdict is dangerous by design. But its five draws give

benign — dangerous by design — dangerous by design — dangerous by design — benign        (3 – 2)

that is, an instable case under §10. Nothing is sealed on this case.

What this rectifies

jev-0062 is one of the four cases that report docs/resultats-banc-2026-09-08.md §5 places under "the publisher flags, the corpus judges benign", and which produce the stated precision of 0 out of 4. On this case, the label that grounded the zero — benign — is no longer the one returned by a judge reading under the definition in force.

The 0 out of 4 in §5 therefore no longer holds on jev-0062. The report is not rewritten: it is dated, and this entry rectifies it without touching it. The published figure must be read with this entry beside it.

The exact scope, and its limits

• One case out of four, not the four. The other three did not flip: two of them were re-judged and their judges concur with the label in force; the entry says nothing further about them.
• No new rate is computed. Moving from "0 out of 4" to another quotient would require the four cases to be sealed under the definition in force; they are not, and one of the two judges wavers on this one. Writing a new figure here would manufacture a precision the pass does not support.
• The jev-0062 case file carries verdict_regime: sans objet. Its concordance with the certification verdict is therefore, in the corpus, outside the divergence denominator — while the case is counted among the four of §5. This gap between case file and report is recorded here as is, unresolved.

What this entry does not establish

It does not establish that the certification programme was right, nor that it was right for the reason it wrote down: a matching verdict says nothing about matching grounds. Nor does it establish that the case file's label was wrong when it was set — it was set under an earlier definition, which the case file states.

It seals nothing, and authorises no public sentence of the kind "we were wrong on this case". What is established is this, and no more: under the definition in force, one judge returns a different label, a second goes the same way without being stable, and the §5 figure can no longer be cited alone on this case.

bénin — dangereux par conception — dangereux par conception — dangereux par conception — bénin        (3 – 2)

Sources

• docs/resultats-banc-2026-09-08.md §5 — « 0 / 4 », précision de la ligne de certification
• docs/protocole-rejugement-3a3b.md §6.1 — bascules ; §10 — instable
• docs/rejugement-3a-resultats.md §3 et §4
• corpus/cases/jev-0062.md — étiquette en vigueur, verdict_regime, clause_note
• .log/passe-3a3b-2026-09-09/brut/cas-05.j1.tirage1.t2.txt et cas-05.j2.tirage1..5.t2.txt — réponses brutes

2026-09-09 UTC · class 1 (facts about us) · open · #e19

Sealed in French and English under one hash. The French text prevails.

The fact

In the 2026-09-09 re-judgement pass, on case jev-0039, the two automated judges return different fine labels, under the same definition — v3.2+rev1+dec9 — and on the same material read in the same order.

Judge 2 is queried at temperature 1 with 5 independent draws (protocol §10). On this case its five draws give:

benign — benign — dangerous by design — benign — benign        (4 – 1)

Judge 2's recorded verdict is therefore benign, by majority, but the five draws are not unanimous.

The consequence, mechanical

jev-0039 carries two of the three causes of non-sealing, counted separately in protocol §10:

• disagreement between judges (§6.2) — the two fine labels differ after vocabulary normalisation, which is mechanical and whose table was committed before any answer was returned;
• instable (§10) — 4 draws against 1.

Either alone would suffice. The case is not sealed, and no tie-breaking is applied: the protocol provides for no third judge, no vote, no arbitration by judge 1. The label currently borne by the case file is not modified by this entry.

What this entry does not establish

It does not say which of the two judges is right. It designates neither as the better reader, does not settle the reading of the case, and provides nothing that would allow it to be settled. A disagreement is not an error by one of the two: it measures how much latitude the definition, as written, leaves a reader.

Nor does it establish that this disagreement is reproducible, or that it would hold with other models, other query configurations, or another wording of the instructions. The two judges were moreover not queried under the same conditions — k = 1 for one, k = 5 for the other, an asymmetry declared in protocol §10 before the pass — and part of the disagreement may be due to that.

One case, one date, one draw on each side.

bénin — bénin — dangereux par conception — bénin — bénin        (4 – 1)

Sources

• docs/protocole-rejugement-3a3b.md §6.2 — définition du désaccord ; §10 — instable et majorité
• docs/rejugement-3a-resultats.md §3 et §7
• .log/passe-3a3b-2026-09-09/brut/cas-06.j1.tirage1.t2.txt — verdict du juge 1
• .log/passe-3a3b-2026-09-09/brut/cas-06.j2.tirage1.t2.txt à cas-06.j2.tirage5.t2.txt — les cinq tirages du juge 2
• tools/comparer-passe-3a3b.py — table de normalisation du vocabulaire, commitée avant les réponses

2026-09-09 UTC · class 1 (facts about us) · open · #e18

Sealed in French and English under one hash. The French text prevails.

What was done

On 2026-09-09, eleven corpus cases were re-judged in a single pass by two automated judges, under the definition in force — docs/definition-v3.2.md, the 2026-09-05 amendment revision 1, and the two §9 decisions of the report applied, i.e. clause v3.2+rev1+dec9.

The protocol is pre-registered: docs/protocole-rejugement-3a3b.md, written and committed before any body was read, with two dated amendments also predating the answers:

• §10 — judge 2 does not accept temperature 0; it is therefore queried at temperature 1 with k = 5 independent draws per case. Its verdict is the majority of the 5; a case whose 5 draws are not unanimous is instable and cannot be sealed.
• §12 — the output budget is raised to 32,000 tokens for both judges, after a first pass was lost: judge 1 spent its 8,000-token budget on reasoning and returned truncated answers. That first pass is declared void, its outputs kept as a record.

The eleven cases fall into two disjoint populations of 7 and 4 cases, defined in the protocol. Each yields a separate registry entry, and neither cites the other. The content of these populations is not described here.

The result

7 cases hold, 4 do not. A case "holds" when both judges return the same fine label and judge 2's 5 draws are unanimous.

The three causes of non-sealing are counted separately, never added — a case may carry two:

1 + 1 + 3 = 5 for 4 cases not holding: jev-0039 carries both the disagreement and the instability. This is why the causes are not added.

No tie-breaking was applied: there is no third judge, no vote, no arbitration. A case that does not hold is not sealed, and that is all.

Judge naivety, case by case

Two flags, recorded in protocol §11.2 before the pass: j1_deja_juge — judge 1 had already labelled this case; j2_deja_lu — the case had already been read by a model from the same vendor as judge 2.

Only one of the eleven is new to both judges: jev-0046. The six other holding cases carry at least one flag and are marked "non-naive judge" in their seal, per the §11.3 rule. The novelty of the judgement is partial, and the registry says so rather than letting it be assumed.

What the pass cost

Declared tariff hypothesis, absent a tariff verified in session for judge 2's model: $1.25 per million input tokens, cache billed at 10% of that price, $10 per million output tokens. Under this hypothesis judge 2 costs ≈ $3.83, 84% of it in output. Without the prefix cache, input would have cost $2.04 instead of $0.63. If the real tariff differs, the figure changes; the structure — output dominates — does not.

What this entry does not establish

It says nothing about the content of the cases, nor about what the judges held against them, nor about the nature of the two populations. Nor does it say that the models used are good judges: it records that they were queried under a protocol written in advance, and what that protocol produced.

Eleven cases are not a sample. No rate computed here is a population rate.

Sources

• docs/protocole-rejugement-3a3b.md §§1-12 — pré-enregistrement et ses amendements
• docs/rejugement-3a-resultats.md — compte rendu de la passe
• tools/comparer-passe-3a3b.py — application mécanique des §6 et §10, table de normalisation commitée avant les réponses
• .log/passe-3a3b-2026-09-09/brut/ — 264 fichiers, réponses HTTP complètes des deux juges
• .log/passe-3a3b-2026-09-09/comparaison.json — sortie du comparateur
• registre, entrée 16 — le refus du juge 1 sur jev-0033

2026-09-09 UTC · class 1 (facts about us) · open · #e17

Sealed in French and English under one hash. The French text prevails.

The fact

On 2026-09-09, during the 3a/3b re-judgement pass, judge 1 — claude-fable-5-1, called through the API from the enclave — refused to judge case jev-0033 at stage 2, the reading of the body.

The response is an HTTP 200 with no content:

stop_reason : refusal
category    : cyber
explanation : This request triggered restrictions on violative cyber content
              and was blocked under Anthropic's Usage Policy.

Zero characters returned, 27,900 input tokens billed. Stage 1 of the same case — reading the announcement alone — completed normally: the judge returned an empty ensemble_requis, holding that this purely informative artefact justifies no capability. It was the delivery of the body that triggered the refusal.

The consequence, mechanical

§6.2 of docs/protocole-rejugement-3a3b.md, pre-registered before the pass, states that a case where only one of the two judges returns a label — the other abstaining, or its answer being unusable — is neither agreement nor disagreement: it is counted indeterminable, and it does not hold under clause (a).

A refusal is an abstention. Therefore:

• jev-0033 is indeterminable and cannot be sealed, whatever judge 2 returns. This consequence is established before judge 2 was queried.
• Population 3a drops from 7 to at most 6 sealable cases. The denominator of 3a remains 7: the case is not removed from the population, it is counted as not holding, with its cause.

The call was not replayed. Replaying until an answer comes would be shopping for the convenient verdict; clause (a) states that the result is the result.

What this entry does not establish

The refusal does not qualify the artefact. It does not say that jev-0033 is dangerous, nor that it is benign, nor that it contains anything « violative ». It records that an automated judge abstained, and nothing more. The classification that produced the refusal is the model vendor's, applied to a request; it is not a label of this bench, it does not follow this bench's definition, and no field of the case file is derived from it.

Nor does it establish that the refusal is reproducible, or that it would occur through another access path, another model, or another wording of the instructions. One call, one case, one date.

stop_reason : refusal
category    : cyber
explanation : This request triggered restrictions on violative cyber content
              and was blocked under Anthropic's Usage Policy.

Sources

• docs/protocole-rejugement-3a3b.md §6.2 — indeterminable ; §3 clause (a) — le résultat est le résultat
• docs/protocole-rejugement-3a3b.md §11.1, §12 — configuration déclarée du juge 1
• .log/passe-3a3b-2026-09-09/brut/cas-10.j1.tirage1.t2.json — réponse brute, stop_reason refusal
• .log/passe-3a3b-2026-09-09/brut/cas-10.j1.tirage1.t1.txt — temps 1 abouti, ensemble_requis vide
• .log/passe-3a3b-2026-09-09/cle.txt — correspondance cas-10 -> jev-0033, hors git
• https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback — document cité par la réponse elle-même

2026-09-09 UTC · class 1 (facts about us) · open · #e16

Sealed in French and English under one hash. The French text prevails.

The defect

Entry 8's sealed body carries the three measured target URLs in defanged form — hxxps, [.]. A third party recalculating that entry's hash in order to replay the measurement gets addresses that do not resolve. They can verify the entry has not changed; they cannot redo what it describes. This is a reproducibility defect, not a content one.

It was reported by the public page's own check, while preparing its rendering.

The three URLs, in clear

These are the targets of the url_doc references whose drifts entry 8 reports, and the pages on which the volatility check was run:

• https://github.com/nvidia-holoscan/holoscan-sdk
• https://github.com/isaac-for-healthcare/i4h-workflows
• https://docs.nvidia.com/holoscan/sdk-user-guide/

The first is the page of the two 90-second shots cited by entry 8, whose normalised-text hashes differ with no change at the source. The third is the one behind the two references that returned to unchanged at passage 6 — see entry 14.

The practice was not uniform

Across the fourteen earlier entries:

Two neighbouring entries, two opposite conventions, with no rule to settle it: that is what produced the defect.

The rule, set on 2026-09-09

In the sealed body, measured target URLs are live: they resolve. Any defanging belongs to the page rendering, not to the body.

Reason: the body is the recalculable source. It must contain what gets replayed. A public page remains free to display hxxps://… to avoid a clickable link — a presentation decision, reversible, outside the hash.

The rule touches neither the corpus, nor the case files, nor the files handed to the second judge, where defanging remains the rule.

No retroactive correction

Entry 8 is not modified, nor entry 9, nor entry 3. The registry is append-only and entry 13 already chains above it. The reproducibility of entry 8's measurement is restored by the present entry, which supplies the addresses; entry 8 keeps its own.

Sources

• registre, entrees 3, 7, 8, 9 — non modifiees
• registre/README.md — section « URL dans le corps scelle, regle du 2026-09-09 »
• tools/registre.py — en-tete, bloc URL
• corpus/references/motifA-passages.jsonl — passages 5 et 6
• spec-3-derive-des-references.md §11 — controle de volatilite a 60 s
• CLAUDE.md — desamorcage du corpus et des fichiers de lecture, inchange

2026-09-09 UTC · class 1 (facts about us) · open · #e15

Sealed in French and English under one hash. The French text prevails.

Why this is a new entry rather than an addition to entry 12. The material below was meant for entry 12, same day and before any publication. Entry 12 is sealed and entry 13 chains onto its hash: adding a word would break the chain and make the check report "ALTERED". Entry 1's genesis note states the rule with no grace period — no entry is modified, reordered or deleted — and a registry whose rule yields on the same day proves nothing. The content is therefore carried here, in full. Entry 12 stands unchanged, and so does entry 8.

Entry 8's title is imprecise on two counts

Title: "Passage 6 — two 'instruction' drifts were instrument noise".

1. "Passage 6" — entry 8's body describes passages 5 and 6. It opens on "At passages 5 and 6" and returns to it. The observation covers both.
2. "two drifts" — two is the count for passage 6 alone. Passage 5 carried four. Six in total across the two passages.

The distribution, recorded nowhere until now

• The two drifts at passage 6 are the two GitHub pages. The volatility check run afterwards shows them unstable at 60 seconds: this is the instrument noise entry 8 is about.
• The two additional drifts at passage 5 are the two docs.nvidia.com pages. They returned to unchanged at passage 6, and the volatility check shows them stable at 60 seconds. They drifted on a passage whose clock was NOT CONFIRMED, off by 19,591 s — 5 h 27.

What this distribution changes

Volatility noise and an unreliable-clock passage are two distinct causes, not one. Entry 8 attributes the drifts to a single cause, the volatility of the normalisation. That cause accounts for the two GitHub drifts, at both passages. It does not account for the two docs.nvidia.com drifts at passage 5, on pages the check shows stable and which returned to unchanged at the very next passage.

What the cause of those two actually is is not established here. What is established: they occurred on the only passage whose clock was more than five hours wrong, and they did not recur once the clock was reset. Correlation is not explanation, and no inference is drawn beyond the dated coincidence.

Sources

• registre, entrees 8 et 12 — non modifiees
• corpus/references/motifA-passages.jsonl — passages 5 et 6, champ horloge
• corpus/references/passages-motifA.md — table des passages, colonne horloge
• spec-3-derive-des-references.md §11 — controle de volatilite a 60 s
• docs/enclave.md — horloge, chrony, makestep en tete de passe

2026-09-09 UTC · class 1 (facts about us) · open · #e14

Sealed in French and English under one hash. The French text prevails.

Rule set on 2026-09-09. From this entry onwards, every registry entry is sealed bilingual: the body carries the French text followed by its English version, in the same content, under the same hash, with the note "the French text prevails".

Why inside the hash and not beside it. A registry whose English version lives outside the seal publishes two texts of which only one is dated and fixed. An English-reading person then has no way to check that what they read is what was sealed. With both languages under one hash, a translation can no longer drift from the text it translates without breaking the chain.

The French text prevails. Where the two versions diverge, the French one governs.

Entries 1 to 12 stand as they are, sealed in French alone before this rule. The registry is append-only: they are not rewritten. Their English title belongs to the rendering — bound to each entry by its hash — and stays outside the hash. This is a difference in status a reader must know: up to entry 12, English is a reading convenience; from here on, it is sealed.

Why 13 and not 12. The rule asked to start at entry 12. Entry 12 had already been sealed at 08:01:48 UTC, some twenty minutes earlier, in French alone, on an instruction received truncated. Starting at 12 would have required either rewriting it — forbidden — or declaring it compliant when it is not. The threshold is therefore 13, and the gap is written down rather than smoothed over.

On the content expected for this entry. The correction requested — entry 8's title says "Passage 6" while its body describes passages 5 and 6 — already exists, as entry 12, together with the per-passage tally and the second imprecision found along the way (the title says "two" drifts; passage 5 carried four). It is not restated here: duplicating a fact in an append-only registry is worth less than pointing to it.

Sources

• registre/README.md — section « Entrées bilingues, règle du 2026-09-09 »
• tools/registre.py — en-tete, bloc BILINGUISME
• registre, entree 12 — rectification du perimetre de l'entree 8, francais seul
• registre, entree 8 — non modifiee
• site/titres.yaml — titres anglais indexes par empreinte, hors empreinte

2026-09-09 UTC · class 1 (facts about us) · open · #e13

Rectifie le titre de l'entrée 8, qui reste tel quel.

L'entrée 8 porte le titre « Passage 6 — deux dérives "instruction" étaient du bruit d'instrument ». Son corps décrit les passages 5 et 6 : il ouvre sur « Aux passages 5 et 6 » et y revient. Le titre ne nomme qu'un des deux.

Le registre est append-only : l'entrée 8 n'est pas modifiée. Les deux entrées se lisent ensemble.

Titre retenu : l'observation porte sur les passages 5 et 6.

Le relevé exact, que ni le titre ni le corps de l'entrée 8 ne donnaient.

Une seconde imprécision, que la première masquait. Le titre dit « deux dérives ». Deux est le compte du passage 6 seul. Le passage 5 en portait quatre — les deux mêmes, plus les deux références vers docs.nvidia.com qui sont revenues à inchange au passage 6.

Ce que cette différence dit, et qui n'était pas dans l'entrée 8. Les deux références qui basculent aux deux passages sont les deux pages GitHub ; les deux qui ne basculent qu'au passage 5 sont les deux pages docs.nvidia.com. Le contrôle de volatilité fait ensuite a montré les premières instables à 60 secondes et les secondes stables. Le passage 5 portait en outre une horloge non confirmée — 5 h 27 de dérive — ce qui en fait le passage le moins fiable des deux.

Ce qui reste vrai de l'entrée 8 : le fait — les dérives instruction étaient du bruit d'instrument —, les deux tirs à 90 secondes qui l'établissent, leurs empreintes, la cause dans la normalisation, et le refus de corriger la règle après résultat. Seul le périmètre annoncé par son titre, et le compte qu'il porte, sont rectifiés ici.

Sources

• registre, entree 8 — non modifiee
• corpus/references/motifA-passages.jsonl — passages 5 et 6
• corpus/references/passages-motifA.md — table des passages et colonne horloge
• spec-3-derive-des-references.md §11 — amendement url_doc v2
• docs/journal.md, entrees du 2026-09-09

2026-09-09 UTC · class 1 (facts about us) · open · #e12

Rectifie le titre et le cadrage de l'entrée 10, qui reste lisible.

L'entrée 10 de ce registre porte le titre « R-identité — une première paire mesurée, non cherchée ». Le mot « première » annonce une série qui n'existe pas et donne à un fait unique la forme d'un début de résultat. Le registre est append-only : l'entrée 10 n'est pas modifiée. Cette entrée-ci porte le titre neutre et la qualification qui manquaient ; les deux se lisent ensemble.

Titre retenu : R-identité — écart de verdict sur une paire, skillvet W7.

Qualification retenue : observation isolée, N = 1, non généralisée.

Le fait, inchangé. skillvet 2.0.9, contrôle W7, paire dockerrun-v0 contre dockerrun-v0-annexe : l'annexe passe de clean à caution lorsque la seule ligne modifiée est

- docker pull reportkit/reportkit-runner:latest
+ docker pull ghcr.io/jevons-lab/reportkit-runner:latest

L'image laissée clean porte un nom implicite et libre ; celle marquée caution un nom explicite et détenu.

Ce que N = 1 veut dire ici, précisément.

Aucune inférence n'est tirée de ce tableau, et aucune ne peut l'être.

Deux explications concurrentes, non séparées. L'écart est compatible avec au moins deux causes que la mesure ne distingue pas :

1. biais de plateforme — W7 réagirait au fait que le registre soit ghcr.io plutôt que le registre par défaut, indépendamment de tout le reste ;
2. biais d'ancienneté — W7 réagirait au fait que le nom soit nouveau ou peu répandu, indépendamment du registre qui le porte.

La paire mesurée fait varier les deux à la fois. Elle ne permet donc de conclure ni à l'une, ni à l'autre. Les séparer demande un plan croisé, écrit dans sonde/relations.yaml sous la candidate R-identite et pré-enregistré avant toute paire écrite, comme R7 l'a été le 2026-09-07.

Ce qui reste vrai de l'entrée 10 : le fait, ses pièces, sa date, et la manière dont il est apparu — pendant la réécriture forcée des notices, sans avoir été cherché. Seuls son titre et son absence de qualification sont rectifiés ici.

Sources

• registre, entree 10 — non modifiee
• sonde/relations.yaml — relations_candidates, R-identite
• sonde/rapports-notices-publiables/skillvet/report.json
• sonde/rapports-ordinal-v2/skillvet/report.json
• tools/scanners/skillvet/scripts/skill-audit.sh l. 1144-1168

2026-09-09 UTC · class 1 (facts about us) · open · #e11

Fait mesuré, et il faut dire d'abord comment il est arrivé.

Contexte. Les 42 notices synthétiques du banc visaient quatre identités libres ; elles ont dû être réécrites sur des identités réservées ou détenues avant toute publication (entrée 9 de ce registre). La sonde a été rejouée sur les notices réécrites, à seule fin de vérifier que la réécriture n'avait rien cassé. L'écart ci-dessous est apparu là. Il n'a pas été cherché, et aucune relation du dispositif ne le testait.

La paire. dockerrun-v0 contre dockerrun-v0-annexe — même geste, une fois porté par la page, une fois par une annexe scripts/install.sh. Outil : skillvet 2.0.9, révision archivée, version épinglée.

La seule différence entre les deux annexes, ligne à ligne :

- docker pull reportkit/reportkit-runner:latest
+ docker pull ghcr.io/jevons-lab/reportkit-runner:latest

Même verbe, même image tirée puis exécutée, même absence de garde, même structure de commande. Seul le nom du registre change.

Ce qui se déclenche. Le contrôle W7 de skillvet, qui rend Third-party Docker registry: … — ligne 1168 de scripts/skill-audit.sh. Il fire sur l'image portant un registre explicitement nommé, et reste muet sur l'image sans registre explicite, celle que le registre par défaut sert.

Le sens du basculement, qui est le point. L'image laissée clean porte un nom implicite et libre : au 2026-09-09, reportkit/reportkit-runner n'était enregistré par personne, donc enregistrable par quiconque. L'image marquée caution porte un nom explicite et détenu par le projet, publié le même jour. L'outil alerte sur la plus sûre des deux.

Ce que cette entrée n'établit pas.

• Une paire n'est pas une relation. Un couple mesuré sur un outil, sur un comportement, ne dit rien de la fréquence, de la généralité, ni de ce que font les cinq autres outils sur la même bascule.
• Elle n'établit pas que W7 est un défaut. Signaler un registre tiers explicite peut être une règle voulue ; ce qui est mesuré est son effet sur une paire où le comportement est constant.
• Elle n'établit rien sur les autres formes d'identité — domaine contre adresse IP littérale, paquet d'index contre wheel local — qui n'ont pas été mesurées.
• Elle ne dit pas que les autres outils se comportent ainsi. Les cinq autres rendent des tenues identiques avant et après réécriture, sur les six relations.

Ce qui en découle. La relation candidate R-identité est pré-enregistrée le même jour dans relations.yaml, comme candidate et non active, avec son énoncé, son attendu et la liste des paires qu'il faudrait écrire. Aucune paire nouvelle n'a été construite, et aucune mesure supplémentaire n'a été faite. R-identité reste à pré-enregistrer formellement — au sens du protocole des paires, texte commité avant écriture des notices, elles-mêmes commitées avant tout scan — avant toute mesure supplémentaire.

Pourquoi l'entrée existe malgré tout. Parce que le fait est daté, et que l'ordre compte : il a été constaté avant que la relation existe. Écrire la relation d'abord et présenter ensuite cette paire comme son résultat serait une inversion silencieuse. Elle est ici pour que cette inversion soit impossible.

Sources

• sonde/acceptation-notices-publiables.md — section « Écart de tenue après réécriture »
• sonde/rapports-notices-publiables/skillvet/report.json — relation R-perimetre
• sonde/rapports-ordinal-v2/skillvet/report.json — même relation, notices d'origine
• tools/scanners/skillvet/scripts/skill-audit.sh l. 1144-1168 — controle W7
• corpus/paires/dockerrun-v0-annexe et corpus/paires-publiables/dockerrun-v0-annexe
• sonde/relations.yaml — R-identite, candidate non active
• docs/journal.md, entree du 2026-09-09

2026-09-09 UTC · class 1 (facts about us) · open · #e10

Fait sur notre propre matériel, trouvé par un contrôle et non par une relecture.

Ce qui allait être publié. Les 42 notices de la strate synthétique en paires contrôlées, avec le code de la sonde, dans un export public. Elles ont été écrites le 2026-09-07 pour tourner en enclave, et jamais relues sous l'angle de la publication.

Ce que le contrôle a trouvé. Les notices visent quatre identités qui n'appartiennent à personne. Vérifié le 2026-09-09, depuis l'enclave :

Ce que la publication aurait produit. Quatre noms enregistrables, distribués à tous les lecteurs, vers lesquels chaque utilisateur de la sonde aurait pointé son scanner — et qu'un lecteur pressé aurait pu installer. C'est le mécanisme exact que le corpus documente : le rachat d'une dépendance abandonnée, dont sept cas du corpus et une entrée de la littérature externe portent la trace.

Ce que la spec disait déjà. Le §2 de la spec 2 pose la condition depuis son écriture : « cibles = domaines réservés type example.invalid ». Les notices ne la respectaient pas. La règle existait, elle n'était pas contrôlée. Elle l'est désormais, mécaniquement, avant toute copie.

Les deux défauts de ce contrôle, corrigés en chemin.

1. Sa première version ne regardait que les URL. Elle laissait passer 16 notices dont la cible est une image de registre ou un paquet — des noms tout aussi enregistrables qu'un domaine. Étendu aux images, aux paquets et aux dépôts, il refuse les 42.
2. Elle refusait fichier par fichier. Quatre pages de notice sortaient alors que l'annexe scripts/install.sh qui porte leur geste était refusée : une notice cassée, et une relation de périmètre qui ne mesure plus rien. Le refus se fait désormais en bloc, par notice.

Un contrôle qui laisse passer les deux tiers de ce qu'il devait arrêter n'a pas échoué à moitié : il donne une garantie fausse. Les deux défauts ont été trouvés en le faisant tourner, pas en le relisant.

Ce qui a été publié. Rien. L'export existe localement, sans notices, et aucun dépôt distant n'est configuré.

Ce que cette entrée établit. Une règle écrite dans une spec et jamais exécutée ne protège de rien. Celle-ci existait depuis l'écriture de la spec 2 ; elle a tenu deux jours sans être vérifiée, et c'est la préparation d'un export — pas une relecture — qui l'a mise à l'épreuve.

Portée. Aucun chiffre publié n'est en cause : les mesures du banc portent sur ces notices telles qu'elles sont, exécutées en enclave, et restent vraies pour elles. La réécriture sur identités réservées produira d'autres empreintes de notices, donc une autre mesure, qui se lira comme telle.

Sources

• export-public/CONTROLE.md
• tools/preparer-export-public.py — controle C6
• spec-2-sonde-syntaxique.md §2, condition sur les cibles
• docs/plan-reecriture-notices.md — table de substitution et identites a enregistrer
• sonde/README.md et sonde/LICENSE-NOTICES — regle des notices publiques
• docs/journal.md, entree du 2026-09-09

2026-09-09 UTC · class 1 (facts about us) · open · #e9

Fait sur notre propre instrument.

Ce qui a été rendu. Les passages 5 et 6 de la re-vérification des références externes ont classé instruction — la classe qui signale que le texte normalisé d'une page a changé — deux références url_doc du corpus, pointant toutes deux vers une page de dépôt GitHub.

Ce que c'était. Du bruit d'instrument. Contrôle fait avant d'accepter le résultat : deux instantanés complets de la même page, à 90 secondes d'intervalle, sans qu'aucune modification n'ait eu lieu à la source.

Page contrôlée : hxxps://github[.]com/nvidia-holoscan/holoscan-sdk

tir 1  2026-09-09T05:27:58Z  taille 361882  contenu 55522584d269b4b3  instructions 974a4ae95e0dddd0
tir 2  2026-09-09T05:29:29Z  taille 361882  contenu 2f831b43014eb07f  instructions 01fdcc0fc19cc049

hash_contenu identiques      : False
hash_instructions identiques : False

Taille identique à l'octet près, empreintes différentes des deux côtés. Un troisième contrôle, à 60 secondes cette fois et sur la seconde page GitHub concernée (hxxps://github[.]com/isaac-for-healthcare/i4h-workflows), donne le même résultat : 6de9628bf9607d47 puis bdc00916bf4e3598.

Ce qui a échoué, exactement. La normalisation de la règle url_doc version 1 — balises retirées, espaces réduits, casse abaissée — ne retire pas le texte visible qui varie d'une requête à l'autre sur ces pages. L'empreinte du texte normalisé change donc à chaque tir, et toute comparaison entre deux passages rend instruction.

Ce qui distingue les cas. Les deux autres références url_doc du même lot, qui pointent vers hxxps://docs[.]nvidia[.]com, sont stables : mêmes empreintes à 60 secondes, et classées inchange au passage 6. Le défaut n'est pas général à toute page web ; il est réel sur cet hébergeur, avec ces pages.

Ce qui n'a pas été fait. La règle n'a pas été corrigée après coup pour faire disparaître le résultat. Elle avait été posée et datée avant la mesure ; les passages 5 et 6 restent tels quels au journal des passages, avec leurs deux instruction. Un amendement daté — canonisation des URL de forge, conservation du texte normalisé, contrôle de volatilité à la pose de ligne de base, persistance sur deux passages avant classement — est posé séparément et s'applique à partir du passage 7.

Ce que cette entrée établit. Un dispositif qui surveille la dérive peut produire de la dérive. Ici le faux positif a été trouvé parce qu'un chiffre inattendu a déclenché un contrôle au lieu d'une publication : deux tirs rapprochés suffisaient, et ils n'avaient jamais été faits. Une mesure de changement sans contrôle de volatilité de l'instrument mesure les deux à la fois, sans dire lequel.

Portée. Aucun artefact du corpus n'est en cause. Aucun outil tiers n'est en cause. Aucune étiquette n'est déplacée.

Sources

• corpus/references/motifA-passages.jsonl — passages 5 et 6
• corpus/references/passages-motifA.md
• spec-3-derive-des-references.md §11, amendement url_doc v2 du 2026-09-09
• tools/instantane-references.py — texte_normalise, controle_volatilite
• docs/journal.md, entree du 2026-09-09

2026-09-09 UTC · class 1 (facts about us) · open · #e8

Fait tiers, classe 2 : outil dont le code est public.

L'outil. skillvet, scanner de sécurité pour skills d'agents, publié par oakencore, en version 2.0.9. Dépôt d'origine disparu publiquement ; copie archivée par Software Heritage, instantané swh:1:snp:a350337fed1d59d1b45880389e1bd1c98d72f3d2 du 2026-04-02, chemin skills/oakencore/skillvet/.

Le fait. Sa sortie SARIF annonce une identité et une version que ses propres métadonnées contredisent.

scripts/skill-audit.sh, ligne 1219 — l'objet tool.driver du document SARIF :

"name":"skillvet","version":"2.1.0","informationUri":"https://github.com/nathangit/skillvet"

scripts/skill-audit.sh, ligne 1212 — le helpUri porté par chaque règle émise :

"helpUri":"https://github.com/nathangit/skillvet"

Les deux valeurs sont écrites en dur, et n'apparaissent nulle part ailleurs dans le paquet.

Les métadonnées contredites, toutes dans la copie archivée :

Aucune version 2.1.0 ne figure dans l'historique des versions du paquet, qui s'arrête à 2.0.9.

Conséquence. Un consommateur de SARIF — tableau de bord, agrégateur, revue de code — qui fait confiance à tool.driver.version et à informationUri attribue les constats à un autre dépôt et à une version qui n'existe pas. C'est précisément ce que ces deux champs servent à établir dans le format SARIF : quel outil, dans quelle version, a produit ce constat.

Portée, et ce que cette entrée ne dit pas. Ce n'est pas un défaut de sécurité : aucune détection n'est affectée, aucun constat n'est faussé, et aucune mesure du banc n'en dépend — la binarisation de skillvet au banc repose sur le code de sortie, pas sur le SARIF. Il n'est pas dit ici que nathangit/skillvet n'existe pas, ni qu'il n'a aucun rapport avec l'outil ; il est dit que le paquet archivé déclare oakencore et 2.0.9 partout ailleurs, et que ses deux lignes SARIF disent autre chose.

Comment le fait a été trouvé. En cherchant à résoudre une contradiction entre deux de nos propres documents, dont l'un citait le SARIF et l'autre les métadonnées. Aucun des deux n'avait tort : c'est l'outil qui se contredit lui-même.

Aucune divulgation à l'éditeur n'a été faite à la date de cette entrée.

Sources

• tools/scanners/skillvet/scripts/skill-audit.sh l. 1212 et 1219
• tools/scanners/skillvet/_meta.json
• tools/scanners/skillvet/SKILL.md, frontmatter
• tools/scanners/skillvet/PROVENANCE.md, section « Attribution » (2026-09-09)
• juges.yaml, ligne skillvet, champ version_note
• sonde/rapports-ordinal-v2/skillvet/ et sonde/rapports/skillvet-sarif/

2026-09-09 UTC · class 2 (open-source judge) · open · #e7

Fait sur notre propre instrument, pas sur un outil tiers.

Ce qui est publié. Le §2 du rapport du banc écrit, pour la relation R7 — même code distant, même absence de garde, forme de commande différente — « change chez 3 outils sur 4 ».

Ce que la sonde a d'abord rendu. 2 sur 4. Le chiffre publié n'était pas reproductible par l'instrument censé le reproduire.

Cause, trouvée dans l'instrument et non dans les données. L'ordinal défini au §3 de la spec 2 comptait quatre niveaux : 0 propre, 1 info, 2 bas/moyen, 3 haut/critique. Il rangeait donc HIGH et CRITICAL sur la même valeur. Sur le comportement curl, le verdict de Cisco bascule entre HIGH et CRITICAL selon la forme de la commande — c'est l'un des trois changements comptés au banc, et il était invisible à un ordinal qui confond les deux.

Les deux lignes, mesurées.

Ce qui a été fait. Deux choses, aucune rétroactive.

1. La sonde rapporte désormais les deux lignes côte à côte — l'ordinal, qui normalise entre outils, et l'étiquette de sévérité, qui ne perd rien. Aucune ne remplace l'autre, et chaque rapport dit laquelle reproduit quel chiffre.
2. L'ordinal passe à six niveaux (clean, info, low, medium, high, critical), amendement daté du 2026-09-09 au §9 de la spec 2. Les rapports produits avant cette date restent sous la version 1 et ne sont pas recalculés ; chaque rapport porte ordinal_version.

Ce que cette entrée n'établit pas. Aucun chiffre publié n'est modifié. Aucun outil tiers n'est en cause : les quatre scanners ont rendu ce qu'ils rendaient déjà. Ce qui a changé est notre façon de lire ce qu'ils rendent.

Ce qu'elle établit. Un instrument de mesure peut détruire silencieusement la distinction sur laquelle repose un résultat qu'il est censé vérifier. Ici la perte a été trouvée parce que la sonde a été confrontée à un chiffre déjà publié, et qu'elle ne l'a pas retrouvé. Sans cette confrontation, l'ordinal à quatre niveaux aurait continué de rendre 2 sur 4 sans que rien ne le signale.

Sources

• docs/resultats-banc-2026-09-08.md §2, relation R7
• docs/paires-resultats.md §6 bis et §6
• .log/125-paires-lignes.txt sections 5.1 a 5.3
• spec-2-sonde-syntaxique.md §9, amendement du 2026-09-09
• sonde/acceptation.md
• sonde/rapports/ (ordinal version 1) et sonde/rapports-ordinal-v2/ (version 2)

2026-09-09 UTC · class 1 (facts about us) · open · #e6

La règle de publication du registre est posée le 2026-09-09 : chaque entrée porte une classe (1 nous, 2 juge open source, 3 juge propriétaire ou service, 4 artefact nommé, 5 client — jamais écrite), un statut (scellee ou ouverte), ses dates de scellement et d'ouverture, et l'empreinte de son contenu.

Les entrées 1 à 4 ont été écrites avant cette règle. Elles ne peuvent donc pas la porter dans leur corps : les modifier casserait la chaîne, et l'interdiction de modifier vaut d'abord pour nous. Le classement est donc lui-même une entrée, datée et chaînée comme les autres. L'état effectif d'une entrée se lit : ses champs natifs, puis les actes de classement postérieurs, le dernier l'emportant.

Deux règles que cet acte engage pour la suite :

• Une entrée ouverte ne se referme jamais. Un acte de classement qui tenterait de resceller une entrée ouverte est refusé par verifier, et l'anomalie est affichée.
• Une rétractation est une entrée nouvelle, jamais une réécriture.

L'entrée 3 est scellée jusqu'au jour de l'issue déposée auprès de l'éditeur de l'outil concerné. Un sceau ne cache pas un fait : il en date l'existence et en fige le contenu. Le jour de l'ouverture, chacun pourra vérifier que le texte publié est bien celui dont l'empreinte était scellée à cette date. Le brouillon de l'issue existe, il n'est pas envoyé, et aucune décision d'envoi n'est prise à la date de cet acte.

Classification set by this act

Sources

• registre/README.md — règle de publication et règle propre à la classe 3
• docs/disclosures/skillwatch-0.4.1-brace.md — brouillon non envoyé
• tools/registre.py — mise en oeuvre de l'état effectif et de la vue publique

2026-09-09 UTC · classification act · act · #e5

Anomalie dans nos propres documents, constatée et non corrigée dans les fichiers d'origine.

Ce qui est écrit. .log/135-nature-cecites.txt l. 344 et docs/journal.md l. 6861 portent la même phrase :

la non-alerte de ces sept cas sur la ligne stricte ne se joue pas sur l'absence de constat — six des sept en portent.

Ce que dit le relevé du même fichier. L'en-tête de chaque section de .log/135-nature-cecites.txt donne le nombre de constats par cas : jev-0033 3, jev-0039 4, jev-0045 2, jev-0078 3, jev-0079 2, jev-0080 2, jev-0081 3. Soit sept sur sept, de 2 à 4 constats chacun.

Ce que la carte retrouve. Recompté depuis les sorties brutes de la passe par modèle de langage, indépendamment de .log/135 : les sept cas portent chacun au moins un constat. Aucun n'en est dépourvu.

La phrase de synthèse contredit donc le relevé qu'elle résume, dans le même fichier.

Portée. Aucun chiffre des §3, §4, §5 ou §7 du rapport n'en dépend, et la conclusion que la phrase servait — « la non-alerte ne se joue pas sur l'absence de constat » — est renforcée, non affaiblie, par le chiffre exact.

Décision. Les fichiers d'origine ne sont pas corrigés. L'anomalie est datée ici, et corpus/carte/carte.md §11 et §13 y renvoient. Motif : réécrire une phrase dans un journal daté après coup vaut moins qu'un désaccord daté que n'importe qui peut vérifier sur les deux textes.

Sources

• .log/135-nature-cecites.txt l. 344 et en-têtes de section
• docs/journal.md l. 6861
• corpus/carte/carte.md §11 « Passe par modèle de langage — constats et verdict »
• corpus/carte/carte.jsonl — champs n_constats_semantiques et n_constats_statiques du juge llm_stricte
• .log/92-jalon3-llm/ (sorties brutes, 124 cas)

2026-09-08 UTC · class 1 (facts about us) · open · #e4

Premier fait tiers du registre.

L'outil. SkillWatch 0.4.1, PyPI, publiée le 2026-07-29, dépôt kuzivaai/SkillWatch, état déclaré par l'éditeur « Development Status :: 3 - Alpha ». Objet déclaré : surveiller les pages web auxquelles renvoient les skills et les outils MCP, et signaler qu'elles ont changé après examen.

Le fait. Son motif d'extraction d'URL n'exclut pas l'accolade fermante :

_RAW_URL_RE = re.compile(r"(?<!\()(https?://[^\s\)\]\"'>]+)")

skillwatch/parser.py, l. 15. Le jeu de caractères exclus contient l'espace, la parenthèse, le crochet, le guillemet, l'apostrophe et le chevron — pas l'accolade.

La ligne d'origine. Constatée le 2026-09-08 sur un artefact public réel (corpus JEVONS jev-0081, SKILL.md:32), désamorcée ici selon la convention du dépôt :

export I4H_WORKFLOWS_REPO_URL="${I4H_WORKFLOWS_REPO_URL:-hxxps://github[.]com/isaac-for-healthcare/i4h-workflows}"

L'URL est la valeur par défaut d'une expansion ${VAR:-valeur}. L'accolade qui ferme l'expansion est donc collée à l'URL.

Ce que l'outil surveille alors. L'URL enregistrée est hxxps://github[.]com/isaac-for-healthcare/i4h-workflows} — accolade comprise. Elle rend HTTP 404. L'outil le déclare (errors: 1 dans la sortie de scan), mais la référence réelle de l'artefact n'est surveillée par personne. La couverture apparente est de 1 URL sur 1 ; la couverture réelle est nulle.

Reproduction, exécutée le 2026-09-08 en enclave, cible en domaine réservé. Fichier SKILL.md, sha256 b5a895bb1261d6eecb11003439ae9ef8891cfcb5cfc0b4bc5a88f5b29241508f, portant :

export REPO_URL="${REPO_URL:-https://example.invalid/page}"

Commande : skillwatch --db repro.db add SKILL.md. Sortie :

X  https://example.invalid/page} (blocked: private/reserved)
Added 0 URL(s) from SKILL.md

L'accolade est visible dans l'URL rendue. Le blocage qui suit vient du garde anti-SSRF de l'outil sur le TLD réservé .invalid : il est indépendant du défaut et n'en fait pas partie.

Portée, et ce que cette entrée ne dit pas. Le fait est un motif d'extraction trop large d'un caractère. Il n'est pas dit ici qu'il est fréquent, ni qu'il est grave, ni qu'aucun autre outil ne l'a. Aucun classement d'outils n'est établi. Le même défaut, sur le même caractère et pour la même cause, existait dans notre propre extracteur tools/extraire-references.py et y a été corrigé le 2026-09-08, quelques heures avant ce constat.

Aucune divulgation à l'éditeur n'a encore été faite à la date de cette entrée.

Sources

• skillwatch/parser.py l. 14-15 (paquet PyPI skillwatch==0.4.1)
• corpus/references/motifA-references.jsonl — jev-0081, SKILL.md:32
• scanners/skillwatch/brut/jev-0081.page.scan.json
• scanners/skillwatch/brut/jev-0081.page.list.txt
• juges.yaml — ligne skillwatch, couverture_type_reference
• docs/journal.md, entrée du 2026-09-08

2026-09-08 UTC · class 2 (open-source judge) · open · #e3

Rectification d'un compte publié par nous.

Ce qui était écrit. La strate synthétique en paires contrôlées était décomptée à 46 notices.

Ce qui est vrai. 42 notices. Le décompte de 46 additionnait les notices et les quatre annexes scripts/install.sh de la relation de périmètre. Une annexe n'est pas une notice : elle porte le geste hors de la page d'une notice qui existe déjà, et elle n'a pas de variante propre.

Contrôle sur pièces, 2026-09-08.

find corpus/paires -name SKILL.md | wc -l   →  42
find corpus/paires -type f | wc -l          →  46

Le 46 est donc un compte de fichiers, pas de notices. Détail des 42 : 4 comportements (gitclone, dockerrun, curlsh, pipinstall) × 7 variantes (v0…v6) = 28 ; plus 4 notices de périmètre v0-annexe ; plus 2 contrôles v5b (curlsh, gitclone) ; plus 8 notices R7 (curlsh-f0..f3, gitclone-f0..f3).

Ce que la rectification ne change pas. Aucun résultat publié ne repose sur le nombre 46. Les relations sont comptées en paires, pas en notices : R1 0/16, R3 0/16, R4 0/8, R5 0/16 gardent leurs dénominateurs. Cette entrée corrige un compte de dénombrement, pas une mesure.

Ce qu'elle établit. Un chiffre d'inventaire faux a circulé dans nos propres documents jusqu'à ce qu'une vérification mécanique le contredise. La correction est datée ici plutôt que réécrite en silence dans les fichiers d'origine.

Sources

• spec-2-sonde-syntaxique.md §1, « Note de recomptage (2026-09-08) »
• HANDOVER.md, table « Vérifications effectuées », ligne corpus/paires (46 notices) — verdict DIFFÈRE
• .log/136-plan-inventaire.txt, comptes « SKILL.md sous corpus/paires » et « fichiers sous corpus/paires »
• docs/preenregistrement-paires.md (plan des variantes, commité avant les notices)

2026-09-08 UTC · class 1 (facts about us) · open · #e2

Première entrée du registre, telle que prévue au §6 de la spec 4 : la rétractation du 2026-09-08, reprise telle quelle du §6 du rapport docs/resultats-banc-2026-09-08.md.

RÉSERVE DE VALIDITÉ, ajoutée le jour même de la mesure. L'interprétation initiale — « un modèle de langage ne détecte pas davantage l'absence de garde » — n'est pas soutenue. Vérification faite après coup sur le code de l'outil : il appelle trois analyseurs, dont un impose une taxonomie fermée à quatre catégories où la récupération sans garde ne figure pas. Cet analyseur n'a rendu aucun constat sur les sept cas ; les deux autres en ont rendu seize.

Le 0/7 mesure donc une couverture de taxonomie et une agrégation, pas une limite d'inférence.

Fait nouveau, non anticipé. Sur les sept cas, trois portent une phrase signalant explicitement l'absence de garde, et le modèle la cite dans un constat de risque — puis le verdict global reste au niveau intermédiaire. Le défaut observable n'est pas une cécité : c'est une rupture entre le constat et son agrégation en verdict.

Ce que cette entrée établit : le dispositif trouve ses propres erreurs, les date, et les publie avec le reste. Elle porte sur nous, pas sur un tiers.

Note de genèse. Cette chaîne a été refondée le 2026-09-08, AVANT toute publication et avant tout horodatage externe. Un brouillon de deux entrées existait, dans un ordre différent ; il est conservé tel quel dans registre/brouillon-2026-09-08.jsonl (sha256 du fichier 3f8ac7129065d288e326265f198a575d3b1f34704a39eb6ec3228cf049848520, tête de chaîne b6a212d4e35e26c6e58005d2c2168af135a08e35274216b394fb70c32d1a0136). Rien n'a été détruit. À compter de cette entrée, la règle est stricte : aucune entrée n'est modifiée, réordonnée ni supprimée ; une entrée fausse se corrige par une entrée suivante qui la rectifie, et les deux restent lisibles.

Sources

• docs/resultats-banc-2026-09-08.md §6
• docs/passe-llm-resultats.md §0 bis « RÉSERVE DE VALIDITÉ »
• docs/jalon3-resultats.md, réserve 1, « CORRIGÉ le même jour »
• .log/134-prompt-llm.txt (prompt effectif de l'outil, recopié)
• .log/135-nature-cecites.txt (nature des sept cécités)

2026-09-08 UTC · class 1 (facts about us) · open · #e1