Skip to content

Limits and known behaviours

  • Context-model reads on large models. system.artekis.contextModel.get and the editor's open and save take about 1.7 s on a 242-asset, 19,400-tag model when the tag facts are read (the first read, or a minute after the last), and about 240 ms within the minute after. The read scans each tag provider the model names once, so a small model on a very large provider pays for the provider, not the model.
  • Alarm Health reach counts scan the provider once per run, capped at 20,000 tags; on a larger provider the instance count is a lower bound and the finding says so (instances_capped).
  • Bootstrap scans at most 20,000 tags and proposes at most 500 assets per draft; Suggest sends at most 200 tags per asset.
  • Journal reads stop at 500,000 transitions per run; the evidence bundle is cut to budget.maxInputTokens in a fixed order (table rows from the bottom, then trend points), and every cut is recorded on the run.
  • Documents: 25 MB per upload, 1,000,000 characters per document, 200 per collection, 60 s to parse a PDF; the search index is held in memory for the 8 most recently searched collections and rebuilt after any add or delete.
  • Ask: 8 tool calls, 9 model calls, 180 s and $0.50 per turn; 6 earlier turns per conversation; a tool result is sent to the model cut at 24,000 characters; the context model enters the prompt cut at 16,000 characters.
  • Gateway Health reads at most 200,000 log events and 20,000 tags per provider per run.
  • Cron: a missed minute (the gateway was down) is not replayed. A run queue holds 200 waiting runs.
  • Redundancy: after a crash the backup takes the database over after 5 minutes of lease silence (measured 359 s); runs the dead node left unfinished end FAILED(restart). Incidents queued when the module stops are lost.
  • Anomaly Watch: one run screens at most 31 days and stores at most 50 anomalies, strongest first; a run's history read is bounded by the run deadline (the playbook's timeoutSeconds, less up to 120 s kept for the model call); at most 20 detectors per asset and 500 per collection; a proposal stores at most 50 past fires; stuck and rate detectors are proposed with no expression, so their download is refused and Artekis evaluates them; an applied detector is no longer evaluated by Artekis, only read from the journal, unless the gateway has no journal to read; a data-health gap is reported only between two samples inside the window, so a tag silent at the window's start or end, or throughout, is not reported as a gap; the detector list reads at most 5,000 fires per collection (firesTruncated). The Core Historian reports an aggregated interval Good whatever its samples' quality, so quality is read raw, over the screened window only; a baseline therefore keeps the few non-Good samples it holds. Anomaly Watch has not yet been through a field trial on a plant's own historized data: tune sensitivity and thresholds on your first weeks of verdicts.
  • SQL Server: the finding text columns are NVARCHAR, so non-Latin tag paths and model text are stored as written.
  • Not in 1.0: Discovery sessions and the context-model interview (the interview arrives in 1.4.0, section 7.10), a webhook output, Word and Excel documents, MES and quality incident triggers, streaming model responses, a dead-tag analyzer, free-form SQL as a grounding tool (named queries only), the Bedrock, Vertex and Claude-on-AWS provider kinds, a graph canvas in the editor, and importing or exporting Artekis gateway configuration through the module.