stemedb/ai-lookup/services/lifecycle.md
jordan 1ce4004807 feat: Complete Phase 2 (The Cortex) - query, lens, and API layers
This commit adds the read path (Cortex) to complement the write path (Spine):

## Crates
- stemedb-api: HTTP API with axum + utoipa OpenAPI
  - /v1/assert, /v1/query, /v1/epoch, /v1/skeptic, /v1/trace, /v1/audit
  - Metered endpoints with quota enforcement
  - Ed25519 signature verification
- stemedb-lens: Truth resolution lenses
  - RecencyLens, ConsensusLens, ConfidenceLens
  - VoteAwareConsensusLens (Ballot Box pattern)
  - TrustAwareAuthorityLens (The Hive pattern)
  - SkepticLens (conflict analysis)
  - EpochAwareLens (paradigm-safe queries)
- stemedb-query: Query engine with materialized views

## Storage Extensions
- VoteStore: Vote aggregation with cached counts
- TrustRankStore: Agent reputation with decay
- AuditStore: Query audit trail
- IndexStore: SP/P/S index structures
- SupersessionStore: Epoch supersession chains

## SDKs
- sdk/go/steme: Go HTTP client with Ed25519 signing
- sdk/go/adk: ADK-Go tools for AI agents

## Documentation
- Updated CLAUDE.md, architecture.md, roadmap.md
- New ai-lookup entries for all services
- Use case docs for consumer health intelligence
- Arena roadmap for simulation advancement

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-01 13:22:44 -07:00

2.0 KiB

Lifecycle Stages

Quick Ref: Assertions have lifecycle state: Proposed → UnderReview → Approved | Deprecated | Rejected Status: Implemented in stemedb-core v0.1.0 File: crates/stemedb-core/src/types.rs

The Problem

AI agents can't distinguish proposals from decisions. An RFC saying "we should use ES256" looks the same as an approved policy saying "use ES256." Agents query, get proposals, treat them as truth.

The Solution

enum LifecycleStage {
    Proposed,      // Idea, RFC, suggestion
    UnderReview,   // Being evaluated
    Approved,      // Accepted as current truth
    Deprecated,    // Was true, now superseded
    Rejected,      // Considered and declined
}

struct Assertion {
    // ... existing fields
    pub lifecycle: LifecycleStage,
}

Query Integration

# Only approved patterns (safe for implementation)
GET /query?subject=auth/jwt&predicate=algo&lifecycle=approved

# All stages (for research/context)
GET /query?subject=auth/jwt&predicate=algo&lifecycle=any

# Show proposals needing review
GET /query?predicate=*&lifecycle=under_review

State Transitions

Proposed → UnderReview → Approved → Deprecated
                      ↘ Rejected

Transitions are new assertions, not mutations:

POST /assert
{
  "subject": "auth/jwt",
  "predicate": "signing_algorithm",
  "object": { "Text": "ES256" },
  "lifecycle": "Approved",
  "parent_hash": "proposal_hash...",  # Links to original proposal
  "signatures": [{ "agent_id": "security_lead", ... }]
}

Lens Interaction

Lens Lifecycle Behavior
Recency Returns most recent matching lifecycle filter
Consensus Counts votes within lifecycle stage
Authority Weights by signer reputation, respects lifecycle
EpochAware Filters by epoch AND lifecycle

Origin

This feature emerged from user research (see .claude/agents/perspective-*.md). The Implementation Agent's core need: "If proposed and approved look the same, I can't use this."