Open Airchor
In active development

AIRCHOR FOR AI BUILDERS

Keep AI coding work connected to the project it is meant to advance.

Airchor is building the durable control layer around agents, repositories, technical evidence and release decisions so that progress can continue beyond one prompt, session or provider.

Explore the Control PlaneView the Roadmap
Prompt sessionCoding agentRepository contextProvider event
PERSISTENT PROJECT TRUTHOne Project Model
  1. ASKInvestigate
  2. PLANBound the change
  3. TASKExpose real state
  4. EVIDENCESupport review
The Project Model preserves intent across sessions while the task record exposes bounded state and evidence.

A useful coding session is not a durable project system.

Prompts, plans, diffs, commands and test results can remain trapped inside one tool or session. The next agent may not know why a decision was made, which assumptions remain open or what acceptance criteria actually control the task.

Airchor is designed to preserve that context in the Project Model and connect each technical action to an approved project state.

In active development

Keep intent and evidence independent of the current agent.

The Project Model records accepted requirements, architecture decisions, constraints, sources, plans, evidence and release state. Agents and providers can contribute work without becoming the sole owner of project truth.

Repository and provider connections follow the roadmap and must use explicit permissions and customer-controlled accounts.

In active development

Explore safely, then approve the bounded change.

Ask should support investigation and explanation without mutation. Plan should organise the proposed work, dependencies, assumptions and checks. Execute should require an eligible Build Specification, declared permissions and an approved task.

This separation reduces accidental scope drift and makes the execution boundary reviewable.

In active development

Show real task state instead of a persuasive progress animation.

An Agent Task should show the ordered plan, current working step, completed and pending work, changed files, commands, tests, blockers and controls. Pause, stop, retry, review and replacement states should reflect real task events.

The task experience is in active development. Live provider execution is introduced only through separately approved roadmap stages.

In active development

DURABLE PROJECT TRUTH

One Project Model

  • Product intent
  • Scope
  • Requirements
  • Architecture
  • Sources and evidence
  • Decisions
  • Risk and unknowns
  • Ownership and connections
  • Current state
  • Next action

Next actionVisible, reviewable and version-aware

The Project Model is a conceptual durable record of accepted project intent, sources, decisions, evidence, current state and next action.
ONEProject Model
  1. 01Foundation established

    Ask

    Read the Project Model and evidence.

  2. 02In active development

    Plan

    Create a bounded approach.

  3. 03On the roadmap

    Execute

    Coordinate approved Work Items.

  4. 04On the roadmap

    Verify

    Evaluate evidence against criteria.

Ask reads, Plan proposes, Execute performs eligible bounded work and Verify independently checks results. The four intents do not share one completion state.
In active developmentOn the roadmap

AGENT TASK · SPECIALISED EXECUTION OBJECT

Bounded Agent Task

State
Event-derived state
Current step
Visible current step
Completed
Completed steps remain explicit
Pending
Pending work remains explicit
Blocker
Visible when present
Evidence
Files, commands, tests and task events
  1. 01Ordered plan
  2. 02Current step
  3. 03Changed files
  4. 04Commands and tests
  5. 05Blockers and controls
  6. 06Evidence handoff
The task experience is in active development. Live provider execution remains on the roadmap, and the stream represents structure rather than fabricated runtime activity.
SourceScope and intentTestDeclared check resultLogExecution recordReviewHuman finding
On the roadmap

INDEPENDENT VERIFICATION RECORD

Approved acceptance criteria

Method
Independent checks and review
Evidence
Linked, attributable records
Result
Passed, failed, incomplete or blocked
Limitations
Only the declared scope
Verifier
Separate verification path
Work evidence enters a separate verification boundary; the resulting conclusion remains linked to its exact criteria, evidence and limitations.
On the roadmap

TESTED PREVIEW · NOT PRODUCTION

Tested Preview

Environment
Preview · not Production
Checks
Approved checks passed · Evidence linked
Known limitations
Known limitations remain visible
Review status
Waiting for user review
  1. Task completion
  2. Checks passed
  3. Tested Preview ready
  4. User review
  5. Separate launch decision
Tested Preview is a planned review boundary. It is distinct from task completion, Build Complete and Production deployment.

Keep the control surface readable and the evidence expandable.

Project owners can stay with the business-readable summary while developers open files, diffs, commands, tests, Git state, preview details, provider events and logs.

The two layers remain linked so that a technical event can support a user-facing status without pretending the event proves more than it does.

On the roadmap

Separate agent completion from an accepted build result.

Independent verification is planned to check the result against the approved Build Specification and acceptance criteria. Tested Preview is the later state in which the relevant checks have passed and the result is ready for user review.

Neither state is currently presented as live.

On the roadmap

Continue the project even when the tool changes.

Airchor is being designed around customer-controlled repositories, deployments and provider accounts. The Project Model and evidence history should allow work to move between agents, models, developers and providers without losing the project’s accepted intent.

NEXT STEP

Next step

Explore the Control PlaneView the Roadmap