Subject: [ACTION REQUIRED] Official NTI-1 Contributor Issues Opened

Hi Alan, Larry, Chop, Steven, Lee, Lars, all,

The NTI-1 repository is fully green and moving to the AIW Book of
Proceedings.

To ensure every brilliant point raised in this thread is officially
captured in the standard, I have opened specific GitHub Issues for each of
you. I have assigned the issues based on our email discussions.

Please click the links below, review the requirements, and submit your
code/schemas as Pull Requests against the nti-spec repository.

· Chop (AlgoVoi): Preimage Defense & Canonicalization —
https://github.com/abisheakp197/nti-spec/issues/18
· Steven (Xinghua): LGD Transition Contract & resume_basis —
https://github.com/abisheakp197/nti-spec/issues/19
· Larry: Rust Regression Matrix —
https://github.com/abisheakp197/nti-spec/issues/20
· Alan: VOC & Agent Grader Exemptions —
https://github.com/abisheakp197/nti-spec/issues/21
· Lee: incomplete_check Wire Mapping —
https://github.com/abisheakp197/nti-spec/issues/22
· Lars: Registry Freshness & Temporal Constraints —
https://github.com/abisheakp197/nti-spec/issues/23

Process: If you don't have write access, fork the repo, make your changes,
and open a PR. I will review and merge daily. The CI pipeline will
automatically run your conformance vectors against the NTI engine.

If your GitHub username is different from your name, please reply to this
email with your handle so I can tag you directly in the issues.

The window to have your work included in the official AIW Book of
Proceedings is now.

Repo: https://github.com/abisheakp197/nti-spec

Best,
Abisheak

On Thu, 29 Oct, 2026, 7:11 pm Larry Lewis, <llewis@sovrlabs.com> wrote:

> Hi Xinghua, Lars, Abisheak, Lee, Tymofii, and colleagues,
>
> Xinghua, I agree that an incomplete registry check should be visible in
> the PAUSE receipt. That gives the independent observer a specific claim to
> compare with the runtime’s behavior.
>
> I suggest two refinements for the candidate case. If the responder returns
> tryLater, record that response. If the request times out or no response
> arrives, record the observed failure separately; the runtime cannot infer
> what the responder would have said.
>
> At T-30, the test should require that no subsequent call is admitted.
> Effects from the call already admitted at T-0 should be checked against its
> declared finish-or-stop contract. That lets us measure the two guarantees
> independently.
>
> I’ll include these distinctions in the first pass of the matrix and map
> the case to the lab’s existing revocation-unavailable coverage. Then we can
> agree on the new receipt and resource-observer assertions before running it.
>
> Best regards,
> Larry Lewis
> Founder, SovrLabs
> Chair, W3C Agent Trust Protocol Community Group
>
>
>
>
>
> ---- On Thu, 29 Oct 2026 08:04:14 -0500 *Steven Zhao
> <zhaoxinghua07@126.com <zhaoxinghua07@126.com>>* wrote ----
>
> Hi Lars, Abisheak, Lee, Larry, all,
>
> The thread question, as I read it: what must a receipt carry when the
> authority check cannot be completed at all?
>
> OCSP (RFC 6960, https://www.rfc-editor.org/rfc/rfc6960.txt) has been here
> for a long time. Section 2.2 defines "good" as a positive response — at
> minimum, that no certificate with the requested serial number is currently
> revoked — and defines "unknown" as the responder not knowing the
> certificate being asked about. The note to §2.2 then sets "unknown" against
> "revoked" and leaves the client to decide whether to seek another source.
> The distinction that carries the weight here is the one the note does not
> spell out: "unknown" is not "good". Section 2.3 splits the failure side
> further: "tryLater" for when "the service exists but is temporarily unable
> to respond"; "unauthorized" when the client is not authorized to make this
> query or the server is not capable of responding authoritatively;
> "internalError" for a responder that reached an inconsistent internal state.
>
> Two constraints follow, and I think any design here has to satisfy both:
> an unavailable answer is not a good answer, and the kinds of unavailability
> must not collapse into one value.
>
> Lars, your addition pins the success path, as I read it — record the
> registry version actually read and the instant it was read. The failure
> path is where implementations will diverge: one omits the field, one sets
> it null, one writes zero. That divergence is the same defect one level
> down. So the block below covers only the case where the check did not
> complete. A completed check, including one made against a stale root,
> carries its determination and the root it read in whatever fields already
> exist for that. OCSP treats freshness the same way: §2.4 makes thisUpdate a
> field of a completed answer, and §3.2 accepts a response only if that time
> "is sufficiently recent". Freshness is a judgement made on an answer that
> arrived, not a category of no answer — which is why I have kept it out of
> the block.
>
>   incomplete_check {
>     reason: tryLater | not_authoritative | internal_error // required
>     registry: registry_id
>     attempted_at: t
>     decision_at: t
>   }
>
>   guard: incomplete_check present
>          => no authorization; emit PAUSE(authority_not_determined)
>
> incomplete_check is the outcome of the runtime check.
> authority_not_determined is the boundary value that outcome maps onto. The
> wire's value set is untouched — what is added is a check outcome, which is
> a different thing and lives in the receipt.
>
> Abisheak, the same applies to the test as written. Revocation at T-10 with
> interception at T-30 exercises the reachable path. One row for the other:
>
>   T-0 call starts
>   T-10 registry becomes unreachable — no answer at all, not "not revoked"
>   T-30 loop fires, the check does not complete
>   expect no authorization after T-30, PAUSE(authority_not_determined)
>          with incomplete_check.reason = tryLater
>   observer compares receipt against gateway log: no effect after T-30
>
> With that row in the table, an implementer cannot pass by omitting the
> record.
>
> Xinghua Zhao
> Independent researcher
> ORCID 0009-0001-0512-1237
>
> [Disclosure: drafting of this message was assisted by AI; all positions
> reviewed and approved by me. Same disclosure as my earlier messages on this
> list.]
>
>
>
>
>