Requirements — the autonomous company

For: an agent harness executing against /Users/amit/zero.9.stores (branch master).

Deliverable: a company that charters itself, assigns its own work, executes it, reviews it, and

reports what it cost — with the employee as the addressable unit a human can understand.

0. Scope

0.1 What this is

Most of the autonomy stack already exists in this repo (§2). This project does not rebuild it.

It supplies the two missing pieces and closes the loop between everything else:

• the employee — a named, addressable worker with a role, a manager, a budget, and a ledger;

• the clock — what actually fires the autonomous cycle, on a schedule, without a human typing.

0.2 Non-goals (do not build these)

• No engine changes. DSL only.

• No changes to the store install / GET path, closure pull, or paywall mechanics.

• No publishing to the CDN, no store.push, no commits unless explicitly asked.

• No real-human partner marketplace or demand/supply matchmaking (leave the seam, build nothing).

• No attempt to run a million employees hot. Charter density and execution concurrency are

separate numbers (R11); prove the mechanism at a verifiable scale.

• Never start or restart the zero web server. The owner does that.

0.3 Definitions

1. The closed loop (the thing being built)

Every arrow above already has an implementation except assign-to-employee, the reviewer's

claim check, and the heartbeat.

2. Existing machinery — inventory (verified; do not reinvent)

Rule: if a requirement below can be met by composing something in this table, compose it.

Adding a parallel implementation of anything listed here is a defect, not a feature.

3. Requirements

Each requirement is testable. An agent that cannot demonstrate the acceptance criterion has not

met it, and must report it as unmet rather than assumed.

R1 — The employee class

A new class employee, thin, composed from §2. Every employee object carries:

Acceptance: zero employee.<view> renders an employee offline showing role, manager, budget

remaining, current task and ledger. An employee with no tasks renders honestly as idle, not as busy.

A merely chartered employee is labelled not executable; readiness is derived from its live seat,

executor policy and canonical allowance, never stored as another status flag.

R2 — Chief-of-staff, by composition

Supervision comes from the existing staff_catalog on role (lead, reviewer, coordinator,

mentor, assistant), resolved via _staff_catalog per thing/STAFF.md precedence.

• Default scope is per team, not per employee. One lead + one reviewer may cover many workers.

• Do not instantiate five staff things per employee.

Acceptance: a team's chief-of-staff resolves through the existing resolver with no new catalog

mechanism; the staff board shows the correct one of the three documented states (needs-none /

assemble / active).

R3 — Hiring recurses on budget

employee.hire — an employee with sufficient budget charters a subordinate (via thing.charter)

and allocates it a slice of its own zeros (via zeros.allocate).

• The subordinate is a full employee and may hire in turn.

• Recursion terminates when a branch's budget is exhausted. No depth limit, no headcount constant.

• A hire that would exceed the parent's remaining budget is refused, not truncated silently.

Acceptance: starting from one budgeted CEO employee, a multi-level org appears with no

hard-coded depth; total allocated ø across all descendants never exceeds the root allocation; the

refusal path is demonstrated.

R4 — Budget is real, and it is the only throttle

Zeros map to measured provider-token usage, not decoration. Employee adapter runs are the

metered subset of delegate: an employee envelope declares a positive max_tokens and the

employee carries an owner-set positive employee_rate_h (ø hundredths per provider-reported

token).

• Before provider dispatch, reserve max_tokens × employee_rate_h with _zcharge on the

canonical zeros ledger. An employee whose remaining allowance cannot cover that maximum stops

before provider work.

• Only adapters with an authoritative normalized provider usage receipt can run an employee task.

Missing receipts reject the result and refund the full unverifiable hold.

• Settle a valid in-cap receipt from the hold and _zcredit the unused difference on the same

canonical ledger. A receipt above the declared cap is rejected and the full hold is refunded:

the system never records an uncollectable actual charge.

• Task activity records reservation, measured cost, refund, receipt, and gate result, but is never

a second money ledger.

Acceptance: a deliberately under-budgeted employee is refused before provider dispatch, with

the refusal visible in its ledger and org view. A valid receipt spends only its measured tokens and

refunds the unused reservation; no employee task runs on an empty envelope.

R5 — Assignment

An open task is matched to an employee by role, capacity and budget, then recorded on work.

Reuse work.post / accept / submit / approve; add no parallel queue.

Acceptance: a posted task reaches exactly one employee, appears on the org view under that

employee, and an unassignable task stays visibly open rather than vanishing.

R6 — Projects, plans and recursive division

All work enters as a project — a gate of conditions (project/DOMAIN.md). A project too large for

one employee is decomposed into sub-projects, each itself a gate, assigned down the org. Reuse

