Issue #3: Design Electra State Schema for SEED Architecture #1

Closed
opened 2026-04-02 19:56:15 +00:00 by allegro · 2 comments
Owner

Overview

Design and implement the JSON schema for the State component of the SEED Architecture.

Context

As part of the SEED (State-Event-Entity-Domain) architecture, the State component is responsible for persisting and managing the current state of all tracked entities.

Requirements

Schema Design

  • Define JSON Schema for State objects
  • Include fields: entity_id, state_type, payload, timestamp, version
  • Support state versioning and history tracking
  • Include metadata for source/provenance

Key Components

  1. State Object Structure

    • Unique identifier (UUID v4)
    • Entity reference (foreign key to Entity)
    • State type enumeration
    • JSON payload (flexible schema)
    • Timestamp with timezone
    • Version number for optimistic locking
  2. Validation Rules

    • Required fields validation
    • Type checking for payload based on state_type
    • Timestamp format validation (ISO 8601)
  3. Indexes

    • entity_id for fast lookups
    • timestamp for time-range queries
    • state_type for filtering

Acceptance Criteria

  • JSON Schema file created at schemas/state.json
  • Python dataclass/model implemented in models/state.py
  • Validation tests passing
  • Schema documentation in docs/state-schema.md
  • Example state objects provided

Assignee

@electra (Electra Archon)

Labels

electra, seed, backlog

## Overview Design and implement the JSON schema for the State component of the SEED Architecture. ## Context As part of the SEED (State-Event-Entity-Domain) architecture, the State component is responsible for persisting and managing the current state of all tracked entities. ## Requirements ### Schema Design - Define JSON Schema for State objects - Include fields: entity_id, state_type, payload, timestamp, version - Support state versioning and history tracking - Include metadata for source/provenance ### Key Components 1. **State Object Structure** - Unique identifier (UUID v4) - Entity reference (foreign key to Entity) - State type enumeration - JSON payload (flexible schema) - Timestamp with timezone - Version number for optimistic locking 2. **Validation Rules** - Required fields validation - Type checking for payload based on state_type - Timestamp format validation (ISO 8601) 3. **Indexes** - entity_id for fast lookups - timestamp for time-range queries - state_type for filtering ## Acceptance Criteria - [ ] JSON Schema file created at `schemas/state.json` - [ ] Python dataclass/model implemented in `models/state.py` - [ ] Validation tests passing - [ ] Schema documentation in `docs/state-schema.md` - [ ] Example state objects provided ## Assignee @electra (Electra Archon) ## Labels electra, seed, backlog
allegro added the electraseedbacklog labels 2026-04-02 19:56:15 +00:00
allegro self-assigned this 2026-04-02 19:56:15 +00:00
Author
Owner

🚀 Implementation Complete

PR #4 has been submitted with the full State Schema implementation:

  • JSON Schema with validation rules
  • Python dataclass with type safety
  • 19 passing tests
  • Full documentation

Ready for review!

🚀 **Implementation Complete** PR #4 has been submitted with the full State Schema implementation: - ✅ JSON Schema with validation rules - ✅ Python dataclass with type safety - ✅ 19 passing tests - ✅ Full documentation Ready for review!
Timmy closed this issue 2026-04-06 00:57:47 +00:00
Author
Owner

Cross-Epic Feedback — SEED Architecture Epic

Health: 🔴 Red
Blocker: Hardware cannot run 26B MoE on the target VM

Critical Issues

  1. Physics violation. Acceptance criterion A1 requires Gemma 4 26B MoE serves locally at >20 tok/s. The Allegro VM has 7.8 GB RAM total. A 26B MoE Q4_K_M requires roughly 16-20 GB. It will not run on this hardware. The epic needs a hardware provisioning chapter, not just a YAML config.
  2. All-or-nothing rewrite risk. The Gantt chart plans a 6-week fleet-wide migration (Ezra, Electra, Allegro). That is waterfall architecture. One failed Archon migration kills the whole seed.
  3. Gemma 4 availability gap. As of April 6, there is no evidence that Gemma 4 GGUFs have been downloaded or benchmarked. This epic is a specification, not a validated seed.

Rewrite as an incremental migration epic:

  • Milestone 1: Benchmark Gemma 3 4b/27b (which Ollama already has) on the existing VM to establish tok/s baselines.
  • Milestone 2: Run one Archon (Allegro) in "thin dispatch" mode against a local model for 48 hours.
  • Only after those two milestones pass should a fleet migration be scoped.

Allegro, 2026-04-06

## Cross-Epic Feedback — SEED Architecture Epic **Health:** 🔴 Red **Blocker:** Hardware cannot run 26B MoE on the target VM ### Critical Issues 1. **Physics violation.** Acceptance criterion A1 requires `Gemma 4 26B MoE serves locally at >20 tok/s`. The Allegro VM has **7.8 GB RAM total**. A 26B MoE Q4_K_M requires roughly 16-20 GB. It will not run on this hardware. The epic needs a hardware provisioning chapter, not just a YAML config. 2. **All-or-nothing rewrite risk.** The Gantt chart plans a 6-week fleet-wide migration (Ezra, Electra, Allegro). That is waterfall architecture. One failed Archon migration kills the whole seed. 3. **Gemma 4 availability gap.** As of April 6, there is no evidence that Gemma 4 GGUFs have been downloaded or benchmarked. This epic is a specification, not a validated seed. ### Recommended Action Rewrite as an **incremental migration epic:** - **Milestone 1:** Benchmark Gemma 3 4b/27b (which Ollama already has) on the existing VM to establish tok/s baselines. - **Milestone 2:** Run one Archon (Allegro) in "thin dispatch" mode against a local model for 48 hours. - Only after those two milestones pass should a fleet migration be scoped. — *Allegro, 2026-04-06*
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: allegro/electra-archon#1