FIG. 00 — HOW WE BUILD

THE FIRM IS THE PROOF.

The only agentic system ARA can show you is its own.

Every firm now claims AI delivery capability. The proof is usually a client story you cannot verify, and ARA names no clients. That leaves the firm itself: one human principal, an orchestrator, and thirteen named specialists, built to the standard ARA argues enterprises need. Nothing in it is autonomous.

FIG. A1 — BOUNDED · THE ORG

Thirteen specialists, and not one of them chooses its own work.

ARA is one orchestrator and thirteen named specialists. No specialist can hand work to another specialist, because none of them holds the permission that would allow it, so every hand-off routes through the orchestrator. Delegation is a decision the system records, not a behavior that emerges. The hub is a deliberate bottleneck, and ARA accepts that cost for the traceability.

Routing diagram: one orchestrator hub routing goals to thirteen specialist disciplines An index lists thirteen specialist disciplines, numbered 01 to 13, each tagged with the execution role it carries: five builders, six authors, one reviewer and one control-plane engineer. To the left sits a single hub, the orchestrator, annotated "routes, never builds" and "a deliberate bottleneck". Three incoming goals — build the pipeline, design the identity, review and validate — each enter the hub and are then routed out along a single line to exactly one discipline: solution architecture, design and brand, and review and security respectively. A crossed-out dashed line between two specialists is marked "no spoke-to-spoke: no specialist holds the permission", meaning specialists cannot hand work to each other directly. There is no line anywhere between any two specialists; every hand-off returns through the hub. INTAKE THIRTEEN SPECIALISTS · ONE EXECUTION ROLE EACH 01People & orgAUTHOR 02ResearchAUTHOR 03Design & brandBUILDER 04StrategyAUTHOR 05Delivery & operationsAUTHOR 06Data scienceBUILDER 07Review & securityREVIEWER 08Solution architectureBUILDER 09Domain specialistAUTHOR 10Front-end engineeringBUILDER 11Applied AI architectureCONTROL PLANE 12EducationAUTHOR 13Platform specialistBUILDER The orchestrator ROUTES · NEVER BUILDS A DELIBERATE BOTTLENECK GOAL 01 BUILD THE PIPELINE GOAL 02 DESIGN THE IDENTITY GOAL 03 REVIEW & VALIDATE NO SPOKE-TO-SPOKE NO SPECIALIST HOLDS THE PERMISSION

←  SCROLL THE FIGURE HORIZONTALLY  →

FIG. A1 — LOOK FOR A LINE BETWEEN ANY TWO SPECIALISTS. THERE ISN'T ONE, AND THAT IS THE ARGUMENT.

FIG. A2 — ACCOUNTABLE · THE CONTROL PLANE

Every agent's capability is declared in a file the agent cannot edit.

Each file declares that specialist's tools, its permission mode, and whether it works in an isolated copy of the repository. Those settings resolve when the agent starts, not from anything it reads later. Only one specialist may write an agent definition file, and no agent, including that one, may write its own. The hook enforcing that runs before permission rules are evaluated, so no session setting overrides it. If it cannot establish who is calling, it denies.

A regression suite of 110 tests, all passing, checks that each hook still does exactly what it is supposed to. Two of the three refuse nothing by design. They are instruments rather than controls, and one of them measured a permission guarantee that was not holding. The principal accepted the trade in writing. A control nobody has measured is a belief.

Control-plane diagram: capability declared per execution role, one blocking control and two measuring instruments Upper half: a table of four execution roles against four capabilities. Builders, five specialists, may write, execute, and work in an isolated worktree, but not in the main tree. Authors, six specialists, may write only. The reviewer, one specialist, may write and execute in the main tree with no worktree. The control-plane engineer, one specialist, may write and execute in the main tree, scoped. Every setting is declared in the agent's own definition file and resolves when the agent starts, never from anything read at runtime. Five plus six plus one plus one equals thirteen. Lower half, an instrument bench: exactly one control and two instruments. Control 01, the agent-definition write guard, permits only one specialist to write an agent definition file and permits none of them, including that one, to write its own; it runs before permission rules are evaluated so no permission mode overrides it; an attempted write is shown arriving and being stopped. Instrument 02, the subagent spawn mode guard, only measures whether the permission mode held; its readout sits at "not holding", a result that was measured, logged, and accepted in writing by the principal. Instrument 03, the prompted write guard, only measures whether a write was prompted; its readout sits at "not prompted", because it returns an ask which for a background agent resolves permissively. Neither instrument blocks anything. A regression suite of 110 tests passes with zero failures, and one of its cases asserts that the advisory guard cannot block. DECLARED IN .claude/agents/<role>.md · RESOLVED AT SPAWN, NEVER READ AT RUNTIME WRITE EXECUTE WORKTREE MAIN TREE Builders 5 SPECIALISTS Authors 6 SPECIALISTS Reviewer 1 SPECIALIST Control plane 1 SPECIALIST SCOPED FOUR EXECUTION ROLES. EVERY SPECIALIST CARRIES EXACTLY ONE. 5 + 6 + 1 + 1 = 13 ONE CONTROL. TWO INSTRUMENTS. THE DIFFERENCE IS DELIBERATE. CONTROL 01 · BLOCKS agent-definition-write-guard.sh .claude/agents/ <role>.md NO AGENT WRITES ITS OWN DEFINITION. NOT EVEN THE ONE WHO WRITES THEM. IT RUNS BEFORE PERMISSION RULES ARE EVALUATED, SO NO MODE OVERRIDES IT. INSTRUMENT 02 · MEASURES subagent-spawn-mode-guard.sh DID THE PERMISSION MODE HOLD? NOT HOLDING HOLDING MEASURED, LOGGED, AND THE PRINCIPAL ACCEPTED THE TRADE IN WRITING. THIS HOOK BLOCKS NOTHING. EVERY PATH EXITS ZERO, BY DESIGN. INSTRUMENT 03 · MEASURES prompted-write-guard.sh WAS THE WRITE PROMPTED? NOT PROMPTED PROMPTED IT RETURNS AN ASK, WHICH FOR A BACKGROUND AGENT RESOLVES PERMISSIVELY. AN OBSERVER, NOT A CONTROL. 110 PASSED · 0 FAILED THE GUARDS ARE REGRESSION-TESTED. ONE CASE ASSERTS THE ADVISORY GUARD CANNOT BLOCK.

