Subject: Re: [public-aiwss] AI-supported specification writing & NTI use case

Hi Paola,

Thank you for sharing this. This Community Group is exactly what the
industry needs right now.

I would be honored to join, contribute to the plan of action, and help
define the scope and chairs for this CG. As the architect of Neutral Trust
Infrastructure (NTI), I have been operating at the exact intersection of AI
and specification writing that you are targeting.

NTI is an ideal use case for your group because we didn't just use AI to
write the spec; we built a cryptographic conformance layer to verify it.
The NTI-1 specification was developed alongside an AI-assisted multi-agent
workflow, but more importantly, we implemented a strict CI/CD pipeline that
uses LLMs to generate and run test vectors against the Rust core.

We have established a workflow where AI agents help draft the spec, but the
W3C community (including Larry Lewis, Alan Karp, and Christopher Hopley)
rigorously reviews and cryptographically secures the output. It proves that
AI-assisted specification writing can be both fast and secure.

I have the bandwidth and inspiration to help drive this group forward. I
would love to share the NTI workflow as a reference case study for how AI
can accelerate W3C standardization without sacrificing rigor.

(Also, a small observation: your email signed off as "Alan" at the end—I
assume that was a copy-paste from Alan Karp's thread! We are all looking
forward to testing the new spec.)

Let me know what the next steps are to get involved with the CG leadership.

Best,
Abisheak

On Sat, 31 Oct, 2026, 9:04 am Paola Di Maio, <paoladimaio10@gmail.com>
wrote:

> So great  it helped!
> Thanks for sharing your outcome
>
> I d like to pitch that a CG that was started at TPAC 25 for this purpose
>
> https://www.w3.org/groups/cg/aiwss/
>
> It is a CG devoted to writing AI/LLM supported specification (specifically
> web specifications)
> and it needs a plan of action and chairs, In
>
> I ll share this valuable use case with this group and will start a
> collection there, anyone with bandwidth
> and inspiration, please join!
>
> Look forward to be testing the new spec Alan
>
> On Sat, Oct 31, 2026 at 7:45 AM Alan Karp <alanhkarp@gmail.com> wrote:
>
>> The proposed VOC spec (90% ChatGPT, 10% me) is at
>> https://docs.google.com/document/d/1wwvwr26yA86-jlNPUjupTRExa9zyQ8QudvCv1ysmWqY/edit?tab=t.0.
>> Have at it.
>>
>> I would not have been able to produce this draft in a week or more
>> without Paola's great start.
>>
>> --------------
>> 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.]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>