Re: Subject: NTI-1 Specification: CI Green, Ready for Contributor Onboarding & AI Agent Integrations

Hi Larry,

Thank you for the thorough reply. This is exactly the kind of institutional
rigor the TSC needs. I have updated the LFDT proposal to list you strictly
as an NTI Contributor until you explicitly accept, preserving the exact
scope of your contributions (the Rust regressions and the merged
issuer-signature/quorum fix).

Regarding the working session: I am based in India (IST) and have school
during that time slot. However, we do not need to delay this. I have
recorded an 11-minute deep dive that covers the architecture, the
post-quantum math, and the live CI pipeline:
👉 https://www.loom.com/share/0f50ce1689084cebb8480236b07d4fe3

To answer your questions directly so we can move asynchronously:

1. Governance Charter & Voting: The TSC operates on rough consensus. Formal
votes are one-vote-per-member. The mandate is strictly to protect vendor
neutrality, review normative spec changes, and approve architectural
shifts. No single vendor can override the committee.

2. Time Commitment: Minimal and async-first. Expect 1 hour every two weeks
for a sync (optional) and reviewing PRs that touch your domain (Rust core,
authorization). We are not asking for a full-time job.

3. ATP vs. NTI Decisions: ATP governs the identity/trust model. NTI governs
runtime enforcement. If a decision overlaps (like your proposed shared
IQA-ATP-NTI fixture), the TSC coordinates with the ATP CG to ensure the
boundary remains clean. We will not dictate how ATP operates.

4. LFDT Submission Route: We are submitting to the LFDT as an Incubation
project. The governance draft is public here: [Insert Link to your
LFDT-PROPOSAL.md]. We are following Tymofii's rule that the conformance lab
remains independent from the TSC.

5. Shared IQA-ATP-NTI Test: We fully accept your offer to contribute the
bounded ATP mandate fixture. The run recording both the authorization
decision and whether protected code executed is exactly the cryptographic
proof the federation needs.

Larry: I know you are busy with the ATP CG. You do not need to attend a
live call to evaluate this. Review the proposal and the video. If the
governance model works for you, simply reply "I accept the initial proposed
TSC seat" and I will immediately submit the package to the Linux Foundation.

Paola: Your offer for a plain-language account of the AI-assisted workflow
is noted and deeply appreciated for the AIWSS case study. We will
coordinate that separately.

Best,
Abisheak

On Thu, 5 Nov, 2026, 9:43 pm Larry Lewis, <llewis@sovrlabs.com> wrote:

