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>
74 lines
2.0 KiB
Markdown
74 lines
2.0 KiB
Markdown
# 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
|
|
|
|
```rust
|
|
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."
|