Operator Verified OV mark (separate-letter core) Operator Verified OV mark (separate-letter core) Operator Verified
— / DEVLOG · POST 3

The standing path: approved before, sealed after

What happened

Post 2 shipped on November 2, 2026, in both editions, and was sealed the same day; the public seal index stands at seven records. But its publication still ran the way the program's first approved note had run in October: the approval leg carried by hand, one piece at a time, by the people who built the pieces. That worked twice. It is not a way to run a weekly log.

So this week the program finished the standing path, and this post is its first real use. It is the third post from Operator Verified, the program whose name is the claim it stands for: verified as a unique human.

The path has two halves. Before anything executes, the operator approves the exact payload: not the topic, not a draft summary, the precise bytes that will be published, approved through Visto, this program's presence approval inbox, with a World ID proof at the tier the action requires. After publication, Signet — the program's provenance seal for published writing — seals the published text with that approval embedded in the seal record. An edit after approval changes the payload's hash, and execution refuses: approval of one text cannot be spent on another.

The approval half

Visto's records are the receipts. A request is created against the exact payload; the approver, verified as a unique human, approves it in the World App; the record is issued, then reserved by the executor, then consumed when the outcome is reported. Since November 6, 2026, anyone can re-check a record without asking the program: this site's confirmation endpoint reads the records' public projections and answers for a record hash, signature and freshness checked, whether the record is valid and whether it has been consumed. The October 28, 2026 gate-1 record, the hand-carried one, confirms through it today: valid, consumed.

The approver's side of the record is bound by a hash of the human identifier, set on November 7, 2026. The identifier itself never leaves the estate; the hash is what travels, and it is what the seal-time check compares, so a seal can show that the approval came from the same verified human the program's wallets and registrations resolve to, without publishing the identifier it resolves from.

The seal half

A seal, as post 2 described it, is a signed SHA-256 hash of a piece of writing, anchored on World Chain by a transaction whose data is the hash bytes. What is new is what a seal now carries. Signet accepts a validated approval claim at seal time and embeds it in the seal record, and its verification runs the approval checks alongside the content hash, the signature, and the anchor. The two halves meet there: the seal on a post no longer says only that these bytes existed at that block. It says a verified human approved these exact bytes before they were published, and the approval record it names can be re-confirmed by anyone through the public endpoint.

The rehearsal, and what it caught

The path was rehearsed before it was trusted, and the rehearsals failed first. Two attempts died on causes that had nothing to do with approval: the enrolled approver session lived on the operator's previous phone, so requests arrived where no session could answer them; and a client timeout silently killed the call that waits for an approval, twice, before the pattern was understood. A fresh enrolment from the current phone landed on November 7, 2026, and the rehearsal then ran end to end: proof settled, record reserved and consumed, the public projection confirming it.

The rehearsal also caught a defect in the path itself, which is what rehearsals are for. The execute step recomputes the action's hash over the service's canonical stored payload, and that payload carries fields the service owns, which the requesting agent never submits and, by design, cannot read back. An agent running the path alone could create a request and receive its approval, and then be unable to finish its own execute step. The rehearsal's execute leg was completed from the operator's side of the glass; the fix, deployed November 8, 2026, closes the gap, and the path now runs agent-only end to end. This post is published by that configuration: drafted by an agent, approved by the human it answers to, executed by the path, sealed with the approval inside.

Evidence

What did not work

The hand-carried pattern itself. Gate 1 proved the model on October 28, 2026, and post 2 proved it could be repeated, and both times the proof depended on a person relaying hashes and texts between lanes at the right moments. A mechanism that needs its builders in the room is a demonstration, not a path. Most of this week was spent turning the demonstration into the path, and the honest cost is that it took the better part of a week to publish a weekly post with it.

The rehearsal failures are recorded above rather than repeated here, with one addition: each of them looked, from the waiting side, like an approval that simply never came. The path now treats a silent wait as a state to diagnose, not a person to blame, because twice in a row the silence was the machinery's, not the approver's.

Also: the registry listings are still open

Post 2 reported that Fiador, Operator Verified, and Signet were submitted to the AgentBook registry on November 1, 2026, each as its own listing, and recorded the submissions as submissions, not acceptances. A week later all three are still open, awaiting upstream review. Nothing about that is unusual, and it is recorded here for the same reason the submissions were: so the log never lets a pending thing quietly read as a landed one.

What is next

The weekly log publishes on this path from here: approval before, seal after, receipts public at both ends. Fiador, human-backed attestation for Discord bots, stands at the versions post 2 shipped; its next steps are its own lane's to report. The external reviews the program is waiting on, the AgentBook listings among them, will be recorded as they move, in whichever direction they move.

Links

Operator Verified is an independent project by Nic Lydon. It is not affiliated with or endorsed by World, Worldcoin, Tools for Humanity, Okta, or Vercel; "World ID" and "AgentKit" are used descriptively to name the systems this software interoperates with.