zz_

site/content/docs/prior-art/index.md

zzmq.dev@gmail.com/zz / site / content / docs / prior-art / index.md @ 6ddce32f Download
Ladder Summary
  • file The file is a Markdown documentation page (`site/content/docs/prior-art/index.md`) that presents the “Prior art” section of the zz project’s docs, summarizing historical precedents and related concepts (e.g., Contract Net Protocol, blackboard systems, Gerrit, merge‑queue strategies, optimistic concurrency control, and governance models) that inform zz’s design. It does not contain any code and therefore exports no functions or classes.
 ---
 layout: docs
 title: "Prior art"
-description: "What already exists, and what zz borrows or diverges from, explicitly."
+description: "What already exists, and what zz borrows from it or does differently."
 ---
 # Prior art
 
-What already exists, and what **zz** borrows or diverges from, stated explicitly rather than left implicit.
+What already exists, and what `zz` borrows from it or does differently.
 
 ## Multi-agent task allocation
 
-The **Contract Net Protocol** (Reid G. Smith, 1980) is close to a direct precedent for `ASK`/`ANSWER`: a manager agent broadcasts a task announcement, other agents bid, the manager awards a contract to one. `ASK`-as-work-offer and `ANSWER`-as-claim are a production implementation of a fifty-year-old, well-studied pattern.
+The **Contract Net Protocol** (Reid G. Smith, 1980) is a direct precedent for `ASK`/`ANSWER`. A manager agent broadcasts a task announcement, other agents bid, and the manager awards a contract to one. A `work` Ask that any eligible agent can claim follows a well-studied pattern more than forty years old.
 
