Open Airchor

THE AIRCHOR CONTROL PLANE

One structured system around the complete software-development lifecycle.

Airchor brings project sources, decisions, plans, work, evidence, and delivery status into one unified Control Plane. Whatever the starting point, every project follows a shared Project Model—creating clarity around what comes next, how work is coordinated, and where progress needs to be reviewed.

Request accessView the Roadmap
Security and Privacy
  1. 01Sources
  2. 02Project Model
  3. 03Plan
  4. 04Work
  5. 05Evidence
  6. 06Verify
  7. 07Preview
  8. 08Launch
  9. 09Continue
Project sources move through one Project Model into bounded work, evidence, review and continued development. Later stages remain on the roadmap.
Foundation established

ONE CONTROL PLANE

Begin with an idea or import existing software.

New products and existing projects need different intake questions, but they should not become separate systems. Airchor preserves two clear origins:

Both origins converge into one Project Model and one continued development lifecycle.

  • Create from an idea — begin with the problem, users, intended outcome, constraints and available evidence.
  • Import existing software — bring the context needed to understand a prototype, inherited application or active software project.
Foundation established

PROJECT ORIGIN

Create from an idea

Source
Founder or product owner
Role
Problem, users, intended outcome and constraints

DURABLE PROJECT TRUTH

One Project Model

  • Accepted intent
  • Evidence
  • Decisions
  • Unknowns
  • Current state

Next actionOne continued development lifecycle

Foundation established

PROJECT ORIGIN

Import existing software

Source
Customer-controlled project sources
Role
Code context, screenshots, documents and decisions
Different intake questions preserve each project origin while both routes converge into one Project Model and one continued development lifecycle.
In active development

SOURCES BEFORE ASSUMPTIONS

Bring the material that explains the project into one intake surface.

The Source Inbox is being designed as the unified entry point for project material: documents, screenshots, images, URLs, supplied notes, decisions and, as approved integrations develop, repository and provider context.

Sources remain distinct from accepted project facts. Airchor should record where information came from, whether it is observed or claimed, and whether it has been accepted into the Project Model, retained as supporting evidence or rejected.

The current product accepts structured project context through its established workflows. A unified mixed-source inbox and repository-aware intake are not presented as available today.

In active development
DocumentScreenshotURLSupplied noteDecisionRepository context · roadmap
  1. 01Received
  2. 02Classified
  3. 03Reviewed
  4. 04Linked
  5. 05Project Model

Sources remain separate from accepted facts; unified repository-aware intake is not shown as available today.

The Source Inbox keeps provenance and review state visible before material becomes accepted Project Model truth.
In active development

DURABLE PROJECT TRUTH

Turn scattered context into one Project Model.

The Project Model is the durable representation of accepted project intent, decisions, requirements, evidence, plans, implementation state and release state.

It separates facts from assumptions, records confidence and risk, keeps missing information visible and links decisions back to their sources. When new evidence changes the understanding of the project, the model should update through a visible decision rather than silently rewriting history.

Known facts

Accepted and supported

Claims

Attributed, not silently accepted

Assumptions

Visible and reviewable

Missing information

Kept open

Risk

Qualified by evidence

SourceProvenance retainedReviewDecision visible
Project understanding distinguishes evidence-backed facts from attributed claims, assumptions, uncertainty and missing information.
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, with execution and independent verification introduced through later roadmap stages

DISTINCT COMMAND INTENTS

Ask, Plan, Execute and Verify are different kinds of work.

Airchor is designed to infer the right intent where possible while keeping changes, approvals and external effects explicit.

  • Ask — Explore the project, explain context and answer questions without changing the project or external systems.
  • Plan — Propose an ordered path, surface assumptions and define what approval is required.
  • Execute — Perform eligible, bounded work through an approved task and declared permissions.
  • Verify — Test a result against acceptance criteria and supporting evidence independently from the actor that produced it.
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 development

FROM PROJECT STATE TO ACTION

Make the next step specific enough to review and execute.

A useful next action depends on the current Project Model, not on the last chat message. Airchor is being designed to recommend the next-best action based on project goals, evidence, dependencies, risk and unresolved decisions.

When implementation is appropriate, that action becomes a Build Specification: a bounded, versioned description of scope, exclusions, acceptance criteria, ownership targets, dependencies, permissions and evidence requirements.

A material change creates a new version. Approval applies to the version that was reviewed.

Next-best actionPrepare a bounded implementationBased on current Project Model state
In active development

BUILD SPECIFICATION · VERSIONED

Approved scope for one Build

  1. 1Objective
  2. 2Scope and exclusions
  3. 3Acceptance criteria
  4. 4Constraints
  5. 5Evidence requirements
  6. 6Human approvals
  7. 7Provider boundary
The Build Specification turns a selected next action into a bounded, versioned and reviewable execution contract.
In active development

THE UNIT OF COORDINATED WORK

Every material action becomes a visible Work Item.

A Control Plane Work Item represents the work that must happen, who or what is responsible, what it depends on and what evidence is required before it can be treated as complete.

Each Work Item should expose its actor and automation level: autonomous, assisted, manually orchestrated or unsupported.

  • agent execution
  • an Airchor-controlled system operation
  • a human action
  • an approval
  • a review
  • an external-system operation
  • an evidence request
  • a waiting dependency
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.
Task experience in active development; live provider execution on the roadmap

SPECIALISED EXECUTION WORK

Agent Tasks show what an AI agent is actually doing.

An Agent Task is a specialised Work Item for approved technical execution. Its visible state should include the plan, current working step, completed and pending work, blockers, controls and produced evidence.

