Open Airchor

AIRCHOR FOR FREELANCERS

Define the work clearly, keep decisions visible and deliver a project that can continue.

Airchor is designed to give independent builders and clients one shared project state around scope, approvals, evidence, ownership and handoff.

Explore the Control PlaneRequest access
APPROVED DELIVERY BOUNDARYOne bounded change
Scope
Included · excluded
Client input
Decision · access · review
Evidence
Work · checks · limitations
Outcome
Acceptance · handoff
◆Material change requires approval
Scope, client inputs, evidence and ownership stay inside one visible delivery boundary; material changes return to a decision.

Informal scope becomes expensive when the project starts changing.

A freelancer may inherit incomplete context, shifting expectations and provider access that was never clearly assigned. The client may see output without understanding what was included, tested or left unresolved.

Airchor is designed to make the working boundary visible before that ambiguity becomes conflict.

In active development

Keep the client and builder aligned around the same project state.

The Project Model records accepted goals, decisions, constraints, evidence, risks and open questions. It provides a durable basis for the work that does not depend on one person’s memory or chat history.

In active development

Make the agreed change specific and versioned.

A Build Specification should define the outcome, included and excluded work, acceptance criteria, dependencies, client actions, ownership targets and evidence required for delivery.

When scope changes materially, the specification changes visibly and requires a new approval.

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.
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.

DECISION

Has the approved scope changed materially?

Choices
Continue within scope · Revise the specification · Pause
Evidence
Client decision, dependency and acceptance criteria
Outcome
Visible approval boundary
Owner
Client and independent builder
Status
Decision recorded
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.
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.
In active development

Keep client decisions inside the delivery workflow.

Content decisions, access, provider configuration, review and acceptance can become explicit Work Items with responsible actors and due evidence. The project can then show what is blocked, what is waiting and what can proceed.

On the roadmap

Explain what was done and what the evidence actually proves.

The Control Plane direction connects task progress, files, commands, tests, preview evidence and approval. Independent verification and Tested Preview remain roadmap capabilities, and their scope must be clear when introduced.

On the roadmap

Leave the client with the assets and context needed to continue.

Airchor is being designed around client-controlled repositories, providers, domains, deployments and project assets. The Project Model, Build Specification and delivery record support a cleaner handoff to the client, another freelancer or an agency.

NEXT STEP

Next step

Explore the Control PlaneRequest access