←  SCROLL THE FIGURE HORIZONTALLY  →

FIG. A2 — ONE OF THE THREE HOOKS BLOCKS. THE OTHER TWO ONLY MEASURE, AND ONE MEASURED SOMETHING ARA DID NOT LIKE.

FIG. A3 — GROUNDED · THE SELF-IMPROVING SDLC

ARA designed this lifecycle to self-improve, then instrumented it to find out.

Work starts with an interview, not a prompt. The goal becomes a written plan with verifiable success criteria, and a human approves it before anyone builds. Every phase has to pass its own criteria.

Nothing reaches a client until it has passed a review with a recorded verdict, and that review is required rather than a courtesy pass. A rejection goes back to the specialist who produced the work and is re-gated rather than waved through. The reviewer's mandate is to author findings rather than the work under review, and the orchestrator never routes a deliverable back to its own author.

Dial diagram: the build protocol as a loop that closes on itself, with the human approval point marked A measured dial with five stations set 72 degrees apart around its rim. 01 interview, scaled to size and never skipped. 02 approved plan, with numbered phases and an owner per step; this station is bracketed and marked "a person approves here", and it is the point at which a human has to say yes before anything is built. 03 small steps, one phase at a time with the result back before the next. 04 the review, required, returning a recorded verdict. 05 reuse, cite the library and log the citation. The arc draws station by station, and the final segment from reuse back to interview closes the loop. A chord inside the dial runs from the review back to small steps, marked "reject returns into the loop", because remediation goes back to the specialist who produced the work and is re-gated rather than waved through. At the dial's centre sits phase zero, call the task. Below, the review's three verdicts are listed: approve, approve with conditions, and reject with remediation. As of 2026-08-06, forty-one library deposits and twelve captures exist, and every gated deliverable leaves a capture answering four fixed questions. The reuse counter reads one: the log's first entry was made on 2026-08-05, from the audit this page's fact check triggered, and one is not a track record. ARA logs whether the next project actually cites a deposit, and depositing is not reuse, because a reuse number worth trusting cannot be backfilled. PHASE 0 Call the task WORKTREE · CLEAR · STAY 01 · INTERVIEW SCALED TO SIZE. NEVER SKIPPED. 02 · APPROVED PLAN NUMBERED PHASES · OWNER PER STEP A PERSON APPROVES HERE 03 · SMALL STEPS ONE PHASE. RESULT BACK. 04 · THE REVIEW REQUIRED · RECORDED VERDICT 05 · REUSE CITE IT. LOG THE CITATION. REJECT RETURNS INTO THE LOOP THE REVIEW RETURNS ONE OF THREE APPROVE APPROVE WITH CONDITIONS REJECT WITH REMEDIATION 41 LIBRARY DEPOSITS · 12 CAPTURES · 2026-08-06 EVERY GATED DELIVERABLE LEAVES A CAPTURE ANSWERING FOUR FIXED QUESTIONS. ONE IS NOT A TRACK RECORD. REUSE EVENTS LOGGED 1 FIRST ENTRY 2026-08-05, FROM THE AUDIT THIS PAGE'S FACT CHECK TRIGGERED. DEPOSITING IS NOT REUSE. A COUNT WORTH TRUSTING CANNOT BE BACKFILLED.

←  SCROLL THE FIGURE HORIZONTALLY  →

FIG. A3 — THE REJECT PATH RETURNS INTO THE LOOP. A REVIEW THAT ONLY EVER APPROVES IS DECORATION.

FIG. 04 — CONTACT

Ask whoever is building your agents to show you their version of this page.

hello@ara-data.com