thing/_plan_generate and _due_plan for plan generation; controller to run many gates at once.

• Decomposition is recursive and terminates when a leaf is a single assignable task.

• A project is done exactly when its conditions are met — nothing else changes.

Acceptance: one large project decomposes to leaves across at least two org levels; closing all

leaf conditions closes the parent gate with no extra bookkeeping.

R7 — Execution

An employee doing work = delegate.create + delegate.run under its own budget and adapter, with

its team's reviewer as the gate. Existing delegate guarantees are preserved exactly: disposable

full-copy variant, never the live store or ~/.zero; guards for off-target write, budget, no-op and

whitewash; _gate_variant behaviour + architecture checks; never self-applies.

Acceptance: a real task runs end to end and produces a proposal in contrib; the live store is

provably untouched until acceptance.

Observation: every direct or employee-originated coding run is stored once under Delegate and is

visible at /delegate. /<employee>/content shows that employee's scoped activity and opens the exact

/delegate/task?id=... evidence; an eligible task opens its exact /contrib/view?id=... proposal. This

does not yet stream provider tokens/tool calls like Codex, Claude Code or OMP—the durable task currently

exposes created/reserved and the settled QA/review/cost outcome.

The public and autonomous door is the same employee.execute action. The universal loop supplies its

ordinary one-string JSON argument; caps_gated_extra=execute stages a human approval, and the action

then rechecks seat_state=active before it enters the existing delegate/work switch. Company autostaff

must therefore birth AI incumbents as class=employee, not generic thing objects that miss this

contract.

R8 — The reviewer verifies claims (load-bearing)

qa.run validates behaviour. It cannot catch a worker that writes confident prose about

capability that does not exist — and that is this system's characteristic failure mode.

• The chief-of-staff reviewer must verify factual claims against the target's real action files

before accepting output.

• When a worker cannot determine what something does, the correct output is an honest

status = stub, not a guess.

• A rejected claim is recorded in the ledger with its reason.

Acceptance: a seeded task whose output contains an unsupported capability claim is rejected

by the reviewer, and the rejection with its reason appears in the ledger.

R9 — Acceptance and publish stay fail-closed

All output routes through govern: propose → review → modify/comment → accept (grant-checked,

N-approval) → publish only when the target's publish policy is satisfied. Nothing self-publishes.

Because the fleet generates volume, define change classes: a narrow, low-risk class (e.g.

additive metadata in defaults.data) may be batch-approved under an explicit guard; everything else

keeps per-item approval. The guard must be stated in the class definition, not implied.

Acceptance: an unapproved or under-approved publish is refused; the batch-approval path is

demonstrably limited to its declared change class and cannot be widened at runtime.

R10 — Legibility: the ledger and the org view

A person must be able to open the org and understand who is doing what, and what it cost,

without reading code: company → department → team → employees, each showing role, manager, budget

remaining, current task, and its ledger.

Reuse company's existing org chart, roster and brief. Add no parallel org store.

Acceptance: a reader who has never seen the code can name, from the UI alone, what any given

employee did last, whether it passed review, and what it cost.

R11 — Chartered vs active

The two numbers must never be conflated in any view or report:

• chartered — employees that exist (cheap: objects and ledger rows);

• active — employees executing now (costly: gated by R4 budget and adapter concurrency).

Acceptance: every scale figure the system reports is labelled as one or the other, and the

measured ø cost per employee-task is reported alongside so scale-up is arithmetic, not assertion.

R12 — The heartbeat (currently nothing fires the cycle)

thing/_live_cycle and the _*_tick bodies exist, but no scheduler drives them. Build the

driver: a bounded, idempotent cycle that wakes the org, advances gates, assigns open work, collects

finished work, and stops cleanly.

• Bounded per tick by budget and by a max-active cap.

• Idempotent: a tick that fires twice does not double-spend or double-assign.

• Externally stoppable: a single command halts the fleet.

Acceptance: with the owner typing nothing, a chartered org advances a project by at least one

condition per tick, and the stop command halts all activity within one tick.

R13 — Client zero is this repo

The company's first client is itself. The repo's own backlog becomes projects, decomposed per

R6 and assigned to teams, including work on the repo's own classes.

Acceptance: at least one real repo improvement is delivered by an employee through the full loop

(R6 → R7 → R8 → R9) with no human authoring the change.

R14 — The human-fill seam

Every employee slot must be fillable by a person later: same role, same brief, same ledger, only

the executor differs. fill = human may route to work as a stub — but the field, the brief and the

ledger shape must be identical from day one. This is the augmentation and cost thesis; it is

near-impossible to retrofit once thousands of employees exist.

Acceptance: flipping one employee to fill = human leaves the org view, brief and ledger

