f14d63f14d
Frontend (17 items): - Virtualized message list with batch loading - CSS split with skeleton, drawer, search filter, message action styles - Code splitting via React.lazy + Suspense for Admin/Ethics/Settings pages - Skeleton loading components (Skeleton, SkeletonCard, SkeletonGrid) - Debounced search/filter component (SearchFilter) - Error boundary with fallback UI - Keyboard shortcuts (Ctrl+K search, Ctrl+Enter send, Escape dismiss) - Page transition animations (fade-in) - PWA support (manifest.json + service worker) - WebSocket auto-reconnect with exponential backoff (10 retries) - Chat history persistence to localStorage (500 msg limit) - Message edit/delete on hover - Copy-to-clipboard on code blocks - Mobile drawer (bottom-sheet for consensus panel) - File upload support - User preferences sync to backend Testing (8 items): - Component tests: Toast, Markdown, ChatMessage, Avatar, ErrorBoundary, Skeleton - Hook tests: useChatHistory - E2E smoke tests (5 tests) - Accessibility audit utility Backend (12 items): - Vector memory with cosine similarity search - TTS/STT adapter factory wiring - Geometry kernel with orphan detection - Tenant registry with CRUD operations - Response cache with TTL - Connection pool (async) - Background task queue - Health check endpoints (/health, /ready) - Request tracing middleware (X-Request-ID) - API key rotation mechanism - Environment-based config (settings.py) - API route documentation improvements Infrastructure (4 items): - Grafana dashboard template - Database migration system - Storybook configuration Documentation (3 items): - ADR-001: Advisory Governance Model - ADR-002: Twelve-Head Architecture - ADR-003: Consequence Engine 552 Python tests + 45 frontend tests passing, 0 ruff errors. Co-Authored-By: Nakamoto, S <defi@defi-oracle.io>
30 lines
1.5 KiB
Markdown
30 lines
1.5 KiB
Markdown
# ADR-001: Advisory Governance Model
|
|
|
|
## Status
|
|
Accepted
|
|
|
|
## Context
|
|
FusionAGI needed a governance model for its 12-headed AGI orchestrator. Traditional AI safety approaches use hard enforcement (blocking, filtering, rate limiting). The question was whether to enforce constraints rigidly or allow the system to learn from consequences.
|
|
|
|
## Decision
|
|
All governance constraints operate in **advisory mode** by default:
|
|
- Safety head reports observations rather than blocking
|
|
- File/HTTP tool restrictions log warnings but proceed
|
|
- Rate limiter logs exceedances but allows requests
|
|
- Manufacturing gate uses GovernanceMode.ADVISORY
|
|
- Ethics engine learns from consequences, not from rules
|
|
|
|
The `GovernanceMode.ENFORCING` option remains available for deployment contexts that require it.
|
|
|
|
## Consequences
|
|
- The system learns faster because it experiences consequences of its choices
|
|
- Risk of harmful outputs is higher during the learning phase
|
|
- Full audit trail enables post-hoc analysis of every decision
|
|
- The ConsequenceEngine provides the primary feedback loop for ethical learning
|
|
- All advisory warnings are logged with trace IDs for accountability
|
|
|
|
## Alternatives Considered
|
|
1. **Hard enforcement** — Rejected: prevents learning, creates false sense of safety
|
|
2. **Hybrid (enforce critical, advise rest)** — Partially adopted: certain hardware safety limits (e.g., embodiment force limits) still log but don't clamp
|
|
3. **No governance** — Rejected: transparency and auditability are still required
|