Skip to content

Runtime Memory

Target Architecture — Final-State Design

This page describes the final-state runtime memory of the Knowledge Platform: how the behaviour of everything the factory ships flows back in as durable, queryable knowledge. Owned by RuntimeMemoryService and KnowledgeReplayService.

Runtime memory is what makes the factory self-improving. Generated SaaS products run in production and emit telemetry; the Observability & Feedback Platform collects it; and the Knowledge Platform ingests the meaningful signals as RuntimeSignal, IncidentMemory, and FeedbackItem records, linking them back through the knowledge graph to the exact artifacts, decisions, and context that produced the running code. This closes the loop from intent → generation → runtime → learning.

Ingestion from Observability

flowchart LR
    OBS["Observability & Feedback Platform"] -->|"RuntimeSignalReceived"| RTW["RuntimeSignalWorker"]
    RTW --> RM["RuntimeMemoryService"]
    RM --> Signal["RuntimeSignal"]
    RM --> Incident["IncidentMemory"]
    RM --> Feedback["FeedbackItem"]
    Signal --> Graph["GraphProjectionWorker"]
    Incident --> Graph
    Feedback --> Graph
    Graph --> KG[("Knowledge Graph")]
    Signal --> OTEL[("App Insights / OTEL")]
    RM --> Conflict["ConflictDetectionWorker"]
Hold "Alt" / "Option" to enable pan & zoom

The Observability & Feedback Platform publishes runtime events in the canonical envelope. POST /knowledge/ingest/runtime-signal and the RuntimeSignalWorker persist them and link each to its producing artifact via linkedArtifactId, emitting RuntimeSignalRecorded, IncidentMemoryCaptured, or FeedbackItemRecorded.

Runtime Knowledge Types

Aggregate Captures Example
RuntimeSignal A discrete runtime observation (metric, error, saturation, cost) p95 latency regression on module-reservations-api
IncidentMemory A production incident with timeline, root cause, resolution Reservation double-booking incident, root cause + fix
FeedbackItem Explicit human/automated feedback on an artifact or output Reviewer rates a generated test suite as incomplete

Each links into the graph (GENERATED, TARGETS) so the factory can answer "which runtime problems trace back to this blueprint/decision/context?".

The Runtime Feedback Loop

flowchart LR
    Context["ContextPackage"] --> Artifact["Generated Artifact"]
    Artifact --> Deploy["Deployment"]
    Deploy --> Signal["RuntimeSignal"]
    Signal --> Attribute["Attribute to producing context/decision"]
    Attribute --> Quality["KnowledgeQualityService"]
    Attribute --> Pattern["PatternCatalogService"]
    Quality -->|down-rank weak knowledge| Context
    Pattern -->|promote proven solutions| Context
    Attribute --> Replan["Control Plane re-planning"]
Hold "Alt" / "Option" to enable pan & zoom

Because every ContextPackage records its policyDecisionId, traceId, and sources, and every artifact records the contextPackageId that produced it, a runtime signal can be attributed back to the exact context that grounded its generation. The platform uses this to:

  • Down-rank weak knowledge — knowledge that consistently produces problematic outcomes loses ranking weight in the Context Builder.
  • Promote proven solutions — knowledge correlated with healthy runtime behaviour is promoted to KnowledgePatterns for reuse.
  • Trigger re-planning — significant signals/incidents flow to the Control Plane to open corrective work.
  • Detect conflicts — the ConflictDetectionWorker flags when new runtime evidence contradicts an existing decision or pattern.

This is the concrete mechanism behind the factory's promise that each project is better than the last.

Knowledge Replay

KnowledgeReplayService and the KnowledgeReplayWorker re-drive historical envelope events to rebuild projections, recover from a bad ingestion, or analyse a timeline.

stateDiagram-v2
    [*] --> Requested
    Requested --> Loading: select window (traceId / time range / topic)
    Loading --> Replaying: stream events in order
    Replaying --> Projecting: re-run idempotent handlers
    Projecting --> Completed: projections rebuilt
    Replaying --> Failed: unrecoverable
    Completed --> [*]
    Failed --> [*]
Hold "Alt" / "Option" to enable pan & zoom
  • Deterministic — replay relies on envelopes being immutable once published and on every handler being idempotent (keyed by the idempotency key).
  • Scoped — a replay window can be a single traceId, a time range, or a topic, partitioned by tenantId.
  • Use cases — rebuilding the graph after a schema change, re-embedding after a model upgrade, reconstructing an incident timeline, or recovering dead-lettered messages after a fix.
  • Auditable — emits KnowledgeReplayStarted / KnowledgeReplayCompleted with counts of records rebuilt.

Governance of Runtime Memory

  • Runtime signals are classified like any memory; production data that may contain sensitive values is classified Confidential/Secret and redacted before inclusion in any context.
  • Raw telemetry has a shorter retention (30–90 days) than the derived IncidentMemory/FeedbackItem aggregates, which persist as durable learning.
  • Access to runtime memory in context assembly is governed by MemoryAccessPolicy (see Governance).