ATLAS synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From logistics inputs to retained context
ATLAS is a shipped memory/knowledge/context-engineering system for logistics agents. This account covers its repository at commit 65b91b4fd5d703e8a82ad8fa2a9b8d2f38754988, with an analysis cutoff of 2026-10-12. SRC-1 supplies inspected implementation and doctrine/design, not an observed deployment, executed tests or a causal comparison. The whole-system functional boundary includes CLI and web callers, acquisition drivers, maintenance, internal chat and MCP service. External MCP hosts' later decisions and provider internals are not attributed to ATLAS. See the boundary and Source register.
The architecture has two principal retained stores: operational records in SQLite and natural-language knowledge in package-relative Markdown files. SQLite can be file-backed or use the in-memory fallback; actual persistence depends on configuration and mounts. The browser separately retains conversation text in an ES-module array across navigation, without established reload persistence. Symbolic hashes, timestamps and checkpoints govern future acquisition and processing. These stores have different consumers and cannot be treated as one knowledge ledger. See RT-OBJ-atlas-db, RT-OBJ-knowledge, MEM-OBJ-messages and MEM-OBJ-progress-state.
Non-AI connector and CLI imports map supplied records, check minimum required fields and upsert them. AI file extraction first sends document text and schema guidance to a model, then parses and filters proposed records before upserts. The default text input is bounded to 40000 characters. The runtime checks field presence, not full schema conformance or real-world truth. Per-record errors can coexist with a successful terminal response, and silent upsert returns can inflate reported counts. The legacy sample initializer is a separate direct-SQL exception, not another witness for the mapped import gate. See RT-RTE-record-import, RT-RTE-file-extraction, EPI-RTE-field-mapping and the report-verification limits.
Maintaining Markdown without a semantic approval gate
The knowledge engine receives raw text or bounded extracted-entity summaries together with selected existing files. Selection is lexical: topic matches in paths and keyword matches in file contents rank positive-scoring whole files. Default limits are five files and 30000 characters, but the first oversized file can exceed the character budget. New-information summaries contain only ten records per entity group; those in-memory entities need not all have survived database admission. The model proposes create, append or contradiction-marking actions. Software checks JSON and a minimal action/path envelope and applies admitted actions without per-content human approval. See RT-RTE-knowledge-enrichment and its memory annotation.
The scheduled knowledge-enricher is materially different: it supplies extraction filename, counts and timestamp from retained logs, not the extracted facts. That metadata can drive automatic Markdown updates, but cannot reconstruct particular logistics assertions by itself. The pipeline's content-hash deduplication also recognizes failed logs, so unchanged failed files can be skipped unless force is supplied. The scheduled cursor can advance after a returned enrichment failure; strict timestamp windows can exclude equal-timestamp entries outside a limited batch. These are implemented selection and recovery policies, not guarantees of complete processing. See RT-RTE-extraction-summary, MEM-OBJ-extract-log and MEM-OBJ-progress-state.
Conflict marking retains both supplied values and a verification request. It does not adjudicate truth or deterministically prevent either assertion from reaching later consumers. A missing target can produce no warning yet be reported as applied. Likewise, the engine's add-only instruction is policy rather than a store invariant: create on an existing path can overwrite, and chat saves or direct edits independently replace files. Source/date text is not verified provenance, and returned analysis/reasons are not independently persisted as an acceptance ledger. See MEM-OBJ-contradiction-block, EPI-RTE-contradiction-marking, RT-CLM-additive-knowledge and RT-RTE-knowledge-edit.
A question reaches tools and a displayed reply
The representative connected workflow is browser chat, selected because its next-step decisions and delivery are inside ATLAS rather than an excluded host. A user supplies a question, accumulated conversation text and an optional model choice. The server supplies current record counts, all knowledge filenames, instructions and tool schemas. The selected model decides whether to answer or request tools; a fixed JavaScript switch executes recognized calls on the shared Atlas instance. Knowledge contents are pulled by requested path, unlike the automatic filename inventory or the engine's lexical file push. See RT-RTE-chat-tools and the workflow account.
Calls within a round execute sequentially. Current tool results, including executor errors, return to the same model for continuation. Five tool-enabled rounds are allowed, followed on exhaustion by one tool-free final call. This bounds rounds, not writes, files or bytes. No separate reviewer or expected-answer oracle accepts final text. Endpoint failure ends the request; the browser displays an error and requires another user action rather than automatically resubmitting. Earlier successful saves are not rolled back. Delivery means an API reply/log/usage response and browser rendering, not verified task achievement. Later browser requests replay user/assistant text but omit earlier tool-result evidence. See RT-BAP-chat-guidance, MEM-RTE-conversation-replay and the workflow account.
MCP is a distinct returning service: external hosts request indexed records or rule-defined results and own subsequent action. Fixed closure, SLA and idle computations support conditional conclusions over selected rows and timestamps; they do not authenticate delivery, signatures or contractual breaches. Closure's default document cap of 50 and other sample/result limits constrain completeness. Developer validators, mock tests and setup diagnostics have separate targets and do not gate live knowledge truth. See RT-RTE-mcp-query, EPI-RTE-derived-results and EPI-RTE-evaluator-tools.
What adaptation does and does not establish
The strongest supported adaptive contribution is implemented automatic trace-fed retention with later consumers. Processing metadata can feed durable Markdown; run outcomes generate checkpoints that change later input selection; chat history and current tool feedback can feed a saved-finding branch whose files are later readable. These are wired behavior-shaping pathways, not demonstrated improvements in future capacity. Raw conversation replay alone is not a derived learning artifact, and not every chat save has established trace provenance. See RT-RTE-extraction-summary, MEM-OBJ-progress-state, RT-RTE-chat-tools and the profile verification.
Theory-builder conditions remain separate. For condition 1, available Markdown storage and conflict prose do not establish an actual localized formulated theory; provider formulation is not determinable. For condition 2, file delivery is wired, but dependence on what a theory says is unestablished. For condition 3, conflict rendering requests verification but does not establish claim-directed criticism with placement of blame and resulting revision or changed reliance. For condition 4, persistence and later delivery do not establish that a criticism's result shapes another round. These conclusions do not assert absent opaque model reasoning. The epistemic bounded conclusion and RT-RTE-knowledge-enrichment support these distinctions.
Criticism improving future capacity is unestablished independently of those conditions. Reflection is also unestablished: extraction logs represent processing and feed maintenance, but the records do not establish both causal directions for a selected self-represented aspect. Autonomy is supported locally for model/software proposal execution and admission without individual human approval; autonomous theory building is not established. Exercised self-improvement is unestablished at this repository boundary: retained changes can enter later context or control, but an independently specified improvement objective, objective-bearing evidence shaping the update, and subsequent operation causally depending on that change are not established as a complete pathway. Neither successful improvement nor a causal component effect was measured. See MEM-OBJ-extract-log, MEM-OBJ-progress-state, RT-RTE-chat-tools and the epistemic bounded conclusion.
Scenario-relative assessment and changes that would matter
For a question over already indexed records, ATLAS supplies a connected query-to-model-to-reply workflow, conditional on source quality, selected context and provider behavior. For an evolving knowledge base, it supplies automatic updates and later reads, but not content-level evidence-consuming acceptance, adjudicated conflict resolution or coordinated withdrawal of all derivatives. Record pruning changes later query results without retracting derived Markdown. These limits matter more to longitudinal reliance than the mere availability of save/read tools. See MEM-OBJ-record-payloads, MEM-RTE-record-pruning and EPI-RTE-contradiction-marking.
For shared-server operation, source-level MCP token checks do not establish REST authorization: the inspected REST handlers do not use that gate. Native modules initialize before the enabled test and have ordinary process authority, not a sandbox. The lexical KB path guard does not establish realpath isolation. Model routing can change on reload, but old module and directory-extraction references can survive. External controls and deployment evidence would be needed for broader guarantees. See RT-ABS-rest-auth, RT-BAP-native-module, RT-OBJ-knowledge, RT-RTE-config-reload and the report-verification limits.
Input/output-linked runs showing actual retained updates and later consumption would change activation judgments. Evaluated document/reference comparisons would change fidelity judgments. A content acceptance decision tied to evidence, intended use and scope would change the warrant account; an existence veto covering create and coordinated writer controls would change preservation guarantees. Objective-specific before/after evidence with suitable interventions would be needed to attribute improved capacity or self-improvement rather than merely retained change. None of those stronger conclusions follows from the current implementation and test designs.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| No observed deployment, operational KB, actual provider transformations, executed test results or causal comparison | SRC-1; RT-RTE-file-extraction, RT-RTE-knowledge-enrichment, EPI-RTE-evaluator-tools | Frozen source implementation and doctrine/design | Exercised reliability, semantic fidelity, actual acceptance, passing tests, historical evolution and improved capacity | Linked inputs, outputs, retained artifacts and later-consumer traces; test results; objective-specific controlled comparisons |
| Provider-private retention and exact served parameters; unavailable external-module state | SRC-1; RT-CMP-llm-client, RT-RTE-module-lifecycle | Client interface and shipped loader, not provider internals or installed external implementations | Complete memory/learning inventory, immutable deployed model identity or universal absence of other adaptation | Pinned provider identity and inspectable retention behavior; installed module source and state/consumer evidence |
| Initial content and generic caller provenance/control unresolved | SRC-1; RT-OBJ-knowledge, MEM-OBJ-record-payloads, RT-RTE-knowledge-edit | Store and write routes without deployment history | Complete lineage and manual/automatic admission classification | Content creation/admission records identifying producers and decisions |
| Legacy sample initializer omitted from separate import characterization | SRC-1; RT-RTE-record-import, MEM-OBJ-record-payloads; report limit | Verifier inspected seed.js: direct SQL writes, including omitted shipment/carrier indexed status/country fields |
Every initializer sharing minimum-field gates or identical payload/index views | Dedicated initializer record tracing direct writes and resulting index/payload differences |
| Diagnostic inventory omits separate health classification | SRC-1; EPI-RTE-evaluator-tools, EPI-RTE-derived-results; report limit | Verifier inspected src/health.js and src/ui-server.js timestamp/run-based HTTP diagnostic |
Complete evaluator/monitoring comparisons; healthy status certifying successful synchronization | Dedicated diagnostic record tracing predicates, result and consumers; independent synchronization evidence |
| Reload retains additional old configuration reference | SRC-1; RT-RTE-config-reload, RT-CMP-llm-client; report limit | Verifier inspected reload handlers and src/connector-runner.js; runner.config is not replaced |
Immediate rerouting of every extraction producer | Consumer-specific propagation records or implementation replacing retained references, with activation evidence |
| Profile lacks a dedicated external MCP operational-record return unit | SRC-1; RT-RTE-mcp-query, MEM-OBJ-record-payloads; profile limit | Accepted records establish the channel; profile requested-read unit names chat/editor only | Complete route-by-route read-back and transport comparisons; excluded host memory/action attribution | Dedicated classification unit for the recorded MCP request/return operation; host evidence under a separately authorized boundary |
| Returned counts/applied flags can exceed durable effects; recovery checkpoints can suppress replay | SRC-1; RT-RTE-file-extraction, MEM-OBJ-contradiction-block, MEM-OBJ-progress-state | Pipeline callbacks, conflict insertion and built-in checkpoint predicates | Terminal success or applied count certifying complete durable processing | Per-item durable-effect evidence and failure/retry traces; corrected admission/replay predicates |
| Source truth, mapping interpretation and selected-context completeness unverified | SRC-1; EPI-RTE-field-mapping, RT-RTE-knowledge-enrichment, EPI-RTE-derived-results | Configurable mappings, bounded model inputs/file selection and capped rule queries | Semantic preservation, accepted new facts or complete physical/contractual conclusions | Source contracts and reference comparisons, actual input/output instances, complete relevant-row/context coverage and scoped acceptance records |
| Deployment isolation and storage survival unobserved | SRC-1; RT-ABS-rest-auth, RT-BAP-native-module, RT-OBJ-knowledge | Shipped server, loader, lexical guard and deployment configuration; no operational filesystem/network/image evidence | End-to-end access control, sandboxing, proven image build or durable mounted KB | Build evidence resolving missing tracked knowledge input; deployed access controls, filesystem/mount configuration and persistence/isolation traces |
No unresolved cross-report conflict was supplied. Source-read log: none; this synthesis used only the handed members and added no evidence.