Skip to main content

Derived progression

Aegis may expose a richer sense of growth over time, but progression is meant to be a derived layer, not a new durable owner.

That rule keeps progression motivating without letting it outrank work, continuity, or correctness.

Why progression exists​

A lightweight progression loop can help users feel momentum, but a thin, capped, volume-driven score stops being meaningful quickly. The target design wants something deeper:

  • early reward for onboarding and first-use momentum
  • later reward for mastery, not just volume
  • no hard end-state where growth simply runs out
  • clear explanations for why progress happened
  • stronger motivation to return and continue real work

Boundary rule​

Progression is a projection built from canonical sources. It must not become the only authoritative home of any fact.

Canonical truth still lives in:

  • ProfileGraph for identity and relationship state
  • WorkGraph for goals, blockers, decisions, and work depth
  • EvidenceGraph for outcomes, recall, and produced artifacts
  • ProcedureLibrary for verified reusable procedures
  • CapabilityRegistry for available tools and overlays

Product goals​

The progression layer tries to create five feelings at once:

Immediate reward​

New users should feel progress early. The first visible upgrade should happen within the first turns and sessions.

Meaningful mastery​

Later growth should reward depth of execution, continuity quality, recovery, and verified learning instead of raw churn.

Long-horizon aspiration​

The system should avoid a hard cap. There should always be another ring, threshold, or challenge track to pursue.

Fair challenge​

Harder, cleaner, more reusable work should advance faster than trivial busywork.

Explainable reward​

Users should be able to understand why they progressed and what behavior is most likely to move the bar next.

The derived projection​

The target runtime can expose a progression read model with fields such as:

  • ascension level and ring position
  • stage title and dominant archetype
  • mastery vector and power score
  • progress to the next milestone
  • momentum state
  • active challenge tracks
  • recent reward reasons
  • anti-grind flags

This is a view for shell, API, console, or reports. It is not a second database.

Signal families​

A stronger progression model should combine several sources of signal.

Work depth​

How demanding was the completed work? Did the runtime advance meaningful goals, resolve blockers, and produce useful artifacts?

Outcome quality​

Did the work finish cleanly? Did validation pass, rework stay low, and the result prove useful?

Continuity quality​

Did Aegis actually keep the thread? Did resume, recall, and constraint carry-forward help rather than confuse?

Learning yield​

Did the session produce reusable procedure candidates or verified procedures? Did the system become more capable in a durable way?

Guardrails​

The progression layer must not:

  • create a hidden cognition store
  • make growth more visible than the current work
  • reward token spam or trivial turns
  • reward unsafe autonomy or behavior that ignores user intent
  • lock meaningful product behavior behind progression gates

The practical takeaway​

Progression can make Aegis feel more alive over the long run, but it should always remain downstream of durable truth, continuity, and verified learning. That ordering is what keeps the product motivating without making it misleading.