Adoption Mode Guidance

Goal

This document defines a first concrete guide for AletheIA adoption modes.

In simple terms:

if Alpha 6 is going to support lighter and fuller ways of adopting the framework, it needs a clearer model for how much structure should be emphasized at the start without changing the framework itself.

Why this matters

Not every team needs the same operating depth on day one.

Some teams need:

a lighter reading path
a smaller starter-pack slice
a more minimal protocol while they test fit

Other teams need:

stronger continuity between agents
more explicit review discipline
more reusable artifacts from the start

If AletheIA offers only one level of ceremony, it creates two problems:

lightweight adopters may avoid it because it feels too heavy
higher-risk adopters may underuse it because the baseline feels too thin

Adoption modes help solve that without creating multiple frameworks.

Core idea

An adoption mode should be understood as:

a recommended operating depth for introducing AletheIA in a real context

An adoption mode is not a new preset. It is not a new adapter. It is not a weaker or stronger version of the core.

An adoption mode should answer questions such as:

how much structure should be introduced now?
which layers are essential immediately?
which artifacts can wait until the framework proves useful locally?
what is the safest default level of ceremony for this context?

The adoption mode should change the entry posture. It should not change the framework meaning.

Three adoption modes

1. Lite mode

Use when the main goal is:

learning the framework without too much upfront ceremony
testing fit inside a smaller team or bounded pilot
introducing AletheIA with minimal friction

This mode should emphasize:

getting started
overview
governance baseline
token policy
apply-to-existing-project guidance
small starter-pack usage

This mode should postpone:

richer handoff patterns unless multi-agent continuity is already real
Alpha 5 inference artifacts unless semantic risk is already material
domain governance packs unless trust boundaries justify them early

Lite mode is about proving usefulness before expanding operating surface.

2. Standard mode

Use when the main goal is:

adopting AletheIA as a stable team operating layer
preserving reusable process without maximal upfront depth
balancing clarity and practicality across ongoing work

This mode should emphasize:

governance baseline
project extension discipline
contribution boundaries
starter-pack reuse
Alpha 4 handoff baseline where more than one agent or environment is involved

This mode should usually include:

explicit durable decisions
validation discipline appropriate to the work
clearer local operating conventions

Standard mode is the most likely default for a serious team using AletheIA beyond a small experiment.

3. Fuller operating mode

Use when the main goal is:

operating in a context where continuity, reviewability, and trust boundaries matter more from the start
using more than one agent, surface, or team boundary regularly
making risk-oriented artifacts and domain-specific packs easier to add when needed

This mode should emphasize:

the full Alpha 3 adoption baseline
the Alpha 4 handoff baseline
the Alpha 5 experimental baseline in bounded higher-risk scenarios
explicit use of project-level conventions
readiness for future domain governance packs when justified

This mode should remain careful not to become universal default ceremony.

Fuller mode is justified when the coordination and risk surface is already significant enough to benefit from more structure.

How to choose

AletheIA teams should choose an adoption mode based on the current operating context, not on aspiration alone.

Good selection signals include:

Choose Lite when:

the team is still testing whether AletheIA fits
work is still mostly single-agent or tightly coordinated manually
the goal is to reduce ambiguity without introducing too much process at once

Choose Standard when:

AletheIA is already useful across recurring work
more than one contributor or surface needs shared structure
local extension boundaries matter and need to stay visible

Choose Fuller when:

cross-agent continuity is already a recurring need
semantic risk is high enough to justify more explicit review artifacts
domain-specific trust boundaries are important early
the team will benefit from richer reusable operating packages

Selection sequence in practice

A practical Alpha 6 read is:

choose the preset
choose the adapter
choose the adoption mode
freeze the project extension boundary

See:

examples/distribution/constrained-adoption-mapping.md

This keeps adoption mode from floating as a purely abstract label.

What adoption modes should not do

Adoption modes should not:

imply that Lite is unserious and Fuller is always better
create incompatible versions of the framework
hide the difference between entry posture and framework meaning
pressure every team into maximum ceremony too early
replace good judgment about when a layer is actually justified

teams can start lighter without losing sight of the fuller framework
fuller operating depth feels justified by context, not ideology
packaging becomes easier without multiplying framework variants
Alpha 6 stays about delivery choices rather than core distortion

Adoption Mode Guidance

Goal

Why this matters

Core idea

Three adoption modes

1. Lite mode

2. Standard mode

3. Fuller operating mode

How to choose

Choose Lite when:

Choose Standard when:

Choose Fuller when:

Selection sequence in practice

What adoption modes should not do

Relationship to presets and adapters

Preset

Adapter

Adoption mode

Good signs

Suggested next reading