
Use these exact entries. Submission Title CAT Dark Factory Short Description An autonomous software factory that separates implementation, evidence, and acceptance. CAT uses independent agents, deterministic contract gates, durable handoffs, and reviewer-driven repair loops so software is accepted by evidence—not by its author. Long Description `CAT Dark Factory is an autonomous software-delivery system designed around one principle: the agent that writes software should not be the agent that decides whether it is correct. For the Pocketful challenge, CAT R4 used four independent roles: Coordinator, Implementer, Evidence Engineer, and Reviewer. After a single human dispatch, the factory operated autonomously. The Implementer produced committed candidate revisions, deterministic contract checks validated each candidate, the Evidence Engineer generated independent evidence, and the Reviewer made the final acceptance decision. Failed reviews were automatically converted into evidence-backed repair requests and routed back to the Implementer. This was not a simulated workflow. Stage 1 required six implementation attempts before acceptance. The factory caught issues including idempotency and state round-trip edge cases, malformed split participant types, and settlement authorization precedence. CAT also demonstrated recovery from infrastructure failure. When an Evidence Engineer process timed out, the factory recovered an already-prepared durable handoff without another human task message and without creating a duplicate logical handoff. The final accepted Stage 1 revision was published publicly and independently validated from a fresh clone. The official isolated harness collected 147 tests: 147 passed, with zero failures and zero errors. CAT combines SHA-bound handoffs, durable orchestration state, deterministic gates, independent evidence, independent review, auditable Git history, and autonomous repair loops. Its goal is not simply to make agents write more code.
6 Oct 2026

AI coding agents can produce code that compiles, passes tests, and still implements the wrong product because an underspecified request was silently turned into a plausible assumption. NoGuess is an epistemic control plane for AI coding agents built around IBM Bob. It sits between a developer request and implementation. Bob can propose plausible interpretations of an ambiguous requirement, but NoGuess compares their observable effects rather than trusting wording or model confidence. If two plausible interpretations would produce materially different behavior, NoGuess records a semantic fork as Guess Debt and denies implementation capability. The system then asks the smallest neutral human question that can distinguish the competing behaviors. A model proposal cannot declare ambiguity resolved, manufacture a human decision, or grant itself execution authority. Only an allowed evidence path—such as an explicit human decision—can resolve the relevant Guess Debt. A deterministic kernel then grants or denies capability from that evidence basis. Every accepted transition is recorded in an append-only, hash-chained event ledger. NoGuess produces an Epistemic Receipt showing what was known, what was inferred, where interpretations diverged, what a human actually decided, and why the agent was allowed to act. The flagship demo starts with: “Make VIP refunds automatic.” With no human answer, the system remains BLOCKED_UNRESOLVED_INTENT. An explicit human selection can move it to READY_FOR_IMPLEMENTATION. Choosing “Other / none of these” returns NEEDS_EXTERNAL_INPUT and stays blocked rather than fabricating closure. The target users are engineering teams using AI coding agents in enterprise, regulated, high-change, or high-cost codebases where a technically valid but wrongly inferred requirement can cause expensive rework or operational risk. The key difference is that NoGuess does not merely ask clarification questions after uncertainty appears; it controls whether implementation authority exists before the agent acts.
27 Sep 2026