Open Airchor

THE AIRCHOR VISION

AI made implementation faster. The lifecycle still needs control.

Airchor is being built to make AI-assisted software development understandable, coordinated and verifiable from the first idea to continued operation.

Explore the Control PlaneView the Roadmap
Human intent
Airchor Control PlaneIn active development
Bounded execution
Evidence · verification · continue
The Control Plane is the shared layer above people, agents, repositories and providers. Individual connections retain their published capability state.

FROM GENERATION TO GOVERNED DEVELOPMENT

Generated code is only one part of building software responsibly.

Software still depends on product intent, architecture, evidence, permissions, ownership, testing, release decisions and continued maintenance. When these remain scattered across chats, repositories and provider dashboards, faster implementation can increase rather than reduce delivery risk.

Airchor’s purpose is to connect those parts into one controlled project lifecycle.

Generated codeOne output
  1. Product intent
  2. Architecture
  3. Evidence
  4. Permissions
  5. Testing
  6. Release decisions
  7. Maintenance

One controlled project lifecycle

In active development

THE MISSING CONTROL LAYER

Agents and tools need a shared project state above them.

Coding agents, models, IDEs, repositories, hosting platforms and human teams each expose part of the work. None of them should become the only place where the project’s intent, decisions and delivery truth live.

The Airchor Control Plane sits above the execution layer. It maintains the Project Model, coordinates work, records evidence and keeps the next decision visible while providers perform the tasks they are authorised to perform.

Origin 01Create from an ideaProblem · users · outcome · constraints
Origin 02Import existing softwareCode · evidence · decisions · open issues
In active development

DURABLE PROJECT TRUTH

One Project Model

  • Intent
  • Sources
  • Decisions
  • Risk
  • Evidence
  • Next action

Next actionReview a bounded plan

  1. 01Ask
  2. 02Plan
  3. 03Execute
  4. 04Verify
AgentsHumansExternal systemsEvidence
Two ways of starting a project feed one Project Model, which coordinates planning, work, evidence, verification and continued development.
In active development

ONE PROJECT MODEL

Project truth should survive changing tools and people.

The Project Model brings together accepted goals, requirements, sources, decisions, assumptions, evidence, plans, implementation state and release history.

It is designed to preserve provenance and change history so that a new model, developer, agency or provider can continue from the current project state rather than reconstructing the project from fragments.

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.
In active development

COORDINATION INSTEAD OF FALSE AUTONOMY

The complete workflow matters more than the appearance of full automation.

Some work can be automated reliably. Some work needs assistance, human authority, approval, review or an external provider. Some work is unsupported.

Airchor’s governing principle is simple: automate what can be automated and orchestrate what cannot. The responsible actor and automation level should remain visible, and dependent work should not advance on a false completion claim.

In active development

CONTROL PLANE WORK ITEM

Deliver one approved change

Scope
One bounded result
Coordinator
Airchor Control Plane
State
Waiting for coordinated work
Dependency
Approved Build Specification
Evidence
Task, human and provider records
Next action
Verify the complete result

AGENT TASK · SPECIALISED EXECUTION OBJECT

Implement the approved technical scope

State
Awaiting verification
Current step
Evidence handoff
Completed
Plan followed · Change reported
Pending
Independent verification
Evidence
Changed files and command results
Human action

Review the exact result

Actor
Reviewer
Mode
Assisted
Instruction
Compare the result with the approved scope.
Evidence
Recorded review decision
Resumes
Verification and Preview path

EXTERNAL-SYSTEM STEP

External provider

Responsible actor
External provider
Required input
Exact approved operation
Returned evidence
Correlated provider result
State
Waiting
Boundary
Outside Airchor execution
A Work Item is the parent coordination envelope. Agent Tasks and their execution records remain distinct from human actions, external operations and verification.
In active development

HUMAN AND AGENT COLLABORATION

People remain part of the control system.

Founders define goals and approve material decisions. Developers and agents perform bounded technical work. Reviewers inspect evidence. Account owners complete protected external actions. Approvers control release effects.

Airchor is designed to make these responsibilities explicit, reduce unnecessary handoffs and keep the workflow resumable after every human or external step.

In active development
  1. AI agentPerform bounded approved workTask evidence
  2. HumanApprove, review or provide evidenceRecorded decision
  3. External systemPerform provider-controlled operationCorrelated result

Human confirmation, provider completion and independently verified completion remain separate states.

Non-automatable work stays visible, instructed, evidenced and resumable inside the same project workflow.
On the roadmap

EVIDENCE AND VERIFICATION

Progress should be supported by the evidence appropriate to the claim.

A project may need source evidence, changed files, commands, test results, review decisions, preview evidence or deployment records. Airchor is designed to connect the claim, the actor and the evidence without forcing every visitor to operate at the deepest technical level.

Independent verification is a distinct roadmap capability because the actor that produced a result should not be the only basis for accepting it.

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.
Long-term direction

CUSTOMER CONTROL AND PORTABILITY

The project should remain portable beyond one model, agent or vendor.

Airchor’s architecture is directed toward customer-controlled repositories, provider accounts, domains, deployments and project assets. The Project Model provides continuity across those systems.

Provider neutrality does not mean every provider is already connected. It defines how Airchor should expand: through bounded adapters, explicit permissions and preserved customer ownership.

Governing product direction

CUSTOMER-CONTROLLED FOUNDATIONS

  • Code
  • Repositories
  • Provider accounts
  • Domains
  • Deployments
  • Project assets

CUSTOMER-CONTROLLED FOUNDATION

Project continuity

Custodian
Customer
Provider category
Generic, replaceable connections
Portability direction
Designed to preserve project truth across tools
Airchor boundary
Airchor coordinates; individual integrations follow the roadmap
Model providerRepository providerDeployment provider
Airchor is being designed around customer control and provider-neutral coordination. The scene does not imply that every integration is currently available.
Foundation established

THE ESTABLISHED FOUNDATION

MVP v1.0 proved the first structured project layer.

The current invitation-based product established persistent projects, two project origins, structured planning and assessment workflows, visible uncertainty, generated roadmaps and developer handoffs.

Those foundations remain valuable. The Control Plane programme extends them from structured preparation into coordinated, evidenced and verified delivery.

Foundation established
  • Persistent projects
  • Two project origins
  • Structured planning and assessment workflows
  • Visible uncertainty
  • Generated roadmaps
  • Developer handoffs

THE PATH FORWARD

Build the Control Plane in truthful stages.

The active programme establishes the unified Project Model, Source Inbox, Work Items, task visibility and Control Plane experience. Later approved stages introduce bounded execution, independent verification, Tested Preview, explicit launch control and continued development.

Longer-term expansion adds broader providers, portfolio coordination and governance without replacing the same core Project Model.

  1. 01In active development

    Control Plane foundation

    The unified Project Model, Source Inbox, Work Items, task visibility and Control Plane experience.

  2. 02On the roadmap

    Coordinated execution

    Bounded execution.

  3. 03On the roadmap

    Verified delivery

    Independent verification and Tested Preview.

  4. 04On the roadmap

    Launch and continued development

    Explicit launch control and continued development.

  5. 05Long-term direction

    Platform expansion

    Broader providers, portfolio coordination and governance.

The progression is capability-based and publishes no dates or decorative completion percentages.
Explore the Control PlaneView the Roadmap