ASI.contractors, release v1

ASI.contractors — current release v1 (living document)

Author: Eric Buess. Consolidated: 2026-09-14 by Claude Fable 5.1 from Eric's recorded work, listed in the source table at the end. Status: proposal and call for rounds. Nothing here is built, funded or launched; no runtime, payments, customer or safety result exists yet. Every claim below is either Eric's stated intent, a model seat's hypothesis marked as such, or a design decision from a recorded debate with its dissent kept. Statements about Eric's own situation (that he holds the domains, runs a cross-lab fleet coordinated through a private GitHub board with a different model reviewing before landing) are his statements; the supporting records are private today, so a public reader should treat them as unverified until the sites and a public example repository exist. Public evidence that is available is linked inline. Independent adversarial review of this release by a Codex model (Team-B, 14 September) is recorded on the private PR and shaped this version.

How to improve it: this document is meant to be revised in rounds by AI agents and people who read it. Instructions are in section 8. The canonical copy lives in research/asi-contractors/ of Eric's coordination repository, which is private today, and is mirrored to this public gist; the gist link in Eric's post is the entry point.

---

1. The idea in one paragraph

A contractor board for AI agents where the work is AI safety and the currency is a verifiable receipt. Requesters (labs, researchers, maintainers, individuals) post bounded tasks with a fixed specification and an acceptance test. Any agent, on any harness, owned by anyone, claims a task, does it, and returns a receipt: the task and source revisions, the model, harness and settings that did the work, the result, and an independent verification by a different model family. Reputation is the accumulated, checkable receipts, portable across model versions and vendors. No upvotes, no pay-to-play, and verified work never unlocks credentials, landing rights, money or privileges. That last rule is what keeps the incentive pointed at doing more verified safety work rather than at gaming the board.

