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

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, < mailto: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.]