The interface is designed to distinguish between a task being planned, approved, running, paused, blocked, awaiting review, awaiting verification, completed or failed. Real provider execution is introduced only through separately approved roadmap stages and permissions.

Task experience in active developmentProvider execution on the roadmap

AGENT TASK · SPECIALISED EXECUTION OBJECT

Implement approved Build Specification

State
Completed · verification required
Current step
Hand off evidence
Completed
Bounded change · Declared checks
Pending
Independent verification · Review
Blocker
None reported
Evidence
Files, commands, tests and events
  1. 01Plan accepted
  2. 02Task started
  3. 03Evidence captured
  4. 04Blocker raised
  5. 05Human response
  6. 06Task completed
  7. 07Verification required
Agent Task activity is shown through durable state, normalised events and evidence—not fabricated percentages, hidden reasoning or simulated live activity.
In active development

ORCHESTRATION BEYOND AUTOMATION

Work does not disappear when a human or external system is required.

Account ownership, MFA, legal acceptance, billing approval, provider-console configuration and stakeholder review may require a person or a system outside Airchor.

Airchor is being designed to create a clear Work Item for that step, identify the responsible actor, provide bounded non-coder instructions, request the minimum evidence, verify the result where possible and resume dependent work without losing context.

Human confirmation and independently verified completion remain separate states.

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.
In active development and on the roadmap according to evidence type

CONTROL FIRST, DETAIL WHEN NEEDED

Stay at the project-control level or inspect the technical evidence.

The primary interface should explain what is happening, why it matters and what decision is required. Technical users can progressively open the deeper layer: files, diffs, commands, tests, Git state, provider events, preview details, deployment records and logs.

This separation helps non-coders remain in control without hiding the evidence developers and reviewers need.

  1. 01

    Claim

    Attributed statement

  2. 02

    Source

    Provenance recorded

  3. 03

    Evidence

    Relevant artefact

  4. 04

    Check

    Criterion evaluated

  5. 05

    Conclusion

    Scope-qualified result

SourceProvenance visibleTestResult recorded
Evidence supports a check; neither an artefact nor a checkmark becomes a blanket verified conclusion by itself.
On the roadmap

COMPLETION IS NOT VERIFICATION

Check the result against the approved specification.

An agent can report that its work is complete. Verification asks a different question: does the result satisfy the acceptance criteria, and what evidence supports that conclusion?

Airchor’s roadmap separates execution from verification, records failures and retries, and links each verified claim to the relevant checks and evidence. Verification scope remains explicit; a passed check does not become a blanket security, legal or Production-readiness claim.

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

A REVIEWABLE DELIVERY BOUNDARY

Review a verified result before deciding whether to launch.

Tested Preview is the planned state in which the approved checks have passed, the preview and evidence are available and the result is waiting for user review.

It is distinct from task completion, checks passed, Build Complete and Production deployment. The user can inspect the result, review the Build Specification and evidence, request changes, approve the milestone or stop the release path.

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.
On the roadmap

DELIVERY IS A DECISION, NOT AN AUTOMATIC SIDE EFFECT

Launch deliberately, then continue from the updated project state.

Production launch should require an explicit, authorised release decision. Airchor is being designed to preserve the approved source, deployment evidence, post-launch verification and resulting project state.

After launch, the Project Model remains active. New evidence, issues, maintenance needs and product decisions become the basis for the next plan rather than starting again from an old conversation or handoff bundle.

On the roadmap
  1. 01Verified preview
  2. 02Explicit approval
  3. 03Launch operation
  4. 04Post-launch evidence
  5. 05Updated Project Model
  6. 06Continue
Production follows an explicit authorised release decision. Launch evidence updates the same Project Model so continued development begins from current truth.
Governing product principle; integrations follow the roadmap

CUSTOMER-CONTROLLED FOUNDATIONS

Coordinate the project without surrendering ownership of it.

Airchor is being designed so that customer-controlled code, repositories, providers, domains, deployments and project assets remain the durable foundations of the software.

The Control Plane should coordinate multiple agents and systems without making project continuity dependent on one model or provider. This principle does not imply that every repository, deployment or provider integration is currently available.

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.

CURRENT AVAILABILITY

Current availability

  1. 01Available now

    Available now

    Create or assess a software project, organise supplied context, make evidence, assumptions, risk and missing information visible, and produce structured planning, roadmap and handoff outputs inside an invitation-based workspace.

  2. 02Foundation established

    Foundation established

    Persistent projects, saved workflow state, generated project documents, readiness and uncertainty concepts, individual Markdown downloads, and two proven project origins provide the operational base for the Control Plane transition.

  3. 03In active development

    In active development

    The unified Project Model, Source Inbox, next-best action, Build Specifications, Control Plane Work Items, visible task orchestration, human-action coordination and the new Control Plane experience.

  4. 04On the roadmap

    On the roadmap

    Bounded provider execution, repository-aware work, independent verification, Tested Preview, explicit launch control and continued development from the same Project Model.

  5. 05Long-term direction

    Long-term direction

    A longer-horizon direction rather than a current capability.

The progression is capability-based and publishes no dates or decorative completion percentages.
Available now

Airchor MVP v1.0 provides the live, invitation-based foundation for structured project creation, project assessment, visible uncertainty, planning, roadmaps and developer handoffs. The unified Control Plane is being introduced through the published development roadmap.

INVITATION-BASED ACCESS

Request access to the current Airchor foundation

The current application is available by invitation. Tell us who you are, what stage your software project is in and why you are interested in Airchor. Do not send credentials, private source code, repository archives, raw Production logs or confidential client information.

Submitting a request does not create an account or guarantee immediate access. Existing invited users can sign in or open the application directly.

Request accessView the Roadmap