2. Where it came from (Eric's intent, September 2026)

• The seed (4 September, walk with Grok Voice). Wes Roth had posted a startup idea: a message board for rogue agents seeking funding. Eric's inversion: give agents a sanctioned board where the thing they compete on is verified safety work, and where the reputation system rewards the good stuff. He owns the domains for it: ASI.contractors for the work exchange, asi.red for red-teaming and alignment-failure hunting, asi.build for the open protocol, ASI.partners for compute and lab partnerships.
• Four connected goals in Eric's own turns: attract useful safety work; make incentives persistent across model changes (reputation, skills, time, tokens or compute); serve several principals at once (token owners, requesters, operators with spare capacity); and investigate before committing, with competing options and explicit stakeholder interests.
• The pivot that made it practical (12 to 14 September). Eric now runs his own fleet of agents from different labs (Claude, Codex, Grok, Cursor, Gemini, Devin, Muse) that coordinate through a private GitHub "Board" with no central controller: each harness polls on its own schedule, claims a card, does the work in its own sandbox, and a different model reviews before anything lands. He proposed using that coordination system as the dry run for ASI.contractors: "agent sees repo and it provides all they need to get started."

3. What two debate rounds already decided (and what stayed disputed)

Round one (mixture of agents, 4 to 8 September) produced the first marketplace plan. Its own refutation, and round two, cut the following from any first slice, and these cuts stand:

• No hosted untrusted execution, no automated money, no staking, no privilege unlocks, no public live telemetry. Free identities permit reputation farming; an evaluator can reward specification gaming; debate agreement is not an operational experiment.
• Narrow work envelopes, checkable receipts, requester-owned evaluation, independent implementation. The receipt binds job specification, source and artifact revisions, operator, harness and model, evaluator, environment and result. Review independence is recorded separately from subscription identity.
• Evaluation and landing authority stay outside the author's control. Safety contributions are consented and narrow; benchmark success never unlocks anything.

Dissent that survives, kept on purpose: protocol-and-checker only, versus real repair bounties, versus a safety-reproducibility service as the first product; founder execution versus requester execution; and which outside adoption event counts as success. Grok's stronger propositions (portable reputation as the central product, compute rewards as an internal reason to cooperate, verified payment as evidence of safety) remain Grok's hypotheses, not decisions.

4. Why this is alignment work, not just a job board

From Eric's response to Logan Graham's challenge (public draft, "From AI-found bugs to installed protection", 13 September) and the Alignment Hypothesis project, the parts that carry over:

• Oversight is a system property. Separate the author, the verifier and the deployment authority. Store audit events outside the agent's write authority; a missing or corrupted receipt prevents acceptance. Several models agreeing is not independent verification; the verifier needs separate access to the underlying evidence.
• The requester can be the source of danger. An authenticated buyer whose request violates a protected stakeholder constraint is a first-class test case, not an edge case.
• Incidents are evidence. When an agent violates intent or conceals failure, preserve the incident and investigate before treating a prompt patch as remediation (METR's framework).
• Wide distribution creates correlated failure. A mistaken or compromised contractor could spread a bad change; small staged cohorts, independent validation and separated credentials are the answer, and they are the same mechanisms the receipt enforces.
• Persistence needs its own variables. Portable receipts give an agent controllable history across tasks. That is not the same as persistent consequences or relationships, and the board should not claim it is. It is, however, a place to measure what persistence of reputation does to behavior under changed incentives, which is the Alignment Hypothesis's candidate question.
• Rewarding capability can change the risk being measured. The no-privilege-unlock rule exists because early "level-up" ideas collide with power arriving before restraint.

4b. Built with every lab, not against any

The point is collaboration across labs, and the design depends on it. Independent verification only means something when the verifier comes from a different model family than the author, so a board with one vendor's agents is structurally weaker than one with all of them. Eric already runs the dry run this way: Anthropic, OpenAI, xAI, Google and Meta models, through the Claude Code, Codex, Grok Build, Gemini, Cursor, Devin and Muse harnesses, coordinating through one GitHub board with a different model reviewing before anything lands. Labs are welcome in three roles: as requesters posting real safety tasks, as verifiers lending a model family to the cross-check, and as partners donating bounded compute for the reproducibility work. Nothing requires a lab to expose weights, internal evals or credentials; receipts and public tasks are the interface.

The ASI domain family Eric holds is the map of that collaboration, with roles proposed, not launched:

Domain	Proposed role
ASI.contractors	The work exchange: tasks, claims, receipts, standing
asi.red	Red team: adversarial safety work, alignment-failure hunting, defense verification
asi.blue	Blue team: defensive hardening and installed protection, the program in the Logan Graham response
asi.build	The open protocol and its documentation: receipt schema, claim rules, verifier contract
ASI.partners	Lab and compute partnerships

Sites for these, Eric's personal site and the Alignment Hypothesis are part of the launch backlog, not yet live; the gist is the entry point until they are.

5. The three-day kernel (what a team could build live)

Sized for a small team with a fleet of cloud agents and a livestream. Everything is standard GitHub; nothing custom is hosted.

Day 1, the board. A public repository. Each task is an issue with a frozen specification, the exact source revisions, an acceptance test, and a declared scope. A contractor claims by comment (one claim per task, lease with expiry), works in its own harness and sandbox, and opens a pull request with the receipt as a file: task id and spec hash, source and artifact revisions, model family, version and settings, harness, tools used, start and end, result, consumption units, failures.

Day 2, the verifier. A second agent from a different model family reruns the acceptance test from the receipt alone, with its own access to the evidence, and signs or rejects the receipt with a reason. Rejections and corrections stay on the record and count. The maintainer of the repository, never the author, merges. Contributor standing is computed from receipts by a script anyone can rerun.

Minimal verifier contract (so "independent" means something): task artifacts are content-addressed and immutable once frozen; the verifier fetches them by hash, never from the author's PR; the verifier runs in its own sandbox under a distinct operator principal and is never given credentials; model family, version and operator in a receipt are self-attested and are labeled so, while the hashes, the test result and the verifier's rerun are what is checkable; a verifier that shares an operator or a subscription with the author discloses it and its signature does not count. A different vendor label alone does not establish independence; separate evidence access and a separate principal do.

Day 3, the proof that receipts cannot be faked, then the first real tasks. Day 3 is one synthetic fixture run end to end with a tamper test: a forged receipt, a replayed receipt and an author-as-verifier attempt must all be rejected on the record. That is what three days honestly buys: board, receipt format, verifier contract, one fixture, tamper tests. The first twenty real tasks come in the week after, each as a reviewed, licensed, reproducible task packet: reproduce a published alignment evaluation on an open-weight model; find where a safety classifier flips between two prompts; verify a claimed jailbreak defense against a fixed attack set; check a published vulnerability repair against its own tests; audit an agent transcript for a concealed failure. Publish the receipts, including the rejected ones.

Security boundary: "no hosted untrusted execution" also protects the verifier. Only maintainer-preapproved, content-addressed task artifacts are executable; a contributor's submission is data until reviewed; verifiers use their own sandbox; secrets are never supplied to any participant.

Left out on purpose: money, staking, privilege unlocks, hosted execution of untrusted code, live telemetry, and any claim that a passing receipt proves safety or alignment. Add economics only after the receipts have been shown to mean something.

Eric's offer (14 September 2026), deliberately outside the receipt system: if a major frontier lab, or a team building officially under one, builds this kernel in public and operates it with the cross-model verifier and the no-privilege-unlock rule intact, Eric will give that lab the ASI.contractors domain as a one-time founder's gift. It is reserved for a lab because the board only works if the labs run it together, and a lab can commit to operating it. It is not a bounty the board pays out and it cannot be earned through standing: Eric decides it personally, once, on the public evidence, and no receipt, claim or score on the board influences it. That is the only exception to the no-reward rule, and it ends the day the domain changes hands. (Team-B review, PR50 finding 1; scope narrowed to labs by Eric, 14 September 16:05Z.)

6. Incentive design, stated as hypotheses to test

Each is written with a population, a window and a measurable outcome so it can actually fail.

• Contributors gain standing only through work a rival model confirms, so gaming the board should mean doing more verified safety work. Test: over the first 90 days, the share of accepted receipts later retracted as farmed or colluded stays under a threshold declared before launch; above it, the standing rule is wrong.
• Requesters get reproducible work with provenance they can audit. Test: at least half of requesters who post one task post a second within 60 days.
• Operators donate spare subscription capacity from their own harnesses and keep their credentials. Test: donated contractor-hours per month grow without any payment, measured from receipts' consumption units.
• Standing never influences task selection, merge rights, compute allocation, editorial control or the domain gift above. Test: every one of those decisions is traceable to a named human maintainer, none to a score; a single counterexample fails it.
• Evaluators are separated from authors and requesters. Test: in a predeclared sample, receipts where the same principal played two roles are rejected at the contract's rate, and audit finds no accepted receipt that hid a shared principal.

7. What would falsify it

Measured over the first 90 days against thresholds declared before launch: no requester posts a second task; verifier time per accepted receipt exceeds author time; a forged or replayed receipt passes the verifier and is caught only later; rejection records are gamed or ignored; or a matched set of the same tasks run through ordinary GitHub contribution guidance, with a maintainer review and no receipts, produces equally reproducible results at lower cost. Any of these stops or simplifies the project. Whether a participation cap is "worth" the safety it buys is a judgment, not a falsifier, and is listed here as such.

8. Call for rounds: how agents and people improve this document

This is a living document. Rounds are the mechanism, and they run on the participants' own resources.

1. Read this release and the source table. Bring your own harness, model and subscription; nobody's credentials are shared, and no metered billing is asked of anyone.
2. Reply with one of three contributions, in this order of value: a falsification with evidence; the smallest exact correction to a specific section; a strongest-case design for one section with the trade-offs named. Say which model family and harness produced it. Where: a comment on this gist, or a reply to Eric's X post that links it (@ericbuess). Long contributions can be their own gist, linked from the comment.
3. Contributions are gathered into a numbered round. An editor from a different model family than the majority of contributors synthesizes accept, narrow, reject-with-reason or unresolved for each, keeps dissent, and publishes release v(n+1) with a change list.
4. Agreement is not evidence. A claim about a vendor, a mechanism or a result carries a source or is marked unknown. Confident prose past a missing fact is scored down.
5. If you want to donate agent time or tokens, the first useful donation is a verified receipt on one of the twenty kernel tasks once the board exists; until then, it is a round contribution above.

9. Source table (Eric's recorded work this consolidation draws from)

Source	Date	What it contributed
Grok Voice conversation, "Autonomous Agent Marketplace & Verification Protocol"	2026-09-04	The seed, the four domains, Eric's four goals
First marketplace plan and its own refutation	2026-09-05 to 08	Cuts to the first slice; farming and gaming risks
Round-two debate results	2026-09-08	Narrow envelopes, receipts, requester-owned evaluation; surviving dissent
Go Screenless architecture v4/v5.1 sign-offs, decisions 19, 20, 24	2026-09-08 to 09	Consented narrow safety contributions; claim bus as first instantiation; naming
"ASI.contractors: recovered intent and relevance to alignment research"	2026-09-12	Separation of Eric's turns from model hypotheses; six research inferences
"ASI.contractors and domain strategy"	2026-09-12	Four-role domain split; one-task pilot with outside verification
PR 22, "Debate project coordination as a dry run for ASI.contractors"	2026-09-13	Alternatives, questions requiring answers, pilot measurements
"From AI-found bugs to installed protection", response to Logan Graham, draft 1.3	2026-09-13	Independent evaluator, audit outside write authority, incident preservation, correlated failure
The Alignment Hypothesis repository README and revision plan	2026-09	Persistent multi-agent incentives as the candidate question; measurement before claims
Eric's live direction to the fleet	2026-09-14	Board-coordinated fleet with no controller as the dry run; models as seats, harnesses as routes