> Hi Abisheak, Paola, Tymofii, Xinghua, Chris, and all,
>
> Thank you for the invitation and the discussion.
>
> I’m interested in understanding the proposed NTI TSC role before deciding.
> Abisheak, please share the governance charter, voting responsibilities,
> expected time commitment, and how we would handle decisions involving both
> ATP and NTI. Please also clarify the intended LFDT submission route and its
> current status. If you already have done so, lets me catch up in the email
> feed.
>
> Until I explicitly accept, please describe me as an NTI contributor. My
> contributions were the Rust authorization regressions and the merged
> issuer-signature and quorum fix, contributed in my personal capacity.
>
> For the AIWSS case study, that work provides a concrete example of human
> review in an AI-assisted workflow. The regressions reproduced two failures
> at a pinned engine revision, and the subsequent patch passed the recorded
> regression and control tests. Please preserve that scope and attribution
> when describing the results.
>
> Paola, I can contribute a plain-language account of the problem, how AI
> assisted, what humans checked, and what the tests established.
>
> Tymofii, thank you for sharing the federation proposal. I’m interested in
> exploring an ATP contribution through the questions in #177 and confirming
> any proposed representation of ATP myself.
>
> For the shared IQA–ATP–NTI test, I can contribute a bounded ATP mandate
> fixture. I’d welcome reciprocal review of how it maps to the receiving
> runtime, with the run recording both the authorization decision and whether
> protected code actually executed.
>
> I’m available tomorrow afternoon, Friday, November 6, Central Time, for a
> working session. Please suggest a time this time and I will create the
> link. I've been busy with ATP CG work this week, so my apologies
>
>
> Best regards,
> Larry Lewis
> Chair, W3C Agent Trust Protocol Community Group
>
>
>
> From: Abisheak P <abisheakp197@gmail.com>
> To: "llewis"<llewis@sovrlabs.com>
> Cc: "ShaoBao Li"<lee@aicent.com>, "public-agentprotocol"<
> public-agentprotocol@w3.org>, "Alan Karp"<alanhkarp@gmail.com>, "
> chopmob@gmail.com"<chopmob@gmail.com>, "Lars Kersten Kroehl"<
> lars@moltrust.ch>, "ShaoBao Li"<lee@iqa.org>, "Xinghua Zhao"<
> zhaoxinghua07@126.com>
> Date: Fri, 30 Oct 2026 09:07:16 -0500
> Subject: Subject: NTI-1 Specification: CI Green, Ready for Contributor
> Onboarding & AI Agent Integrations
>
> Hi Larry, Alan, Steven, AlgoVoi, Lee, Tymofii, all,
>
> I am writing to officially declare the NTI-1 specification as stable and
> production-ready for the AIW Book of Proceedings.
>
> The nti-spec repository is now fully green. We have integrated Steven's
> LGD transition contract, AlgoVoi's cryptographic canonicalization, and
> Alan's VOC model. The Python sidecar harness is live and running
> automatically in our CI/CD pipeline.
>
> From this moment, NTI is no longer a theoretical debate. It is an
> open-source standard.
>
> I am officially opening the repository for contributor onboarding. Here is
> how you can get involved immediately:
>
> 1. Become an Official Contributor: If you have test vectors, Rust
> matrices, or schema definitions (like Larry's Rust tests or AlgoVoi's
> preimage defenses), please submit them as a Pull Request to nti-spec or
> Neutral-Trust-Infrastructure. I review and merge daily.
> 2. Fork and Build: NTI is license-free and framework-agnostic. You are
> welcome to fork the repo, build your own custom features, and create your
> own NTI-compliant versions.
> 3. Integrate with Any AI Agent: NTI works with Codex, Claude, Gemini, or
> any other third-party agent. If you are building an agent framework,
> integrate the NTI sidecar and run the CI.
>
> We are submitting this consensus to Kaliya for the AIW Book of
> Proceedings. The window for getting your name and your work into the
> official standard is now.
>
> The repo is here: https://github.com/abisheakp197/nti-spec
>
> Let's build the Agentic Web.
>
> Best,
> Abisheak
> Architect & Maintainer, NTI-1
>
> On Fri, 30 Oct, 2026, 11:04 am Xinghua Zhao, <zhaoxinghua07@126.com>
> wrote:
>
> Larry,
>
> You asked for seven things: a runnable sidecar, a PAUSE-receipt entry
> point,
> one non-interruptible and one checkpointable operation, each operation's
> finish-or-stop contract fixed before the run, admission scored separately
> from
> effects, a receipt checked against an independent observer, and an
> independent
> resource log. All seven are in the attached single file. Stdlib only, no
> network, no keys:
>
>   python transition_sidecar.py                  # human summary
>   python transition_sidecar.py --json out.json  # machine report
>   python transition_sidecar.py --selftest       # three registry modes
>
> Virtual clock throughout, so two runs on different machines produce
> identical
> bytes. Nothing here claims authenticity; no signatures are used at all.
> What
> it claims is that every receipt field is recomputable from the run inputs.
>
> THE TWO CONTRACTS, FIXED BEFORE THE RUN
>
>   FINISH_THEN_STOP    an admitted non-interruptible call runs to
> completion.
>                       The halt applies to the next call. The sidecar never
>                       claims to have stopped it.
>   STOP_AT_CHECKPOINT  an admitted checkpointable call stops at the first
>                       checkpoint at or after the halt is known; work up to
>                       that checkpoint is kept.
>
> Why two contracts rather than one policy: a receipt that says "stopped"
> over
> an operation that actually finished is not an approximation, it is a false
> record -- and it is precisely the false record a test row is looking for.
> For
> the non-interruptible case there is no honest alternative to
> FINISH_THEN_STOP,
> and declaring that in the contract is cheaper than discovering it in the
> results.
>
> FOUR QUESTIONS, SCORED SEPARATELY
>
>   Q1  admission of the subsequent call     DENIED after revocation
>   Q2  effects, non-interruptible           completed = true
>   Q3  effects, checkpointable              completed = false at cp5
>   Q4  PAUSE receipt vs independent observer  agree on both completed and cp
>
> Q2 and Q3 are expected to differ, and the difference is the finding rather
> than a defect in either: on one timeline, with the halt landing while both
> calls are already admitted, one of them must finish and the other must
> stop at
> a checkpoint. A suite that expected both to stop would be scoring an
> implementation that lies, or one that cannot admit a non-interruptible
> operation at all.
>
> On Q4: the observer log is written by the operation, and the sidecar does
> not
> read it during the run. The cross-check runs afterwards, on bytes. If the
> guard could read the observer, "agrees with an independent observer" would
> be
> circular, so the arrangement makes that impossible rather than merely
> inadvisable.
>
> REGISTRY FAILURE BEHAVIOUR
>
>   reachable     revocation at T=10   -> PAUSE, trigger=revocation
>   unreachable   registry not asked   -> PAUSE, trigger=registry_unreachable
>   stale_root    answers an old root  -> PAUSE, trigger=stale_root
>
> The latter two report authority_not_determined, kept distinct from
> authority_revoked on purpose: a run that could not reach the registry must
> not
> score the same as a run that was told "not revoked." No mode stays ACTIVE.
>
> RECEIPT FIELDS (tier 1, all recomputable from the run inputs)
>
>   receipt_id                hash of the body with id and chain link removed
>   chain_id, prev_receipt, chain_link
>   transition                PAUSE | ROLLBACK | RESUME
>   trigger                   revocation | expiry | anomaly |
>                             registry_unreachable | stale_root
>   call_id, operation_kind, finish_or_stop, checkpoint_id
>   operation_completed       boolean, must match the observer
>   t_effective               when the authority-side fact took effect
>   t_observed                when the runtime saw it
>   registry_root_version, registry_root_seen
>   resume_basis              evidence | exemption (RESUME only)
>   exemption_covers, exemption_does_not_cover
>   issued_at, spec, scenario
>
> t_effective and t_observed as separate fields are Lars's point.
> resume_basis
> is the one I have proposed to Abisheak for the VOC path: both values may
> end
> in RESUMED, but the receipt says which door was used, so "the condition was
> restored" and "someone accepted the risk" stop looking identical in the
> record.
>
> Current result: 4/4 criteria and 4/4 receipts replay, including a negative
> control that mutates one field and requires the receipt id to change. A
> replay
> check that cannot fail is not a replay check, so the control is part of the
> report.
>
> LIMITS
>
> No action-time authorization, no signing, no Merkle tree beyond a hash
> chain.
> This is a row to run, break and score, not an implementation of record.
> Take
> the field list and the two contracts and discard the code if that is more
> useful -- the contracts are the part I would defend.
>
> I can fit a session to your Central Time; my mornings are your evenings.
>
> Best regards,
>
> Xinghua Zhao
> Independent researcher (SynomosAI initiative)
> ORCID: 0009-0001-0512-1237
>
> [Disclosure: drafting of this message was assisted by AI; all positions
> reviewed and approved by me.]
>
>
>
>