Skip to main content

Operating model

This page is the product model in one place.

If you only remember one thing about AetherFS, remember this:

  • sources are reusable starting points
  • sessions are live working environments
  • forks create parallel proposals
  • checkpoints preserve recoverable milestones
  • commits or promotions create durable outcomes

Sources start the work​

A source is the reusable baseline for future sessions.

Use sources when you need:

  • repeatable starting points
  • managed baselines
  • imports from a remote or uploaded origin
  • a durable origin that outlives any one session

Sessions hold active work​

A session is where work actually happens.

Use sessions when you need:

  • file changes
  • review notes
  • local Aether CLI mounts
  • approvals
  • temporary or task-scoped workspaces

Forks split the work safely​

Forks are the cleanest way to create parallel proposals from an existing session.

Use a fork when:

  • two actors may diverge
  • you want separate review branches
  • one proposal should not destabilize the baseline

Checkpoints protect progress​

Checkpoints are recovery points inside a session.

Use them when:

  • a change is risky
  • a handoff is about to happen
  • an automation step may need rollback
  • a user wants a known-good point before continuing

Approvals gate important actions​

Approvals are for workflow transitions that should not happen automatically.

Use them before:

  • commits
  • source promotion
  • destructive cleanup
  • high-impact automated changes

Persistence ends the provisional phase​

Once a session outcome matters beyond the live workspace, use persistence actions such as:

  • commit
  • merge
  • source promotion

The goal is to keep temporary workspaces temporary, and keep durable outcomes explicit.

Metadata surfaces are part of the model​

The product model is not only files.

Use:

  • annotations for review notes
  • cache entries for keyed workflow state
  • bus messages for live coordination
  • events for durable activity history
  • tags for lightweight session classification

For most users and most product teams, the best default is:

  1. create a source
  2. create a session from that source
  3. fork when proposals diverge
  4. checkpoint before risky changes
  5. annotate and request approval
  6. commit or promote only after review
  7. retire the session when the live workspace is no longer needed

That model keeps the system understandable and keeps cleanup, support, and auditing manageable.