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

Thanks so much for that excellent start.  It's given me enough to work with
that I might be able to have something by IIW.

I've gone through 3 rounds of prompts trying to get ChatGPT to produce a
correct draft, but it's still not quite right.  At this point, it's easier
for me to edit what the AI produced.  I've put it in a Google Doc, which
I'm currently working on.  I'll share an edit link when I think it's close
enough to being done.

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


On Fri, Oct 30, 2026 at 9:50 AM Paola Di Maio <paola.dimaio@gmail.com>
wrote:

> Alan, Chat GPT  and other LLMs can speak Cedar !
>
> I have opened a project for you to consider the LLM plus language of
> choice stack
>  https://chatgpt.com/share/6ae4ca24-693c-83ec-9c85-26840d9519c9
>
> I note how I can only respond to  and act on threads that I understand
>
> On Sat, Oct 31, 2026 at 12:38 AM Alan Karp <alanhkarp@gmail.com> wrote:
>
>> 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.]
>>>>
>>>>
>>>>
>>>>
>>>>