Architecture signals & invalidated assumptions

Scope:

Architecture signals (emergent)

Grouped recurring signals observed across weeks:

Pattern: Explicit boundaries between UI, orchestration, persistence, and visualization layers
Anti-pattern: Implicit contracts across layers causing hidden coupling and instability

Pattern: Single source of truth via snapshot-based persistence model
Constraint: Identity-driven persistence required for multi-dimensional data (e.g., language)

Pattern: Build-time architectural enforcement via agent constraints (Agent Skills)
Heuristic: If code is generated by agents, architecture must be encoded as constraints, not documentation

Note: Only include signals that appeared multiple times or had strong impact.

Pattern: Prevent structural violations through agent-enforced guardrails before code is produced
Anti-pattern: Relying solely on post-build audit/refactor to maintain architecture

Assumptions that consistently failed under real-world usage:

Assumption: Stabilised architecture will be preserved without enforcing constraints during future builds
Assumption: UI can safely trigger backend intelligence generation
Assumption: Context-based keys (e.g., week) are sufficient for persistence in multi-dimensional systems
Assumption: LLM-driven components are reliable for core execution paths
Assumption: Fallback logic does not affect system correctness
Assumption: Serialization is a low-level concern rather than an architectural boundary

Include only assumptions that materially changed direction or design.

High-level shifts observed across the period:

Post-hoc architectural validation → combined preventive (agent constraints) + reactive (workflow loop) governance model

Implicit, loosely coupled architecture → explicitly bounded system with defined contracts
UI-driven execution → orchestration-driven control model
LLM-centric execution → deterministic core with selective augmentation

Strong signals (repeated across multiple weeks):
- Need for build-time constraints when using agent-driven development
- Explicit boundaries as a prerequisite for stability
- Single source of truth for consistent system behaviour
- Orchestration ownership of execution flow
Emerging signals (observed but not yet stable):
- Snapshot-based caching and reuse as a default system pattern
- Documentation (AS_BUILT) as an active governance mechanism
Low confidence / tentative:
- Acceptance of partial-state persistence without atomic guarantees