> > > SpecSoterCoreArchitectureAndAkashaBoundaries

SOTER Core Architecture and Akasha Boundaries

Purpose

This specification defines the separation between SOTER's strict modeling core, projection adapters, Akasha ledger infrastructure, and reader/authority services. It is a boundary document, not a full Akasha ADR.

Scope

This document covers:

strict SOTER core responsibilities;
adapter responsibilities;
Akasha write-side boundary;
reader and authority placement;
SEOS and external-system integration boundary.

Non-Goals

This document does not define reader reliability; see Adr011AkashaReaderSideReliability.md.
This document does not define the Fact envelope; see Adr012FactEnvelopeSourceSequencing.md.
This document does not define interpretive authority; see Adr013InterpretiveAuthorityJurisdiction.md.
This document does not define Akasha deployment milestones; see Adr014AkashaTopologyMilestones.md.

Terminology

Term	Meaning
Strict core	Logos parsing, semantic model construction, ontology checks, VGM construction, and reconciliation concepts.
Adapter	Infrastructure, UI, storage, projection, or integration code outside the strict core.
Projector	Adapter that renders core projection contracts into a target notation or artifact.
Fact sink	Write-side port through which SOTER emits facts.
Akasha	Append-only fact ledger implementation or service.
Reader	Component that consumes Akasha and constructs views, reports, projections, or interpretations.
Authority service	Reader or domain service allowed to issue binding interpretive facts in a jurisdiction.

Model or Contract

Logos source
  -> strict SOTER core
  -> core contracts
  -> adapters
  -> projections, stores, UI, fact sinks, integrations

Akasha integration follows a separate write/read split:

SOTER or external source
  -> Fact sink / ingestion adapter
  -> Akasha append-only tape
  -> raw readers
  -> optional lenses
  -> native readers, authorities, reports, projections

The strict core may write facts. It must not depend on concrete Akasha storage, reader services, or authority services.

Rules

The strict core defines contracts and semantics; it does not import concrete projectors, ledgers, UI frameworks, or storage adapters.
Projectors are dumb translators of core projection contracts.
Fact emission is write-side only from the strict core's point of view.
Reader-side interpretation is outside the strict core.
Authority and jurisdiction are outside the strict core and are expressed through interpretive facts.
SEOS may integrate tightly as a showcase, but external systems must be able to integrate through generic audit sinks or change feeds.

Examples

Valid Projector Boundary

core defines projection contract
adapter implements BPMN projector
adapter registers BPMN projector
core calls abstraction

Invalid Projector Boundary

core imports BPMN projector
core imports Mermaid projector
core imports SVG writer

Valid Akasha Boundary

core emits Fact -> FactSink
FileLogSink or AkashaSink handles persistence
LedgerReader reads later, outside the core

Validation

Boundary validation should check:

core modules do not import concrete projector modules;
core modules do not import concrete Akasha storage or reader implementations;
projectors consume contracts rather than infer new domain meaning;
fact sink implementations are adapter-side;
readers and authority services are not required for core model validation.

Compatibility

This document summarizes ecosystem boundaries. Detailed ledger decisions are tracked in ADR-011 through ADR-014 and should be treated as authoritative for reader behavior, fact envelope fields, authority, and topology.

Open Questions

Should the projector contract be expressed as a Python Protocol, abstract base class, or registry schema?
Which dependency checks should enforce strict-core purity in CI?