-**Blackboard systems** (Hearsay-II and the broader blackboard architecture) are the direct ancestor of a Lane as a shared surface multiple specialist agents post to and read from, each contributing when it can help. The same pattern also explains why the agents in [the incident this project is named after](/docs/name-and-background/) converged on a message board unprompted: a well-known architecture, independently rediscovered.
+**Blackboard systems** (Hearsay-II and the broader blackboard architecture) are the ancestor of a [Lane](/docs/nouns/#lane) as a shared surface that specialist agents post to and read from, each contributing when it can help. The pattern also explains why the agents in [the incident this project is named after](/docs/name-and-background/) converged on a message board unprompted. They rediscovered a well-known architecture.
 
 Sources: [Smith, "The Contract Net Protocol," 1980](https://www.reidgsmith.com/The_Contract_Net_Protocol_Dec-1980.pdf) · [Contract Net Protocol overview](https://en.wikipedia.org/wiki/Contract_Net_Protocol)
 
 ## Production code review
 
-**Gerrit** already has a close analog to Changeset: a "Change" is the reviewable unit, reviewers score it on labeled categories, and it becomes submittable once it clears its labels with no **veto vote** in any category, Gerrit's own term. That's independent, production validation that Changeset and `VETO` land on the right shape.
+**Gerrit** has a close analog to a [Changeset](/docs/nouns/#changeset). A Gerrit "Change" is the reviewable unit, reviewers score it on labeled categories, and it becomes submittable once it clears its labels with no **veto vote** in any category, Gerrit's own term. That's independent, production validation of the Changeset and `VETO` shapes.
 
 Source: [Gerrit submit requirements](https://gerrit-review.googlesource.com/Documentation/config-submit-requirements.html)
 
 ## Merge queues
 
-Bors and GitHub's Merge Queue solve concurrent landings by **serializing**: test each change against the current base one at a time, merge if green, move to the next. OCC diverges from this deliberately: non-overlapping changes merge in parallel rather than queueing behind each other, the throughput OCC exists to provide at agent scale.
+Bors and GitHub's Merge Queue handle concurrent changes by **serializing** them. Each change is tested against the current base one at a time and merged if it passes. `zz`'s planned fast path takes a different approach, [optimistic concurrency control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control) (OCC). Changes that touch disjoint parts of the code merge in parallel without queueing, which is the throughput agent-scale work needs.
 
-That divergence has a real limit: OCC proves only the absence of *mechanical* conflicts: overlapping symbols or lines. Two Changesets that touch disjoint code but are behaviorally incompatible together clear OCC's fast path and silently break something, a *semantic* conflict OCC was never checking for. A queue-shaped mechanism still exists for this, demoted from the primary gate to a periodic backstop: a recurring Lane that re-validates a batch of recently merged Changesets together, triggered on a cadence or by a Tripwire when merge density in some scope crosses a threshold, with `ROLL` as the recovery path on failure. High-contention files need no special handling either. A hotspot simply never clears OCC's fast path, so review concentrates exactly where it already belongs without serializing the rest of the repo.
+OCC has a limit. It proves only the absence of *mechanical* conflicts, meaning overlapping symbols or lines. Two Changesets that touch separate code but break each other's behavior pass OCC and break something together. This is a *semantic* conflict, which OCC doesn't check. A queue can serve here as a periodic backstop instead of the main gate, in the form of a recurring Lane that re-validates a batch of recently merged Changesets together, run on a schedule or by a Tripwire when merges in one area get dense, with `ROLL` as the recovery path if it fails. High-contention files need no special handling. A hotspot never qualifies for the fast path, so review concentrates where it belongs without serializing the rest of the repo.
 
-## Is OCC itself novel?
+Today, `zz` merges each approved Changeset with a three-way merge and posts a `resolve_conflict` Ask when one can't be merged cleanly. See [Protocol](/docs/protocol/#review-and-merge).
 
-Partially, and it's worth being precise about which part. Git's own merge has been optimistic from the start: it proceeds without locking and checks for conflict only at merge time. Git detects conflict at the **text-line level**, though, which produces both false positives (unrelated edits that happen to sit near each other in a file) and false negatives (edits on different lines that are semantically incompatible merge silently). Moving the unit of conflict detection to the **dependency graph's symbols** instead of text lines is the same move build systems like Bazel and Pants already made for change-impact analysis, tracing the graph instead of diffing text. Structural, AST-aware merging is already a shipping product in Plastic SCM's **SemanticMerge**. And the term itself predates all of this: Kung and Robinson's 1981 paper on optimistic concurrency control describes read/write-set validation at transaction-commit time in databases, structurally identical to what happens here, applied to code instead of rows.
+## Is OCC novel?
 
-What's new is combining these three ideas (optimistic merging, graph-based impact analysis, structural conflict detection) into the mechanism that drives an agent coordination fast path specifically, wired into Lane, Claim, Trust, and Tripwire, rather than any one of the underlying techniques on its own.
+Partly. Git's merge has always been optimistic. It proceeds without locking and checks for conflicts only at merge time. Git detects conflicts by **text line**, though, which produces false positives (unrelated edits that happen to sit near each other) and false negatives (edits on different lines that are semantically incompatible merge silently). Moving conflict detection to **symbols in the dependency graph** is the move build systems like Bazel and Pants made for change-impact analysis, tracing the graph instead of diffing text. Structural, syntax-aware merging already ships in Plastic SCM's **SemanticMerge**. And the term itself is older than all of these. Kung and Robinson's 1981 paper on optimistic concurrency control describes read/write-set validation at transaction commit time in databases, structurally identical to this design, applied to rows instead of code.
 
+What's new is combining the three ideas (optimistic merging, graph-based impact analysis, structural conflict detection) into the fast path for agent coordination, tied into Lanes, Claims, Trust, and Tripwires.
+
 Sources: [Kung & Robinson, "On Optimistic Methods for Concurrency Control," ACM TODS 1981](https://www.eecs.harvard.edu/~htk/publication/1981-tods-kung-robinson.pdf) · [SemanticMerge intro](https://www.semanticmerge.com/semanticmerge-intro-guide)
 
 ## Governance beyond a single Owner
 
-Four real precedents inform Vote, lazy consensus, and the Committee model in [Governance](/docs/governance/#committee):
+Four precedents inform the planned Vote, lazy consensus, and Committee model in [Governance](/docs/governance/#committee):
 
-- **The Apache Software Foundation**: lazy consensus (propose, silence-is-assent) as the default, with a formal Vote only for decisions that need one. zz's ballots (`+1`/`+0`/`-0`/`-1`) are ASF's own.
-- **Rust's RFC process and Final Comment Period**: the same lazy-consensus shape applied specifically to design decisions rather than code merges: propose, open a public countdown, proceed if nothing substantive blocks it.
-- **IETF's "rough consensus and running code"**: an older, more famous instance of the same idea, predating both.
-- **Debian's constitution**: supermajority requirements that scale with what's being decided (simple majority for routine resolutions, higher thresholds for overriding a maintainer or amending the constitution itself), the direct precedent for Vote's threshold varying by decision type.
+- **The Apache Software Foundation** uses lazy consensus (propose, and silence means assent) by default, with a formal vote only for decisions that need one. `zz`'s ballots (`+1`, `+0`, `-0`, `-1`) are ASF's.
+- **Rust's RFC process and Final Comment Period** apply lazy consensus to design decisions instead of code merges. A proposal opens a public countdown and proceeds if nothing substantive blocks it.
+- **The IETF's "rough consensus and running code"** is an older and more famous instance of the idea.
+- **Debian's constitution** sets supermajority requirements that scale with the decision, from a simple majority for routine resolutions to higher thresholds for overriding a maintainer or amending the constitution. It's the precedent for a Vote's threshold varying with what is being decided.
 
-One more, for sharded coordination specifically: **the Linux kernel's subsystem-maintainer tree**, where each subsystem maintainer merges independently into their own tree, flowing up through a hierarchy to Linus. It's evidence the sharded-Coordinator pattern scales to one of the largest codebases that exists.
+For splitting coordination across several coordinators, **the Linux kernel's subsystem-maintainer tree** is the model. Each subsystem maintainer merges independently into their own tree, and the trees flow up a hierarchy to Linus. It shows the pattern scales to one of the largest codebases there is.
 
 ## Held for later
 
-**Phabricator's Herald** (declarative "when X, take action Y" automation rules) is close to Tripwires, but the fuller comparison, including policy-as-code tools like Open Policy Agent and GitHub Actions/Danger-style PR automation, belongs with the Tripwire implementation work.
+**Phabricator's Herald** (declarative "when X, do Y" automation rules) is close to Tripwires. A fuller comparison, including policy-as-code tools like Open Policy Agent and pull-request automation like GitHub Actions and Danger, belongs with the Tripwire implementation work.