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

Providing a schema for VOC is a lot of work that I don't have time to do.
Besides, I'm not competent to do it.  Just ask my former colleagues who
laughed at what I considered to be a spec.

One option is to leverage LLMs and use natural language.  I have been
skeptical because of the non-deterministic nature of LLMs, but I attended a
talk by some folks from OpenAI who said it works "surprisingly" well for a
similar task.  My guess is that it will need a model trained for VOC.

A second option is to use a formal policy language, such as Cedar, but that
puts more burden on developers.  The advantage is you don't need to
standardize a schema.  Instead, you treat the policy statement as part of
the application API.

--------------
Alan Karp


On Fri, Oct 30, 2026 at 9:06 AM Abisheak P <abisheakp197@gmail.com> wrote:

> 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.]
>>
>>
>>
>>
>>