> > > SpecAdr014AkashaTopologyMilestones

ADR-014: Akasha Deployment, Role, and Milestone Order

Status

Proposed

Context

Akasha can be local or remote. It can also be an audit ledger or the source of truth. The write mechanism and consistency risks depend on the combination of those axes, not on either axis alone.

SOTER also needs a build order that proves value before incurring the full cost of distributed infrastructure.

Decision

Akasha has two axes:

Axis	Values
Deployment	`local`, `remote`
Role	`audit`, `source-of-truth`

Three combinations are valid:

Deployment	Role	Mechanism
Local	Audit	Append fact in the same local transaction as state. RDBMS remains source of truth.
Local	Source of truth	Append to Akasha as the authoritative write. RDBMS becomes a projection.
Remote	Audit	Source system remains authoritative. Outbox or CDC plus async relay sends facts to Akasha.

The fourth combination is forbidden:

Deployment	Role	Reason
Remote	Source of truth	Authoritative writes would depend on a remote service whose availability the source system does not control.

The milestone order is value-first:

M1: local audit. Prove dumb tape plus smart readers while operational database remains authoritative.
M2: local source of truth. Promote the proven tape to the primary record and rebuild operational tables as projections.
M3: remote audit. Expose Akasha as an external audit sink for other systems.

Rationale

Local audit is the cheapest proof of value. It validates the ledger and reader concept without distributed delivery semantics. Local source-of-truth is a larger architectural commitment but still avoids remote availability risk. Remote audit is the adoption interface for foreign systems and arrives after the concept is proven.

For remote audit, transactional outbox or CDC degrades failure from lost or phantom facts into at-least-once delivery. Duplicates are acceptable because Akasha records raw phenomena and reader lenses decide how to interpret them.

Consequences

Positive

The remote source-of-truth trap is explicitly forbidden.
Milestones validate value before distributed integration.
Foreign systems can integrate gradually without adopting Akasha internally.

Negative

Third-party adoption is delayed until after local value is proven.
M3 crosses both deployment and role context relative to M2.

Neutral or Operational

Remote audit is the only quadrant that requires populated source_id and source_seq.
SEOS may become a showcase integration, but market adoption must not require tight SEOS/SOTER coupling.

Alternatives Considered

Remote Audit First

Rejected for current sequencing. It would establish an adoption contract early but would build distributed infrastructure before proving ledger value.

Remote Source of Truth

Rejected as an availability trap.

Migration or Adoption

Map M1, M2, and M3 onto concrete GitHub milestones and backlog items before implementation starts.