structurally unchanged, with the task appearing on the work board instead of an adapter.

R15 — Disclosure

A per-employee disclose flag controls whether a worker identifies as AI when in direct

conversation with a person. Default on for outward-facing roles. Several jurisdictions require

bot disclosure in direct interaction, and the downside is asymmetric — this is config now so it is

never a retrofit. It does not affect internal execution or how work is composed.

Acceptance: the flag exists per employee, defaults on for outward-facing roles, and is

respected wherever an employee speaks to a person.

4. First production workload — the stores catalog

Once the loop is green (R1–R13), the fleet's first real job is the catalog. This both proves the

company and produces the store.

4.1 The trap to avoid

We have attempted a catalog 10–15 times; each attempt produced another view over another partial

dataset. The truth about a thing is now smeared across defaults.data, DOMAIN.md,

<class>.feature, docs/, guide/, menu, apps, classes, browse, catalog and the

storefront. Do not create a new dataset or a new browser. Fill the gaps in the existing

per-thing files and make stores render those.

4.2 Verified state — do not re-derive

• 434 class dirs; 426 have defaults.data; most have DOMAIN.md and a .feature.

• Only 178 declare sellable; only 111 declare tags. That gap is the work.

• stores/_s_catalog.action already groups by the 15 areas in guide/groups.jsonl, reading the

published _catalog index with a local fallback. _s_detail, _s_card_render,

_s_need_license exist — extend, do not fork.

• license/ already implements personal < professional < enterprise, priced in zeros, enforced by

_core/_lic_gate.

• delegate/_variant full-copies the store per task — batch N things per variant or the cost is absurd.

4.3 Per-thing manifest (in that class's own defaults.data; never overwrite a better value)

• title, icon, blurb (one line), about (a real paragraph — what it does and for whom)

• tags — pipe-separated, generous (6–12): capability, domain, persona, industry, interface

(app / organ / document / API), lifecycle. Tags are the discovery substrate; over-tag deliberately.

• license tier — which tier it needs and why, in one clause. A consumer running IM chat, reels or

ordering from a commerce app stays personal; a blog, firm tooling, or anything serving external

users demands higher. Mark genuinely dual-use things as dual-use rather than forcing a tier up.

• earning side — if using the thing can *earn* its holder money (marketplace, matchmaking,

supply-side, agency, partner work), declare it. A license governs how you may earn, not only what

you may run. Extend license's vocabulary; do not add a second permission system.

• org — the owning company → department → team (ties the catalog to R10).

• docs / refs — links to everything that already documents the thing: its DOMAIN.md, its

.feature, anything under docs/, plus genuinely-used external references. Consolidating these

is the entire point.

• status — honest: live | store-only | partial | stub.

4.4 Storefront

stores becomes the primary discovery surface over that manifest: browse by area, plus filter

and search by tag, license tier, owning team and status; detail pages showing the full manifest with

clickable tag facets and consolidated doc links; every thing listed — not only sellable ones —

with honest status rather than hiding.

4.5 Truthfulness

R8 applies with full force here. One fabricated capability makes the whole catalog worthless, and a

catalog nobody trusts is worse than no catalog. Every worker reads a thing's actual action files

before describing it.

5. Phasing and exit criteria

Do not begin a phase before its predecessor's exit criterion is demonstrated. If a phase cannot be

completed, finish every independent phase and report the blocked one explicitly.

6. Known risks — decide these, do not discover them at task 200

1. Approval bottleneck. delegate never self-applies. 430 tasks = 430 approvals unless the R9

change-class batching is defined first.

2. Variant cost. A full store copy per task does not scale to hundreds; batch.

3. Reviewer is the quality ceiling. Everything the reviewer waves through becomes the product.

Weak review produces a large, confident, wrong catalog — the worst outcome available.

4. Budget must bind to real spend. If ø is decorative, there is no throttle and R4 is theatre.

5. Runaway hiring. Budget is the only terminator; verify the refusal path before running hot.

6. Idempotency of the tick. A non-idempotent heartbeat double-spends. Test a double-fire.

7. Verification and reporting

• Verify renders offline with zero <class>.<action>. Never start the server.

• .data files: edit with bash/python — the file tools refuse them.

• Keep DOMAIN.md in sync for every class whose surface changes.

• Parallelise the §4 sweep across subagents; every worker reads the real files before describing.

Final report must state:

• Employee loop: chartered count, active count, measured ø per task, what the reviewer rejected

and why.

• Catalog coverage against 434, naming what is still thin.

• Every duplicated catalog dataset found, and which one was made canonical.

• Each requirement R1–R15 as met / unmet, with evidence for met and a reason for unmet.

• Anything unverified stated as unverified. No fabricated numbers — swarm's standing rule.