LifecycleLifecycle and limitations

What works now.
What does not.

A capability should say where it works, where it stops, and what that means day to day. The matrix below keeps those edges visible.

Implemented
Present in source and tests within the stated scope; a public release record may still be pending.
Experimental
Nothing is currently listed in this state.
Roadmap
A direction, not a present product capability or delivery promise.
FIG 1.1 · Lifecycle position

Where does each canonical capability sit on the published lifecycle?

Scope: five canonical capability rowsSource: public capability matrixReviewed 2026-07-14

  • Self-hosted memory store
  • Named agent surfaces
  • Supersession and addressable history
  • Principal and scoped access controls
  • Causal-hypergraph and N-ary discovery

Experimental · no listed rows

Illustrative trace

One implemented row, followed end to end

  1. record:r_demo_friday Staging deploys go out Friday at 17:00 UTC Prior · addressable
  2. record:r_demo_wednesday Staging deploys go out Wednesday at 15:00 UTC Current · human-confirmed

Verified 2026-07-14 · Proof claim: memory-roundtrip-supersession

MatrixCanonical matrix

Scope before promise.

Rows are manually reviewed and statically validated; source changes can still make a row stale. Public release references remain pending where each row says so.

Public matrix JSONMatrix schema

Scroll horizontally to compare every field

Origin · capability and lifecycle Position · scope, evidence, reviewed Boundary · limitation, consequence, workaround Destination · next gate
Five canonical capability rows, authored from the public matrix JSON.
CapabilityLifecycleReviewed scopeEvidenceReviewedKnown limitationConsequenceWorkaroundNext gate
Self-hosted memory storeImplementedThe default self-hosted product path keeps stored product data on operator-controlled machines.Inspect claim recordVerified 2026-07-14Implemented in ax0s-memory 0.5.0; a public release record is pending. The scope applies to default product storage, not optional product egress or website services.The operator is responsible for the machines that run and retain the memory store.Review optional product egress and website egress separately before deployment.Publish a release record with date, artifact, supported environments, interface contract, and acceptance receipt.
Named agent surfacesImplementedConnection paths are implemented separately for Claude Code, Codex, ChatGPT, and Hermes; a dated same-store four-surface receipt is pending.Inspect claim recordVerified 2026-07-14Separate implementation paths do not establish simultaneous operation against one store, current runtime health, or any additional surface.Treat each named path as a separate implementation until a combined operational receipt is published.Validate the selected path in the operator's own environment before relying on it.Publish a dated same-store four-surface operational receipt.
Supersession and addressable historyImplementedStale facts can be superseded without deletion, and superseded history remains addressable.Inspect claim recordVerified 2026-07-14Implemented and test-covered in ax0s-memory 0.5.0, with one recorded 2026-07-14 product round trip; a public release record is pending. This row does not claim that every contradiction is resolved automatically.A correction can become current while the prior record remains available for inspection.Inspect the addressable history when the prior state matters.Publish a release record and broader compatibility, concurrency, and durability receipts.
Principal and scoped access controlsImplementedPer-principal tokens and slug/capability grants, expiry, revocation, rate limits, default-deny enforcement, and access-audit records are implemented; record-level authorization, hardened multi-tenant isolation, and externally validated identity controls are not established.Inspect security boundaryVerified 2026-07-14Record-level authorization, hardened multi-tenant isolation, and externally validated identity controls are not established. Legacy shared-bearer compatibility remains until registry cutover.Do not rely on the current product where record-level authorization, hardened tenant isolation, or externally validated identity controls are required.No public workaround is claimed for the unestablished controls.Publish record-level authorization, tenant-isolation, and external identity-validation artifacts before extending this scope.
Causal-hypergraph and N-ary discoveryRoadmapThis is a research direction only; it is not a shipped product capability.Inspect roadmap recordRoadmapCausal and N-ary discovery are not available in the current product.Current workflows must not depend on causal or N-ary discovery.Use only the implemented memory and supersession behavior described in this matrix.Publish an approved implementation artifact before changing the lifecycle state.

A new row needs code, release documentation, or an approved artifact before it earns a lifecycle state.

Roadmap · research direction only

A possible map for many-part relations.

Causal and N-ary discovery are not available in the current product. This illustrative hypergraph names the research boundary without turning it into a delivery promise.

FIG 2.1 · Roadmap hypergraph · Illustrative

What would need to connect before the lifecycle state could move?

Not a shipped product capabilityNo delivery dateNext gate: approved implementation artifact

Roadmap research boundary Three example source records connect to a proposed N-ary relation. That relation connects to causal review and then to an approved implementation artifact required before the capability can move from Roadmap. SOURCE A record SOURCE B record SOURCE C record PROPOSED N-ARY RELATION CAUSAL REVIEW APPROVED ARTIFACT

Boundary: current workflows must not depend on causal or N-ary discovery. Use only the implemented memory and supersession behavior described in the matrix.