Re: Conformance cases for mid-task halts

Hi Tymofii, Abisheak, all,

Thank you, Tymofii. I read both links before replying.

Principles 4, 5 and 6 are the reason I can say yes to this without hedging.
Principle 4 asks a verification to state what was checked, who checked it,
what the evidence supports and what it does not, and whether the checked
party could forge or suppress what the conclusion rests on. That is the same
question my own work asks, in the same order. Principle 5 keeps a claim at
its layer; principle 6 keeps attribution attached. These are the three I
have been arguing for in this CG for weeks. It is unusual to find them
written down by another project, in that order.

Two things in this thread need the record to be exact, so I will do them
here rather than in a later thread.

First, the TSC seat. In 2026Nov/0036 I accepted the initial TSC seat, on
the understanding I set out there. That acceptance stands. What it is not yet
is an LFDT position: by 0047's own account the LFDT proposal goes in only
once the TSC is locked, and acceptance is LFDT's decision under its project
lifecycle, not ours. When someone reads this archive in a year, the sentence
should read "initial TSC seat of the proposed TSC". Nothing in the work
changes. It just keeps the sentence true on the day it is checked.

Second, representation. PRINCIPLES 7 says silence, past collaboration
and continued technical participation never count as consent. SHARED-DECISIONS
says a change that alters how a shared file describes a project needs that
project's explicit confirmation, and that silence is not confirmation. I
agree with both, and I would rather be bound by them than by goodwill. So: I
speak for myself and for the artifacts I maintain. I do not claim to speak
for other NTI contributors, and I am not asking anyone to speak for me. I
will post my own four-part answer on #177 under my own account. If a row, a
map or a list ever names me or my work, I will confirm it myself on the pull
request — not because I distrust anyone, but because that is the rule working
as designed.

On joining the federation itself: I am not against it. But joining is a
project's own opt-in under your rules, not a statement made on a project's
behalf, so I will record mine where the rules say it goes. I would rather
each of us say it than have it said for us — a map gets stronger when each
node speaks for itself, not weaker.

On introducing the architecture. Anything already published as bytes is
fair to describe and to check: the transition-contract mirror at 83d88a70
(27,477 bytes, commit 0b9303a) and the fixture corpus behind it. What I would
keep out of any introduction is what has not been published — positioning,
commercial intent, roadmap items that are not in a public issue. That is
principle 5 read literally. A claim about a tool is not a claim about an
organization, and neither should outrun its bytes.

One thing I can contribute that is not another pilot.

Principle 4's "could the checked party forge or suppress this" is
machine-checkable, and I have been building it that way. For each MUST-FAIL
criterion in a verifier, I make the smallest repair that should flip it and
require it to flip. A criterion that never flips is not checking anything. A
repair that flips more than one means the claim ceiling was drawn in the
wrong place. Underneath sit negative controls: the unmodified artifact, a
path traversal, an untrusted issuer, a tool that was never granted.

The same structure turns a claim ceiling from a promise into a test. In my
own corpus there are eight named mutations — clean, tampered, deleted,
duplicated, reordered, migrated, a fully self-consistent forgery, and a key
swap — each with expected and observed results in both open mode and
owner-key mode. The generator compares the expected matrix cell by cell and
exits non-zero on any drift. The seal covers identity and manifest only, so
"S6 = PASS" reads as "the seal was not disturbed", never as "the content is
true". That is principle 5 made executable, and it fails loudly if anyone
writes the sentence the other way round.

If the federation wants a first cross-project check, I would rather run that
structure against someone else's corpus than add another node to the map. I
do not need them to adopt my implementation to do it.

Best,
Xinghua Zhao (Steven Zhao)
ORCID 0009-0001-0512-1237

Disclosure: prepared with AI assistance, reviewed and approved by me before
sending.

Received on Thursday, 5 November 2026 08:08:32 UTC