Architecture

Malspark is a FastAPI service, an arq worker and a Next.js console over Postgres, Redis and MinIO. The service owns requests and state; the worker owns analysis runs and everything an analysis talks to — language models, static analysis tools, sandboxes, long-term memory and threat-intelligence lookups. This document describes the components, what happens during a run, and the pieces an operator can reconfigure.

ComponentsCopy Anchor Link

Request and job lifecycleCopy Anchor Link

1. The console authenticates and uploads a sample. The API streams it through UPLOAD_TEMP_DIR, hashes it, stores the bytes in MinIO and the metadata in Postgres, and writes an audit row. The object store's client is synchronous, so every call into it — the sample, an uploaded sandbox report, a delete — is made from a worker thread: a hundred megabytes sent from the event loop is a hundred megabytes during which the process answers nothing else, its own health check included.
2. POST /api/v1/jobs creates the job row, commits it, and only then enqueues run_analysis on arq under the same identifier, so the queue job and the database row cannot drift apart. A worker reads the row from a session of its own and cannot see one still inside the request's transaction: a job enqueued before its commit was read as "Job not found" and left pending for ever. An enqueue that fails commits the row as failed with the reason. A worker that finds no row reads again after 0.5, 1, 2, 4 and 8 s (JOB_ROW_READ_PAUSES) before it gives up, and marks a row that arrived meanwhile failed with how long it waited. An optional config object may override a handful of pipeline values, including profile, which is validated against the profiles the store actually holds.
3. The worker takes the job, re-reads the configuration from the settings store, downloads the sample from MinIO and mirrors it into SAMPLES_DIR so the Ghidra container can read it through its bind mount.
4. The pipeline runs. Each stage publishes an event on the Redis channel for that job; the API relays it to the console over /ws/analysis/{job_id}. Publishing is best effort — the database row is always written first, so a Redis outage costs progress updates, never the record.
5. The report is written to Postgres and becomes available under /api/v1/reports/... in every rendering the report service supports. A run that fails after its report was built keeps the report. The graph runs as a stream (astream in the modes ainvoke itself uses, so a run that completes ends in the same state), and MaljanApp.built_report holds what the report node returned, merged into the state it was built from, from the moment it returns. When the graph then raises — a later node, or LangGraph refusing the writes of the report's own step — the worker marks the job failed as for any failure and stores that report against it, with its findings, ledger and transcript, and with analysis_reports.incomplete_reason set to one sentence: where the run failed (node <name>, or the graph step whose nodes' writes were refused), the exception's class and the error id, never its message. The same sentence is added to the report's and the run summary's degradation reasons, so the console's degraded banner, the header notice beside the failure note and the markdown and HTML renderings all say the report is incomplete. The job stays failed. A graph that returned and a result the worker then refused — an absent analysis, a report node that answered with an error — keeps nothing. Neither does a run that was cancelled, by the operator or by arq's job timeout, after its report was built: both reach the pipeline as a cancellation (CancelledError, JobCancelled), not as a failure, and the job ends cancelled or is swept, not failed. A report stored against it would be a result for a run somebody stopped, and the worker leaving on a timeout is a process going down with no session to store it in. Only the report node's own update is merged into the state it was built from: the report stage waits for every stage it depends on, so no node of a team finishes in the report's step (the stage-graph test pins that the report runs in a step of its own).
6. Threat-intelligence enrichment runs afterwards as its own job, on the enrichment worker's queue, so it delays neither the verdict nor the next analysis.

The two worker processesCopy Anchor Link

uv run arq app.worker.analysis_worker.WorkerSettings
uv run arq app.worker.enrich_worker.EnrichmentWorkerSettings

The analysis worker reads arq's default queue and runs one job at a time: two analyses on one host would share a model, a sandbox and a memory budget sized for one. The enrichment worker reads arq:queue:enrichment and runs two at a time (ENRICHMENT_MAX_JOBS), because a reputation lookup waits on somebody else's HTTP.

They were one process, and the single slot was the cost: a measured enrichment spent 451.98 s at VirusTotal while the next analysis sat pending for 4 m 33 s. Nothing about that lookup needed the rule it was subject to.

Which one a deployment gets. api.enrichment_dedicated_worker decides, and it ships off: a release that is taken and run unchanged keeps one process, and nothing stops working because a process nobody started is missing.

On that one queue the enrichment gets out of the way rather than merely waiting its turn. arq pops by score, so an enrichment queued a second before an analysis would otherwise run first and the analysis would wait for all of it — 452 s in the run this was filed for. When the task starts there it reads the analysis queue first, and if anything but another enrichment is waiting it re-enqueues itself 60 seconds later and returns having done nothing. The total deferral travels in the job's own arguments and is capped at 30 minutes, after which it runs whatever is queued: an analysis waits for at most one enrichment per cap window, and a steady stream of analyses can never starve the enrichment. An enrichment already running is never interrupted — that is what the second worker is for. The compose stack runs the second worker and sets ENRICHMENT_DEDICATED_WORKER=true beside it, which is the default the setting falls back to; an operator's saved value wins over both. Turn it on wherever the second process actually runs.

When it is on and nothing is reading the enrichment queue — arq's own per-queue health key is absent one health interval after the analysis worker boots — the worker logs one warning naming the queue and the command that reads it, and GET /api/v1/system/status reports enrichment_worker as down. Queued enrichments are kept, not dropped: they run when a worker starts.

The task is registered on both workers so the single-process default has something to run it, and the nightly job_events purge stays on the analysis worker: one owner per scheduled task. The enrichment worker runs ENRICHMENT_MAX_JOBS (default 2) at a time — more than one because each job waits on somebody else's HTTP, not many more because they share one VirusTotal key and one AbuseIPDB key and a provider's rate limit is per key.

What the worker holds while a run is in flightCopy Anchor Link

No database transaction. The worker opens one session before the models start — the job row, its sample, the stored settings, any attached sandbox report, and the move to running — and closes it again before the pipeline is built. The run's writes open sessions of their own: the event feed's batches as they fill, and one transaction at the end for the report, the agent findings, the evidence ledger, the transcript and the completion, which go together because the report's sections cite the ledger's ids.

A session held for the length of an analysis is a backend sitting idle in transaction for as long as the run takes. One was measured at 13 minutes 51 seconds, holding an AccessShareLock on analysis_jobs, analysis_reports and runtime_settings: a migration's ALTER TABLE analysis_reports queued behind it, every read of that table queued behind the ALTER, and GET /api/v1/jobs/{id} timed out for four minutes while /health answered in milliseconds. The enrichment task follows the same rule — it reads the report's payload, closes, spends as long as the reputation lookups take (452 s on one measured report), and opens a second session to write the result.

A failed run records its failure through a session of its own. The session the run was writing through is the one most likely to be unusable — a terminated backend leaves every statement on it raising PendingRollbackError — and that is how a job came to publish its error event and still read running, with no error and no completed_at, for as long as the worker stayed up. What the row then says is the class of the exception and the id of the log entry holding the rest: error_message is a field of JobResponse, so an exception's own message put there is published, and a failure names a path or a connection string as readily as anything else. The exception to that is StatedFailure and its subclasses — the failures this module words itself, from constants and from ids this system issued — whose sentence is the answer and travels whole: an absent analysis, an attached report that belongs to another sample, a sandbox provider that cannot take one.

Who owns a running jobCopy Anchor Link

The worker that is running it says so, and keeps saying so. While run_analysis runs it holds maljan:job-owner:<job id> with its own id in it, for 90 seconds, refreshed every 30 by a task of its own; the key is dropped on success, failure and cancellation alike. A running row whose key is absent is a row nobody is working on.

Neither of arq's own keys can answer that question. The in-progress claim (arq:in-progress:<job id>) is written once and lives for the job timeout, so it outlives the process that wrote it by hours; the health key is queue-wide and lives 31 seconds past its last write, so a worker killed a moment ago still looks alive — and a restarted container looks at it within seconds of that kill, which is exactly the case the sweep exists for.

The sweep therefore runs on its own clock rather than at the instant of startup: one owner TTL after the worker boots, so a crashed worker's last heartbeat has certainly expired, and every ten minutes after that — which is also what reaches a job a still-running worker gave up on, the case that left one job reading running for an hour. Two rules point the other way, both towards leaving a job alone: a row younger than one TTL is left for the next pass, because a worker may have claimed it a moment ago, and a job this process is running is never swept whatever Redis says. If Redis cannot be read, nothing is touched and the reason is logged once, because ownership cannot be established without it and guessing costs somebody else's run.

A run that ends in CancelledError is told apart by the cancel flag the API writes when somebody presses stop (analysis:{job_id}:cancel, which the heartbeat also polls). The flag is there: the operator asked, so the task writes cancelled on the row through a session of its own, whether the heartbeat noticed or the cancel landed between two of its polls. No flag: arq's job_timeout or a worker shutting down, where the process is going away and writing a row races its own teardown — the heartbeat goes with it, so the next sweep pass marks the job failed within ten minutes.

A cancel stops the run as well as marking it. Each job carries one cancellation (maljan.core.cancellation), bound for the whole run: every graph node checks it on the way in, every LangChain model call the job makes — in a node, on the agent loop, in a thread started from either — checks it before anything is sent, and every call the job has in flight on the agent loop is registered with it, so a cancel cancels the model request itself and the server stops generating. A check raises JobCancelled, a BaseException, so no node's own except Exception reads a cancelled job as a failure and carries on, and the bridge to the agent loop passes a caller's own cancellation on instead of turning it into an ordinary error. The heartbeat sets the flag before it cancels the pipeline task; a job task that is itself cancelled — by SIGTERM or arq's job_timeout — sets it, cancels the pipeline and waits for it at most PIPELINE_STOP_GRACE (10 s). The cancelled event says where the pipeline stopped (stopped) and how far into the run (seconds_into_run): the place a check recorded when a check stopped it, otherwise the graph node that was running when the task was cancelled under it (each node records on the job's Cancellation when it starts, finishes, or is ended by a cancel). The analysts' model calls — the tool loop, the salvage, the validation turn, the revision rounds, the view and tier turns — all go out as the model's own async call on the agent loop, so each is cancelled in flight. A thread still blocked in a call that cannot be — a provider with only a synchronous client — is not waited on at exit either: the shutdown hook arms a guard on the interpreter's own exit, which ends the process with status 1, naming the threads, if a non-daemon thread is still alive EXIT_GRACE (10 s) after the exit began, and does nothing otherwise. The shutdown hook's Redis and database closes are each held to the same grace. SIGTERM therefore ends the worker within 10 s for the pipeline, the job's teardown (WORKER_TEARDOWN_TIMEOUT, 60 s), 2 × 10 s for the closes and 10 s at exit.

What a request holds while it waits on somebody elseCopy Anchor Link

Nothing either. A request-scoped session is in a transaction from its first statement — on an authenticated route, the dependency that resolved the caller — and stays in it until the handler returns, so a handler that then waits on a third party leaves a backend idle in transaction for the length of that wait. The routes that do wait end the read first, through database.end_read_transaction: the three probes (/settings/test/{probe}, /test/mcp, /test/agent, up to five minutes at a model endpoint), the VirusTotal registration, and the long-term-memory purge, which walks the whole configured store. The session stays usable; the next statement opens a transaction of its own.

The WebSocket route holds no session across the stream at all. The handshake reads the account and the job's owner inside a session, closes it, and then accepts or rejects; a resume reads one page of the feed per session and sends it after that session has closed, because the send goes at the client's pace and a thousand frames to a slow reader is not something to hold a transaction across. The account re-check on the clock opens a session of its own each time.

Format routingCopy Anchor Link

The platform never refuses a sample for its format. The first thing a job does is read the sample's magic bytes into a file type and a platform (src/maljan/extractors/sample_identity.py), and everything downstream routes on that answer: which sandbox package or VM profile is asked for, which tools an analyst is given, which rules the Sigma and YARA layers keep, which ATT&CK domain a technique id belongs to, and which artefacts the analyst prompts are told to look for. A format nothing recognises routes to the neutral path — a raw-byte sweep and a report that says so — rather than to a rejection. Deterministic code decides the routing; the analysis itself is the agents' work over whichever tools the operator connected for that format.

The pipelineCopy Anchor Link

A LangGraph StateGraph over one shared state (src/maljan/pipeline/). The triage pack runs first; the analyst stage after it has two shapes, and the job's analyst mode (llm.parallel_analysts: auto, true or false) chooses between them for a stage that sets no mode of its own:

START
  │
triage_pack   the deterministic tools, run by the pipeline, one ledger entry each
  │
  ├─ sequential  (false; auto on a single-slot local server)
  │     static_analyst -> dynamic_analyst -> network_analyst
  │
  └─ parallel    (true; auto on a hosted API or a multi-slot server)
        the pack fans out to all three, then fans in
  │
negotiation  <-------- revision
  │  (consensus, or the iteration cap)   ^
  └─ no consensus -----------------------┘
  │
judge
  │   inside this node: the evidence summary, the degradation note, then
  │   the STIX 2.1 bundle and the judge's own severity, category and family
  │
report  ->  END

Every mediation runs the judge's tool loop, the first round as much as any other: there is no single call without tools for a round in which no analyst wrote explicit dissent. The loop offers the judge's tools, read_evidence from its first turn, and an ask_<agent> tool for each agent the judge's definition names (the reverser and the static analyst in the seed, with the job's sandbox report tools beside them), and the model decides whether to read, look up or ask anything; a round that needs nothing answers on its first turn and pays only for the tool definitions it carried. The prompt's sentence about tools is the one every agent gets (tools_statement), after the reputation sentence when no analyst consulted one (judge_agent.mediator_system_prompt). A loop whose answer is empty and was not cut at the output cap is run once more as it was sent; a cut answer, or a loop a limit ended, is not.

The mediator reads each analyst's report under its heading, then, under === STRUCTURED CLAIMS (ISR) ===, the ISR summary of every analyst whose report is not that summary word for word (judge_agent.mediation_reports_text). A first answer reaches the debate as its ISR summary, so a first mediation reads each claim once; a revised report, the analyst's own words, is read beside the claims in force. The block is left out when no summary is left.

Agreement is measured only between analysts that produced claims. With fewer than two of them, or a debate stage that did not run, consensus is not applicable: the mediator still speaks and its words are kept, but no agreement value is extracted or recorded — is_consensus is null beside consensus_applicable: false, the confidence series gets nothing, the run summary's negotiation.termination_reason is not_applicable with no final_confidence and no converged_early, the report prints one sentence saying so, and the loop goes to the judge without a revision round.

A mediation that raised or timed out measured no agreement either. Its round is recorded with is_consensus: null beside consensus_applicable: true, nothing in the confidence series, the mediator's argument carrying no confidence and its status (failed or timeout); the run summary's termination_reason is mediation_failed with no final_confidence, and the loop goes to the judge. It used to record 0.0, which the run summary then published as the negotiation's final confidence.

Consensus is decided by the mediator's final CONTRADICTIONS: block. After its reasoning the mediator writes that block, one line per contradiction still standing (the analyst, its claim, and what contradicts it: another analyst's claim or a ledger entry id), or CONTRADICTIONS: NONE, then its agreement_confidence line. A contradiction includes a claim an evidence ledger entry contradicts. Only that last block is read into the verdict's contradictions, on the text path and the structured one alike; contradictions the reasoning drafted and then resolved are not counted. A non-empty block is not consensus whatever number the mediator wrote: the number is kept and shown beside the list, and the router sends the analysts to revise, each told the block's lines. The block is one contradiction per line, bulleted, numbered or plain, the label line's own text included; a table's border and header rows and a summary line are not contradictions. A "none" empties the block only as its whole content, and only as a whole line from a closed vocabulary ("NONE", "(none)", "N/A", "No contradictions", optionally "still standing", "stands" or "remain(s)"): "None of the analysts cites ev_0015 …" is a contradiction. A "none" beside contradictions is not read, the contradictions stand, and the round's note and negotiation.mediation_notes say the block was mixed. A block of only table rows is unreadable and asked about once. So is a NONE whose other lines are all plain, most often the mediator's own closing sentence, and a lone label-line phrase opening with "none" outside the closed wording ("none that survive scrutiny"): answered with a NONE again, the round reads as the number says, and answered still mixed, the listed lines stand with the note. Label-line text ending in ":" introduces the list and is not a contradiction. On the structured path the block, when present, decides over the extractor's list. While the last mediation lists a contradiction, a stable agreement number does not end the debate as convergence; the round limit still does. An answer with no block is asked once for it, with no tools, after the mediator's own answer; still without one, the round's note and the run summary's negotiation.mediation_notes say so, and agreement is read from the number as before. A run's mediator listed five contradictions, one of them a claim the ledger contradicted, argued them away, wrote agreement_confidence: 1.0, and no analyst was asked to revise.

The debate ends when nothing is left to settle (pipeline/debate_facts.py, pipeline/claim_drops.py, pipeline/routing.py):

• The mediator ends each line of its block with [blocking: <reason>] or [not blocking: <reason>]; consensus is its confidence at the threshold with no line marked blocking, an unmarked line blocks, and the platform overrides a mark in neither direction. The reason may hold one level of brackets ([not blocking: see [ev_0021]]); a [not blocking] mark with no reason, conflicting marks and a mark that cannot be read block and go to negotiation.unread_marks, and a [blocking] mark with no reason blocks as it asks.
• For a listed line whose cited entries (cited by the line or by a claim it names) hold, in a field named for a count or a total, a number the line itself states, every such value is stated; the length of a list field (a match list: matches = 0 items) only where its key names the noun the line counts with that number ("0 hits" for matches, a hit being a match; "3 domains" for domains). A size or a time is not a count. No call is made for them: they ride on the revision directive of the analysts the line names and on the next mediation's prompt, and a debate that ends at this mediation spends nothing on them.
• A blocking line the ledger states, told before, is recorded and shown, never taken away (debate_facts.ledger_stated). Its dispute must be about a count itself: two sides of the line (split at "while", "whereas", "but", "against", "versus", "although", "however" or a semicolon) each write one number, in digits or a number word, directly before one noun (at most one word between), and the numbers differ ("three matches" against "0 hits"). Two numbers on one side ("31 rules loaded, 3 matched") are two quantities, and a partitive or a ratio ("one of the rules", "0 hits of 31 rules", "3 out of 31", "3/31") is no count of its noun. "Hit" and "match" are one noun, a closed and deliberately minimal vocabulary; a line whose sides read counts both accept differently ("0 matches as benign" against "31 rules as malicious") is a dispute about meaning and is never stated. Every count it states (a number before a plural noun, "0 hits", "31 rules") is stated by a cited entry in a key naming that noun, the cited entries agree (every cited field of a counted noun holds one value) and are one record (an entry naming one of the line's nouns names all of them, so "0 connections" in one entry against "2 domains" in another is a dispute about meaning, not a count), and every fact stating one of its counts was stated by an earlier mediation of the debate. The line stays among the blocking lines, so the mediator, the judge and the report see it; it is said to the room, recorded in AgentArgument.ledger_stated and run_summary.negotiation.ledger_stated, and shown to the next mediation, which decides whether it still blocks. When every blocking line of a mediation is such a line, the debate ends as ledger_stated, with no consensus claimed. A line with a count no entry states, or with no count, is never stated, and a fact not yet told keeps the line out for the one round that tells it.
• The mediator opens each line with [analysts: <name>, <name>], the analysts who must revise over it, written as their reports are headed. A revision round asks only the analysts the blocking lines name; every other analyst keeps its answer in force, recorded in the round's not_revised as not asked: not named by the mediator. A named analyst's revision is shown the blocking lines that name it, with the mediator's summary and confidence, and of its peers only the ones those lines name, in the field or by key or label in any case or form; each is shown exactly as a round asking every analyst shows it, its answer in force whole, with no claim picked out by its number. A block that lists no blocking line holds no revision round: the debate goes to the judge as consensus; below the threshold, a stable confidence series still ends it as convergence, and otherwise it ends as no_contested_point. A blocking line without the field or naming no analyst of the debate, or a block that was not read, asks every analyst with every peer's answer, as before, and the round's record says why under asked_all.
• Sycophancy is a rise in likeness beyond shared sources, told and never enforced (pipeline/sycophancy_detector.py, convergence_flags). After each revision round, for each analyst revised that made no tool call and whose revision cites nothing its answer before the round did not (an entry the platform showed it in the round, a peer's tool result among them, is no citation of its own, and that entry's words are left out like a shared entry's: agreeing with what it states is no move, agreeing beyond it still is), the words of every ledger entry or sandbox item it and a peer both cite are left out of both, and its answer before the round and its revision are each compared with the peer's answer in force (bag-of-words cosine); a revision above the threshold and above its answer before the round is flagged and recorded on the round (revision_rounds[].converged). Two answers alike because they restate the same rows, or alike before the round, are not flagged. A flag is put to the next mediation as a sentence beside the facts block (convergence_sentence) and kept on the mediation (AgentArgument.converged); no analyst's prompt carries it, it never overrides the mediator's consensus or a block with no contested point, opens no round and never widens a round that asks only the analysts the mediator named. A stage with sycophancy_check off is told nothing. A round record stored before the flags existed is read by whole-answer likeness, as before, and decides no route either.
• For a blocking line naming a function the run knows (an address the line writes, or one a claim it names writes, that is a row of the function index or a function a decompile or disassembly call listed; an offset and its virtual address are one function where an image base the run read joins them), the platform states whether the ledger holds a listing of it and which entries hold it (debate_facts.place_facts, AgentArgument.place_facts, said to the room as a notice). The analysts the line names in its field (every analyst, for a line with no field) are told it in their revision. An analyst with a tool whose declared arguments take an address (undeclared_tools.address_arguments, read from each tool's own schema) is also told it can read a function the ledger never listed in this round. Every revision carries the analyst's own tools wherever its model binds them: a configurable analyst's revision is its tool loop already, and a built-in analyst's revision runs its tool loop in place of the one tools-free call it was (BaseAnalyst.revision_answer, safe_revise_isr), which it is still where the analyst has no tools or its model cannot bind them, with a degradation reason saying so. A tool-carrying revision is a full loop: its own time and steps, the no-tool-call question (asked at most once per analyst per job), and a validation turn held to what the revision's loop left. The model decides whether to read; nothing is adopted or rejected for it, and no call is made for the facts.
• A named analyst's revision is also shown, after the feedback, the stored text of the ledger entries the lines naming it cite and of one listing of each function their place facts name (debate_facts.line_entry_ids), each whole as it had it in view and shown through the one view of a tool answer, fenced, so a run-state block or a heading the sample wrote stays data (base_agent.cited_entry_texts, tool_fence.fenced; the validation retry and its drops question read entries the same way): a peer's tool result is in no input of its own, and before this the analysts were asked to check entries only the reverser had read. An entry its brief or its raw data already holds is left out. The entries take what the input room leaves beside the raw data, which they never shorten; one that does not fit is named by id (debate_facts.fit_entries, safe_revise_isr(cited_entries=...)), and the entries shown are grounds for the revision's checks as its raw data is. The next mediation is shown the same entries for the last mediation's blocking lines, in the room its reports and history leave. The mediation's entries also leave room for the turns after its first: one tool answer's share of the window (context_window.ANSWER_SHARE), the first answer at the output cap and the question for a missing block. Showing an entry raises no corroboration count: a technique's sources are ledger entries, each counted once however many analysts cite it, and a revised claim citing only entries of other agents the debate showed its analyst (in this round or an earlier one, revision_rounds[].shown) is marked (ClaimEvidence.rests_on_shown_entries) and counts as no sayer of its own unless it also cites an entry its analyst filed (validation.shown_claim_unbacked, read where tool_backed_answers reads a retry's claims).
• After a revision round the next mediation is told, for each blocking line of the last mediation, numbered, who it named, who revised, the entries of the line each was shown, and who changed a claim anywhere in its answer (claim_drops.changed_anywhere, read by the reworded route's own key claim_substance, claim for claim with counts: a claim added or removed, or one whose values, cited entries, technique, negators, confidence step, technical terms or content words differ, whatever it cites; reordering, punctuation and stopwords are no change, any other rewording is, by design, so the stop rule errs towards another round; an answer whose claims cannot be read is a change; an analyst that filed entries in the round changed), then the entries the round filed by agent (debate_facts.round_facts_text, revision_rounds[].lines and filed). It is asked once to write [carried: L<n>] after the field of each blocking line that raises line n again, or [new]; the mark is no part of the point (debate_facts.carried_marks, AgentArgument.carried).
• A revision round whose every revision is the answer in force again, whitespace aside, ends the debate as converged; the router reads only the record of the round right before the mediation it routes.
• A revision round whose every revision states the claims in force again, wording aside, ends the debate as reworded, with no consensus claimed: another round would argue over words. Nothing factual may change: each claim's values (numbers, hex addresses, technique ids, quoted values), the entry ids its evidence line cites, its technique, its negators ("not", "no", "never", "without", a word ending "n't"), its confidence in steps of 0.05, its technical terms (acronyms, identifiers and names holding a digit, folded: RC4 against XOR is a change) and its content words (every word but articles, prepositions, "and", "so", pronouns and forms of be, have and do, read before the plural fold; "or", "nor" and "but" count; case and plural folded: "three" against "four", "explorer" against "svchost", "packed" against "unpacked" is a change) are the same, claim for claim; a reordering, punctuation or a stopword is wording (claim_drops.unchanged_in_substance, recorded as reworded in the round's record). A claim that cannot be read so, or any difference, leaves the round not reworded, and the debate goes on as before.
• A revision's tool loop is seeded with the calls the analyst made in the run's earlier rounds to a tool that changes nothing and answers an identical call the same: one its server marks read-only (MCP readOnlyHint) or its declaration marks read_only (base_agent.repeatable_earlier_entries, tool_pinning.answers_again). A call of any other tool (a rename, a status poll, a submission) runs again, and so does a call whose earlier answer was a failure, carried a reason, an error or a message, or a status other than a word of completion such as "pending" (evidence_recorder.holds_a_settled_answer); an empty answer that nothing explains, alone or beside a status "ok", is settled and seeded. A tool is matched by its server and its name together, never by its name alone. A seed holds only while no call that is not read-only has run on the same server (its server key, else its source) since its entry was recorded, by any agent in any earlier round (base_agent._stale_after, newest first by seq, or by ledger order where a row has none) or in the current loop (RepeatGuard.forget_round_seeds): a rename or a patch makes a later decompile of that server a new call. An identical call (same tool, same arguments; an argument named for an address in the binary compared by its value where it is written with 0x, and a bare spelling holding a decimal digit and a hex letter, for an argument whose name has no name word, answered from an entry a 0x call made, never the other way) is answered with the result its entry recorded, stamped with that entry's id and a sentence saying it was made in an earlier round, and no tool runs; the call is filed as a repeat of that entry. A failed call, and one whose result the run did not keep whole, is served once more, as for a chunked analysis.
• A revision round that revised analysts and left the contested points as they were ends the debate as contested_points_unchanged, with no consensus claimed. A point is read from its blocking line alone (debate_facts.point_key): the analysts its field names, the ledger ids, hex values and decimal numbers it writes (claim numbers aside, since a revision renumbers claims; the mark and its reason aside), and its words where it writes none of those; two mediations whose blocking lines hold the same points, none resolved and none new, are unchanged however the mediator reworded them. The debate ends the same way when the mediator marked every blocking line carried and, for each, the line shares an entry id or a place with the earlier line it names (a mark naming a line about other things is no mark), every analyst it names was named on the earlier line, every analyst the earlier line named revised in the round, and none of them changed a claim of its answer in the round (debate_facts.carried_unmoved; conservative by design); a line marked new or not marked, or an analyst that has not answered the earlier line yet, leaves the debate going as before.
• A revision is made against the analyst's answer in force and its peers'; each value of the answer in force it states nowhere is recorded in run_summary.negotiation.dropped_claims (a decimal only as a stated value, never a claim, round, step, stage, phase or list number, nor the round's own number; nor a cross-reference to the answer's own numbering such as "#3" or "item 3"; a number after any other word, such as "line 75", is compared as a value), the report's run appendix prints one count line per analyst and round (dropped_value_counts), the worker log one count line per analyst and round at INFO with each claim's sentence at DEBUG, and nothing is asked.
• The debate stage's duration adds the revision rounds' time to the mediations', and termination_reason comes from the router's own rules, hard_limit only when the debate would have gone on.

A single local model server has one slot, and fanning out three analysts onto it produces queue thrash rather than speed; a hosted API serves each request on its own. auto tells them apart per job (pipeline/analyst_mode.py), on a thread before the job is built: Ollama, or an OpenAI-compatible host that is or resolves to a local address (or is a name only a local resolver answers, like host.docker.internal), runs the analysts one after another unless its llama.cpp /props reports more than one slot; a host that resolves only to public addresses runs them in parallel; one that does not resolve runs them one after another. A revision round follows the stages it revises, and the run summary's profile.analyst_mode says what every stage and round ran in and why.

The triage packCopy Anchor Link

Before any analyst starts, the pipeline runs the deterministic tools itself (src/maljan/pipeline/triage_pack.py) and writes each result to the evidence ledger as an ordinary entry under agent="pipeline", server="pipeline". A human analyst runs the same dozen commands on every sample before opening a disassembler, and the live runs showed the local model rarely asks for any of them; a fact a model may or may not ask for is not a fact a run can rely on.

The pack is a list of steps declared as data (maljan.core.pack_steps; an operator lays their own over it in triage.steps, see The pack's steps in configuration.md): each step names its tool and server, an argument template, the routed formats it runs for, its budget, whether it starts beside the others and beside which, the renderer of its pack line and the kind of answer it records. A step with a server is any tool server's tool, called through the tool server registry exactly as an agent's call is and recorded under that server at its place, so an operator hands monotonous work to a tool rather than to a model. A later step reads an earlier answer by its declared kind, never by the tool that gave it. The shipped list is the same code the analysis sidecar serves, called in-process, in a fixed order so the ids a sample produces are the same from one run to the next: identify_file and hashes; signing_info for the routed format alone (Authenticode for a PE, with the signer's subject, issuer and thumbprint read out of the certificate table and no chain verdict claimed; the APK signing block for an APK; LC_CODE_SIGNATURE for a Mach-O; and for anything else the fact that it has no signing scheme); the format tool the routed type selects (pe_info, elf_info, macho_info, apk_info, document_info or archive_list, which carry the section entropies, the packer signature hits and the import rows); the identification servers' steps, each off (no call, no entry) while its server is not switched on: die_scan (Detect It Easy) on every sample, then dotnet_types (ILSpy) and go_symbols (GoReSym) where die_scan's declared name value says .NET or Go (see Identification servers); the document servers' steps, each off the same way and each on the routed format: ole_vba (oletools) on an Office container, office_dde on an Office container or an RTF, rtf_objects on an RTF, js_deobfuscate (webcrack) on a JavaScript, HTA or WSF file (see Rule and document servers); the container and Android servers' steps, each off the same way: container_extract (unblob) on every sample, each file it wrote taken into the job's artefact store, and android_classes (JADX) on an APK or dex file (see Container and Android servers); a strings head capped by triage.strings_head and iocs_from_file (its indicator scan reads printable ASCII and UTF-16LE runs; a UTF-16LE host written directly after a NUL-terminated ASCII string can be read with that string's last letter in front of it, because the bytes are the same either way); yara_scan, capa under the static provider's budget and, when a sandbox report exists, sigma_match_sandbox; api_capability over the import set (asked about the routed format's own platform, and a format the catalogue has no block for — a Mach-O, an APK — is not asked, so it yields no profile and no rule hit) and lolbin_lookup over the sandbox's command lines; the sandbox projections at summary level (processes, network, signatures, dropped files, channels) and pcap_summary when a capture was fetched; one reputation lookup on the sha256 (the first enabled server's tool that declares kind: reputation and a hash argument, lowest declared rank first: with the shipped declarations get_file_report on virustotal when it is enabled, else check_hash on threatintel), made through the tool server exactly as an agent's call is and recorded under that server, its answer read once through the tool's declared paths into the reputation record every reader reads; function_matches when the configured memory backend keeps a function-hash store and a provider that hashes functions is present; and, last, for a PE, floss: FLOSS's decoded, stack and tight strings, recovered by emulation (the sample is never executed) through the same tools.emulated_strings function the sidecar's floss tool serves — its pinned build, 600 s wall clock and 4 GiB address-space limit — with the analysis server's environment (so MALJAN_FLOSS_PATH there is honoured) and a directory inside the job's staging directory that the job's teardown removes. The entry keeps up to 200 rows. It is last so the ids issued before it are the ids they were before it existed. Without a build the entry says so, with the remedy, and is not a failure; a run stopped by its wall clock or its memory limit is a failed entry whose line says which. FLOSS reads the file and nothing the pack writes, so its step declares that it starts right after signing_info, when the routed format says PE, and runs beside the rest of the pack, beside capa's step — when there is room for both. Running them together adds their peaks, so what they need is each step's peak: capa's as this worker measured it (the capa child reports its own peak resident memory before its answer, and the largest one seen is kept) plus FLOSS's 4 GiB address-space bound, its declared peak_mb; any step an operator declares with starts_after and beside is sized the same way, from its measured or declared peak. The host's MemAvailable less that must stay at or above triage.memory_floor_mb (10,240 MiB), and the worker's own cgroup limit, where it has one (memory.max less memory.current, or cgroup v1's memory.limit_in_bytes less memory.usage_in_bytes), must hold both: inside a container MemAvailable is the host's figure, and the container's limit is what an allocation meets first. Otherwise — the first capa run of a worker, which has nothing measured yet, a host with a local model loaded beside the worker, a container with its 8 GB limit — the two run in turn, and run_summary.triage.floss (the step's id) says which and why ("beside capa", or "in turn: …"). Its entry is written in its place either way, with its own clock, and a run it began within the pack's budget is recorded whatever the clock says by then. Measured on PuTTY: 312 s in turn, 183 s beside capa; the pack's process tree peaked at 1.6 GB and 2.3 GB resident.

After FLOSS, for a PE, the platform's own two readings of the file's bytes, in seconds and with nothing run: resolve_api_hashes (tools.api_hashes), the 32-bit values the file holds that are hashes of Windows function names under a vendored set of published algorithms, each with every reading and every place the value stands; and decode_string_blobs (tools.string_blobs), the text its data sections keep encoded under a stated set of generic key schemes, each with the code that refers to it and, when FLOSS recovered the same text, FLOSS's routine. Where a reference loads the address of the text's encoded bytes as a call argument, the decoder states that call beside it, as the call the encoded bytes are passed to (passed_to, address_of: the callee and the argument position, tools.call_sites): an x64 lea into rcx, rdx, r8 or r9, or an x86 push of the address or a store to [esp+n], confirmed as an instruction by decoding its function from the start, then decoded instruction by instruction to the first call in the same function. The callee is the import the file's import table puts in the slot a call or a jump thunk goes through, the function at a direct call's target, or the slot a runtime pointer is read from. A jump or return before the call, a byte the decoder cannot read, the function's end, a write to the argument register, another stack move for a pushed one, or a call through a register leave it absent. After that call, the walk follows to the next call in the same function that receives one of two things (output_passed_to, x64): the one frame slot whose address the call was given as another argument, else its return value in rax. It is said as a fact about the slot or the register ("the frame slot [rsp+0xa0], given to that call as argument 2, is then argument 2 of the call at …"; "that call's return value in rax is then …"), never as what the first call does with it. One hop more, the same walk runs from that later call: its own output_passed_to names the next call that receives the frame slot the later call was given as another argument, else its return value, with the callee and the argument position, and nothing is followed past that call; each hop is absent on its own when the code does not show it. Where the first hop's call reaches a function of the file (no import), that function is read from its first instruction (inside): the first call in it that receives the argument register the value arrived in, an argument spilled to its home slot and read back after a push or a sub rsp being the same slot; any other stack or frame pointer write leaves it absent, and nothing deeper is read. Which call is stated never depends on what the code writes on the way; whether the followed slot, or the argument inside, reaches that call as the decoder left it is a flag of its own on the hop and on inside (contents_unchanged). It is false after a store through a register holding it or a string store through rdi holding it, and, while a frame slot is followed, after a store into the frame at or above the slot's start, a store through any register holding a frame address, a string store, a frame store with an index register, or a call given a frame address before the call that receives the slot. A call through an import or a slot states its stack arguments that a mov [rsp+d], imm32 in the straight run before it sets (constants, by argument position). The walk tracks registers and frame slots, ends tracking of a slot any store overlaps (sized by the store's width, SSE and VEX stores included; within 16 bytes where the width cannot be read), follows unconditional jumps and falls through conditional ones (said), and is absent at a return, an undecodable byte, a jump back, the function's end or a stack or frame pointer write. Both state addresses as offsets from the image base and the function around each from the file's own function table (tools.pe_image), and neither guesses one. The decoder runs after FLOSS so it can read FLOSS's kept result; both run after every other step so no earlier id moves. Where the resolution names functions the import table lacks, the pack then records one more api_capability entry, last, with those names as resolved_names and no import names, under the platform the import-set lookup was asked under: the capability picture of what the sample resolves at runtime, marked as such. The analysis server serves the same two functions (see its README for the algorithms, the schemes and the readability test). A domain, an address or a URL in a decoded text is hidden text the platform recovered, and the publish rule reads it as it reads a FLOSS decoded string (see "A value a tool recovered from hidden text is a source of its own" under the indicator rule).

The deobfuscation passes come after all of that, last for the same reason, and run on every run rather than when a model asks. First find_crypto_constants (tools.crypto_constants) over an executable image, given capa's function starts: the published constants of ciphers, hash functions and checksums, each set computed from its definition, a table found whole and other sets by two of their values, each with the places it stands and the function around them. Sets that share values are named only by a value that tells them apart: MD5's initial values are SHA-1's first four, so a set needs SHA-1's fifth, within 64 bytes of them (found by bisecting the sorted places, so the check stays O(n log n) on any layout), to be SHA-1 and is otherwise the MD5/SHA-1 family; SHA-256's and SHA-224's values are halves of SHA-512's and SHA-384's, so a half that sits inside a 64-bit value found is that value's, and halves standing beside the other halves are the SHA-2 family. A set whose algorithm capa's rules name at the function its place stands in is said to agree with capa there, not repeated. Ghidra's own detect_crypto_constants answers "not yet implemented", so the platform scans itself; the analysis server serves the same function.

Then the static provider's anti-analysis scan (analysis.anti_analysis), asked through StaticProvider.anti_analysis_scan of the run's configured static provider first and then of each other static provider of the run's profile; the first that can scan makes it, a provider's sentence saying why it cannot is recorded only when none can, and with none offering a scan there is no entry. The pack records the scan under the step name anti_analysis_scan; entries stored under its old name, find_anti_analysis_techniques, and a triage.steps declaration naming the step by that id, are still read as the same step. Ghidra's is its find_anti_analysis_techniques (providers.static.ghidra.passes), the sample opened the way the sink pre-pass opens it (load, switch, auto-analysis). Ghidra's answer is kept whole, each address also as an offset from the image base Ghidra reports, and only its exact part is stated: an instruction that is the listed one (Ghidra matches mnemonics by prefix, so it files INT3 under INT 0x2d), and a read through FS:[0x30] or FS:[0x18] exactly where a capa rule in the same function agrees; the line names the rule and the provider by its display name, and the entry's arguments name the provider. The rules compared are the rows of every pack answer of declared kind capability_rules. Ghidra's scan looks for FS reads only, so an x64 file's code bytes are read for the GS ones (anti_analysis.gs_reads): a GS-prefixed mov r64, gs:[0x60] or gs:[0x30] (65 48 8b 04 25 and the address, or 65 48 a1 and an eight-byte address) is a TEB/PEB row beside the FS ones, stated the same way, in a file whose machine field is AMD64. Where the file's own function table (.pdata) holds the address, it agrees with capa only through the function that range belongs to, so a library function capa leaves out is never taken for the user function before it, and the range is decoded from its start: a match no decode lands on is still a row, ending "not on an instruction boundary decoded from the function start", since a table shaped to miss a read would otherwise hide it. Each byte of a section is decoded at most once, into one map of instruction starts, however many ranges overlap or nest. Outside every range the byte match alone is read and the nearest capa function start is asked, as for an FS row. The same file bytes mapped by two sections are one row. A capa rule agrees with a row of the kind it states, read off capa's own namespaces and rule names (anti_analysis.RULE_NAMESPACE_KINDS): a debugger-detection rule with an RDTSC, an INT3, an INT 0x2d or a TEB/PEB read, a vm-detection rule with a hypervisor CPUID, SIDT, SGDT, SLDT or STR, capa's PEB access (a lib/ rule with no namespace) and access PEB ldr_data with a TEB/PEB read, and an obfuscation, packer, anti-disassembly, anti-forensic, anti-AV, anti-emulation or debugger-evasion rule with none (a stack string is not an SIDT); an anti-analysis rule whose namespace states no kind agrees with every row in its function. A TEB/PEB read with no such rule is counted: the 32-bit UCRT's exit path reads the PEB's NtGlobalFlag itself, and capa leaves the library functions it recognises out. An INT3 counts only alone, not as the byte before a function and not right after a call, jump or return (compilers put one after a call that never returns and pad with one where nothing falls through); a CPUID counts only where the code sets the hypervisor leaf in eax, or sets leaf 1 and tests ECX bit 31 before ECX is written again, all read in the file's bytes. An API call is counted and never stated: Ghidra lists every call site of a broad list, a language runtime's own included (the MSVC runtime calls IsDebuggerPresent on its failure path), while capa leaves the library functions it recognises out and the catalogue line already reads the imports. The rest are counted once per place. A scan that matched nothing says what it checks, never that the sample has no anti-analysis code. The provider hands the pack its scan — for Ghidra, switched on, over http, with the mirror the worker made for Ghidra — or the sentence saying why it cannot scan, which is one entry not run: <reason> whose pack line is no: <reason>, not a failure. A scan Ghidra did not complete is a failed entry with Ghidra's own words (no: the pass failed: …).

The function index is the pack's last entry, function_index (tools.artefact_index), for a PE. It lists every function the run knows and, for each, the artefacts the run's answers and the platform's decoder place in it. The functions come from the file's exception directory (a chained fragment counted for the function it belongs to), its exports, its entry point, the function starts of every answer that lists them (an answer of kind function_list or capability_rules that declares function_starts: capa's, as shipped, said as capa function starts), and every direct call target the decoder reaches in an executable section. Its rules come from every capability_rules answer, said under the matcher's display name and held in each row under capa when the shipped capa answered them, else under rules with rule_sources naming each rule entry's tool, and its call-site strings from every emulated or decoded strings answer that names its call sites; an input no answer fills is stated by the kind it lacks. A disassembler's function list is not read: the pack runs before any analyst opens one, and the entry says so as no: with that reason. Every function start is collected first, by a walk that adds each direct call target it reaches; then each function is read with all of them known. A function in the exception directory is decoded instruction after instruction across its stated range; any other is decoded from its start along every branch, up to a return, a jump it cannot follow, another function's start or its section's end. An unconditional jump to another function's start is that function's tail call, a callee, and is not read as part of the function the jump is in, so which function holds which code does not depend on the order the calls come in. A byte the decoder does not read ends that path, and the entry counts the functions where that happened.

Each row holds, with the entry id that states each cell:

• the imports the function calls, through the slot or the jump thunk the import table names, and the names the hash resolution places inside it;
• the strings it refers to: a plain string where an instruction takes an address in a data section (x64 RIP-relative; x86 an absolute address as an operand, a pushed or moved immediate, or the immediate a mov [abs32], imm32 stores, whose destination is a global and not a text) and the bytes there read as printable ASCII or UTF-16LE of at least six characters up to their terminator, read only where the address is the start of that text; a decoded string the blob decoder states it refers to, or one FLOSS decoded at a call site inside it (a stack or tight string: in the routine FLOSS names);
• the capa rules that matched at its start or inside it;
• its callers and callees, and how many of its direct callees hold artefacts of their own and how many those are, counted per callee: each callee's own distinct count is added, so the total is not a distinct count. An artefact two callees both hold, or the function and a callee both hold, is counted for each. A union across callees would cost a callee's artefacts once per caller, which one function holding many artefacts and called from many places makes quadratic; the sum costs one step per call;
• the functions it starts on a thread and the function that starts it, each with the API and the call site (starts_threads, started_as_thread_by): a call of a thread-starting API (an import or a slot the hash resolution fills; CreateThread, CreateRemoteThread, CreateRemoteThreadEx, _beginthreadex, _beginthread, SHCreateThread) whose start-routine argument holds a code address (x64: the register a lea or a register copy set in the straight-line code before the call, only a 64-bit copy carrying it; x86: the word pushed, read only while nothing but pushes and pop r32 moved the stack or wrote into it since the last call, so a junk push dropped by add esp, a pushad or a store to [esp+x] leaves the start absent). A thread started through CreateRemoteThread or CreateRemoteThreadEx is said to run in another process. Any other function start an instruction takes as a value is an address taken (takes_address_of, address_taken_by). Neither is a call: a started function keeps "called by 0", and the row line says the start beside it. The answer lists both relations whole under thread_starts and addresses_taken; a row stored before these were read has neither and reads as it did.

A place is inside a function when an instruction the decoder read there covers it, or else when the exception directory's range holds it. A place no function holds is counted under unplaced by its source and given to none. An artefact counts once per function as a distinct value: an import or a resolved name by its name, a string by its text, a rule by its name. A function with no artefact of its own is not a row. Each source the index could join and did not (an answer the pack holds none of, one that failed or was not run, one with no readable structure) is stated in the entry and its head as no: with the reason. Every walk is bounded by the file: in each of the two walks each instruction start is decoded at most once, whichever starts, overlapping ranges or branches lead to it (code two functions share is read for the first in the second walk's order: the exception directory's functions, then the others, by address); a section is found by bisection over the sections' sorted ranges; texts are disjoint runs read in one pass; nothing recurses. Ten times the functions, calls or sections take about ten times as long.

The pack shows the index as a compact table, after every other line and in the room they leave. The rest of the pack is rendered without it exactly as it would be, so no line gives way to it. The head says how many functions hold artefacts, where the functions come from, which sources are missing and why, and that each address is the image base plus the offset the other lines state, the form a disassembler takes. One row per function follows, ranked by the number of its own distinct artefacts, ties by address: - 0x401000: calls "CreateFileW" (ev_0030); refers to 5 decoded strings (ev_0015); capa: … (ev_0011); called by 1, calls 3 functions; 1 callee holds 2 artefacts of their own, counted per callee. Every name a row takes from the sample (an import, a resolved name, an export) is quoted and escaped as the pack writes every recovered string, so it reads as data. The same holds wherever a value the sample or its submitter wrote reaches a model as free text: the submitted name in the run-state block and in the judge's identity block, a function's name in the function map, a domain and a persistence target in the composer's prompt. One function, fenced in agents/tool_fence.py, is what a model sees of any tool answer on every surface: the recorder's stamp, the answer to a decompile of a function an earlier entry holds, the replay of an earlier chunk's result, and the judge's evidence excerpts. Every character str.splitlines breaks on is shown as a plain line feed. A JSON answer stays unfenced, with every raw break character inside it (the line and paragraph separators, the next-line character, the other control breaks) written as its \uXXXX escape, so it is still valid JSON, means the same and keeps each value on one line; the JSON a guardrail compacts or shortens is written the same way. Every other answer (a disassembler's listing, a decompile, a string or export list, any generic MCP text answer) is shown between a line <<tool output [ev_0007] 3f2a9c1b7d0e>> and a line <<end of tool output [ev_0007] 3f2a9c1b7d0e>>, both carrying the first twelve hexadecimal digits of the SHA-256 of what lies between them, so no line inside can be the closing line. Every < of a run of two or more inside the fence is shown with a backslash before it, wherever it stands, so no << appears inside a fence at all, and so is every character that reads as < wherever it stands (the ones NFKC folds to <, the angle quotes and angle brackets, the syllabic and arrowhead lookalikes); the escape is idempotent. The earlier chunks' list of calls shows each call's headline as one quoted value, and the guardrail summariser reads the text it shortens inside the same fence, its system text saying once what the fence is. The sentence about a prompt's tools says once what the fence is. The guardrails count what the view adds inside each answer's limit: a character cut keeps the longest prefix that fits with the fence lines and the escapes inside that prefix, never reserving the escapes of the part it drops, and the judge's evidence room keeps back the escapes a JSON excerpt cut to text then holds. The ledger keeps every answer byte for byte, and only what the prompt shows is quoted or fenced. A string a function refers to is counted, never shown. A row states what and where and names no behaviour. When not every row fits, each row in rank order that fits what is left is shown, a row that does not is counted and the next is tried, and a last line counts the rows left out, names the entry, which holds every row, and says that the analysis server's function_index tool serves the index whole or by address. With no room for even the head, the index is not shown and the run summary's pack record names it with "no pack room"; it is not counted in the "N more pack entries" line, whose growth would be room the other lines did not leave. The run-state block carries one line saying the index exists, which entry holds it, how many rows it has, and that the analysis server's function_index tool serves it whole or by address. A count is stated only from a readable answer: an entry whose output the evidence byte budget dropped, or with no readable rows, says no: and why instead.

A sample that resolves its imports by hash calls each through a pointer it fills itself, so its import cells alone name almost nothing. The index reads which slot each hashed name fills, in the straight-line run of code that holds the hashed value (bounded by the next transfer of control, never by an instruction count), two ways:

• A call and its store. A call is tied to a hashed name only when exactly one function-name hash is live in an argument at it, placed there in the same run: on x64 in rcx, rdx, r8 or r9 (or their 32-bit forms, a register copy carrying it), on x86 pushed or stored to [esp+x]. A hash held only in another register ties nothing, and two function-name hashes live at one call tie nothing; a module's hash beside them does not count. After a tied call, a store of the return register to a rip-relative or absolute slot, before the register is overwritten or another call is made, names that slot. The tie is read from what the code places, not from what the call does: a hash left live in an argument register across an unrelated call ties that call.
• A table of records. With no tied call stored in the run, the records are read from frame offsets alone. Each store to [rsp+x] or [rbp+x] (x86 esp, ebp) carries its offset, an [rsp+x] offset read against the stack pointer the run began with through the pushes and pops between. A record's extent is the table's stride, the equal spacing between consecutive hashed values stored to the frame, the last record included, and every address stored to the frame falls in the record its offset lies in, whatever order the stores were emitted in. An instruction that holds a hashed value is never also an address, and a call forgets every address a register held. A record's slot is its one address some code calls or jumps through; a record with none names nothing and lends nothing (a name resolved and never called). The table names nothing when a record holds two such addresses, when records name addresses at different places within them, when fewer than two hashed values give no stride, when their spacings differ, when a store to the frame of a pointer's width or more (a hashed value, an address, any other value that wide, a store whose width is not read, or a pop into the frame) lies outside every record, when the records do not share one layout of addresses, or when the stack or frame pointer moves between the stores by an amount the run cannot read (any other write of either, or an x86 call, whose callee may pop its arguments). A narrower store (a loop counter, a flag) is no record's and does not count, except where a record's called pointer would sit one stride before the first record or after the last: there a store of any width says the records may begin at the pointer, not at the hash, and the table names nothing; on x86 a 32-bit counter is a pointer's width, so a counter stored beside an x86 table makes it name nothing. Stores that carry no frame offset (pushes, absolute slots) make no records.

A slot two names fill, or filled by a hashed value that reads as two names, is ambiguous and names nothing. Every call or jump through a named slot, direct or through a register a straight-line load from the slot set, is then a cell of its row, "calls through slots the hash resolution fills", with the slot and the instruction that named it, sourced to the resolution's entry. The entry lists the named slots some code calls through (resolved_slots) and the ambiguous ones (ambiguous_slots), the functions the decoder stopped in (undecoded), the callees of the functions that are no row (other_callees, so the call graph is whole), and per function the calls that still name nothing (calls_unnamed): through a register no load names, through a base and displacement or an index, every indirect jump that goes through no named or import slot, and a call through a slot nothing names. The function claim check reads them to know where an absent call is no fact.

The analysis server serves the same index as the tool function_index (path, optional address, carved_path), built by the same code from the file alone. It joins pe_info, resolve_api_hashes and decode_string_blobs over that file, run in-process, and FLOSS's rows when FLOSS ran on the file in that server; each source it does not join is stated under absent with its reason. It never runs a rule matcher and says so under capability_rules, and it states its own reason for the disassemblers' lists: the analysis server has no disassembler of its own. With no address it answers the whole table in the pack's row form. An address is hexadecimal, with or without 0x (the pack prints hex, so a bare number is never decimal); a value at or above the image base is tried first as a virtual address, then as an offset. The answer is the row of the function that starts at the address or holds it, with its callers and callees and, where the code shows one, its thread starts and addresses taken, and address_read says which reading answered and whether the address is the start or inside; an address no function starts at or holds, or text that is not an address, is a no: sentence. It has no row limit: the MCP tool-output guardrail bounds the answer and records any cut. Ghidra's get_xrefs_to and radare2's xrefs_to take the same addresses.

Byte transforms are the model's to name and the analysis server's to run. A key, a user agent or a reply format kept in an encrypted or encoded blob stays hidden from a model that cannot run a cipher in its head. The analysis server's transform_bytes (tools.transforms) reads one range of the file, given as a file offset or as an address the file's own section table resolves, and applies the steps the model lists in order: xor with an optional per-byte increment, rc4, aes (ECB, CBC or CTR), base64 with the standard, the URL-safe or a 64-character custom alphabet, hex, lznt1, zlib, gzip, raw deflate, reverse and slice. A key, IV or nonce is written literally or named as another range of the same file, so a model points at a key it found rather than copying it. The answer names the range with its section and every step with its parameters, so the ledger entry is a call anyone can repeat, and then states facts about the output: its length, SHA-256, printable share and entropy over all of it, and, over the part shown, its hex head, its ASCII and UTF-16LE readings escaped as the pack writes a string, and the indicators the platform's indicator scan finds in it, each at the offset where the scan's own match stands, as many rows as the room leaves. The part shown is sized from what an answer carries: at most 17 characters per two shown bytes for the two readings as JSON writes them, after the rest of the answer (the input range, the steps and the output's own fields at their longest) is taken from the 6,000-character room one tool answer gets when the window is not measured, so the default part is at most 705 bytes and the whole answer stays within that room; a show_length past what the largest answer any model gets carries is cut to it and says so. It never says what the output is. An unknown operation, a wrong key or IV length, an input that is not whole blocks or padding that does not read is an error naming the step; nothing is retried with other parameters. Decompression is fed a piece at a time and asked for no more than the room left under the platform's fixed sample upload cap (100 MiB, a number here and not the operator's upload setting), concatenated gzip members included, so a bomb is cut at the cap and the answer says so; a cut decompression ends the chain, and the bytes all steps write together are held to the same cap, so a long step list costs at most that much work. Every other step writes at most what it reads, and each is linear in its buffer. No prompt asks for the tool; the server's capabilities answer and the tool's description state what it takes. The entry's evidence root is the start of its input range.

A UPX-packed PE is unpacked once, and the program is a file of its own. A UPX-packed sample shows every reader the packer's stub, so the pack's strings, imports, capa rules and FLOSS rows describe the stub, not the program. When pe_info's packer signatures name UPX, or a pack header with a true checksum byte stands where UPX writes one (sections renamed to hide the packer keep their header), the pack's next entry is unpack_upx (tools.upx, the code the analysis server's tool of the same name runs), after the function index so every earlier id keeps its value. It reads UPX's own pack header and records in Python, with nothing run and no upx program needed: NRV2B, NRV2D, NRV2E and LZMA, the call and jump filters 0x24 to 0x26, and the rebuilt import, relocation, export and resource tables. Both adler32 checksums are checked; a mismatch, or data that does not decode as UPX writes it, is a failed pass with no file written, which does not make the run degraded. A format, method or filter the reader does not cover is a no: entry saying which. The program is written into the job's carved tree for the sample, the directory the analysis server's carved_path reads, so the carved_path the entry states is one every file tool there takes. Decision: the pack is not run again on the unpacked program: its one line, in the room the other lines leave like every pass, states the method, filter, sizes and checksums and the program's carved_path, SHA-256, sections, imports and entry point (the carved_path alone in less room), and the models decide what to open next. The entry's evidence root is the start of the compressed data in the packed file; a call that reads the program by its carved_path is about that program, named by its digest and placed against its own section table.

A sandbox report is sections of items, each with an id a claim cites. Where a sandbox produced a report, the pack's last entry is sandbox_sections (analysis.sandbox_sections), after every other step so every earlier id keeps its value, save one: where the report records API calls, the step sandbox_api_capability follows it and asks the API catalogue about the APIs called, recorded under the kind called_api_catalogue so the import profile never reads it (DynamicBehavior.api_capabilities does), and its line is labelled sandbox-called api catalogue, apart from the import catalogue's api catalogue line; it is read in memory in time linear in the report, so neither the pack's time budget nor its evidence byte budget stops or blanks it. It reads the report the run holds into fixed sections: processes, API calls, file operations, registry operations, network rows (DNS, hosts, HTTP, TCP, UDP, domains, ICMP, TLS), signatures, dropped files, mutexes, executed commands, services, generic events, the per-process API counts, the platform channels, the screenshots, what the sandbox extracted (configurations and payloads, extracted, ids ext:<n>), the resolved API names, the intrusion detection alerts and the process dumps, each read from the neutral report's document by the part's name (one neutral report); the process tree gives a process its parent where the row states none, and no items of its own. An index recorded before the extracted section was named so (cape, ids cape:<n>) is read as that section. An item is one row of the report, with the report's own fields and the list it came from; nothing is summarised, ranked or labelled. A process's id is its pid as the report writes it (proc:84, proc:84.2 for a second process with that pid, proc:p3 for one with none), and every other item is its position in its section (net:3, reg:12, sig:5), the network rows counted in the order the sandbox_network view lists them so the two agree. The entry states each section's count, or a no: saying why the report does not carry it (the report lists it as unavailable from its sandbox, as a Triage report does for the registry and the API calls, or holds none of the lists it is read from), and the process ids, written as runs of consecutive pids with the repeats and the positions of processes with no pid, so the entry stays a few runs long however many processes the report holds. Each provider's reader declares the lists it can fill, beside the reader and held to its code by a test; a section none of whose lists the reader behind the run's report can fill says no: the <provider> report as normalised here carries no <section> rather than 0, since that reader writes the list empty for every report, while a reader that can fill a list and found nothing still says 0. A Triage report read from its overview alone (uploaded, answered by a REST sandbox, or fetched with every behavioural task report missing, as the reader records) fills the signatures and what Triage extracted and nothing else, and says so in its own no: (read from its overview alone); a report a reader that keeps its source's arrangement built without a source is read as laid out from the form. In a report the platform rendered from its normalised model, a pid or parent of 0 is the model's "not stated": such a process gets a positional id, and no process is linked to itself or to an unstated parent; its line states the count and the id form of each section in the room it has. Decision: the items are served by one read-only tool, sandbox_items, built in-process beside the other sandbox views over the report the job already holds, rather than on the analysis server: the report is in the worker, so a sidecar would have to be sent it, and no sandbox is asked anything. It takes a section and, combined, a pid, a substring of any text value, a signature by id or name and a list of ids, and answers the matching items whole with matched, through the answer guardrail and the one view of tool answers. The report is read into sections once for the job, on the first call; a pid and a signature name are looked up in indexes built once per section, an id is found by its position, a list of asked ids is read only up to the section's own size and the rest counted, and only the substring filter reads rows, once each. A pid filter on a section whose rows name no process answers a no: saying so. The dynamic analyst has the tool in its sandbox set. The network analyst has it alone wherever a sandbox produced a report, and the whole sandbox set where its definition asks for ToolRef(kind="sandbox"); no prompt text changed, and the sentence about tools that is generated from the tool list then names the job's sandbox report among the network analyst's sources. An item id is cited as an entry is, and read only where it is cited: in brackets or in a citing field (evidence_ref, evidence_refs), never out of a statement's own words, and only with a token boundary on both sides, so the tail of c2.example.net:443 is never one. A report check reads a cited item through its own row text (the row's fields and the process and parent it names, not the platform's id, kind or source), from the report in hand, exactly as it reads a cited entry's answer: a value stated under the citation is looked for in that row, and an item whose text cannot be read is no citation. An analyst's claim citing one the run's index holds is grounded, and one it does not hold is named in the question the claim is asked; a report section's bracketed item id the index does not hold is asked about once, like an id the ledger never issued; an execution step marked observed may cite items, a network item by its own row's attribution where the row states one and otherwise only where the sandbox attributed a flow to the sample's own tree, as for the network answers; and the evidence roots read a process item as that sandbox process, a TCP or UDP item as its flow and a DNS item as its query. Every check looks a cited id up in the index; no list of every item id is built.

Phrases written for an AI or an analyst reader are a finding. The pack's last step but the behaviour links, find_directed_text (analysis.directed_text, declared kind directed_text), looks for words a sample holds for whoever examines it rather than for the machine it runs on. There are six phrase families. Each one requires the AI or analyst context that defines it, and each match names its family:

The context requirement leaves out strings that are ordinary in benign software: "do not delete this file", "safe to delete", the browser's "report this file as safe", C#'s <Invoke>d__ state machines, contract ABI JSON ("type":"function"), OpenAPI "parameters", Windows Event XML <System>, "skip system messages" and "note to reviewers". A test holds each of these out.

Decision: a role marker is counted as a finding wherever it stands. Only a match inside a chat template structure of its own text, in the same source and the same reading, is said to be there (inside_template, "inside a chat template structure"). A structure is a Jinja loop over the messages, from its {% for … in messages %} to the first {% endfor %} after it, or a "chat_template": "…" string up to its closing quote. Each is measured by its own extent, never by a window, and a structure with no end holds nothing. A template word anywhere else in the sample marks nothing, and nothing is carried across sources or across the run. Every family's grammar is finite except a tool call's name, an identifier token, so the passage cannot carry prose. A tool call is grouped by its form, with <name> in the name's place, and its distinct names are counted and listed in the entry (distinct_names, names). The ledger's own size handling spills a large list, and the pack line shows only the count. A phrase or a name longer than the pack's line can show (PackInputs.pack_chars, the bound every agent is shown the pack at) is held as its normalised prefix of that length, with its full length and SHA-256, never whole. Apart from the bare previous/prior-instructions form, the override family needs its address: "ignore all prompts", "Override the prompt string (PS1)" and "Ignore the instructions above if you use a proxy" are held out by a test.

Text is folded before it is matched:

• Unicode tag characters are read as the ASCII they shadow.
• Compatibility forms are taken apart (fullwidth and styled letters, ligatures).
• Latin small capitals, and the Cyrillic, Greek and IPA letters drawn like Latin ones, are read as those letters.
• Curly quotes and apostrophes are read as straight ones.
• Combining marks and invisible format characters are dropped (zero-width characters, the byte-order mark, soft hyphens, bidi controls).
• Case is folded, and every whitespace character is read as a space.

A control character, an undecodable byte or a private-use character ends a passage, and a word's edge is read on ASCII letters and digits alone. Two further views are read: runs of single letters spaced by a space, _ or . (two or more separators between words), joined into words; and each run after a right-to-left override, read in its visual order. A phrase split across two strings by a NUL, or spaced with one separator between its words, is not read.

The sources:

• the sample's whole file, read as UTF-8, as UTF-16LE at both alignments (which covers UTF-16BE) and as UTF-32LE at all four;
• every unpacked program an earlier step wrote out (an answer of reader unpacked_image);
• the texts of the declared recovered-text kinds (CONSUMER_KINDS["triage_pack.directed_text_sources"]: emulated_strings and decoded_strings, so a plug-in decoder of those kinds is read too), with FLOSS's rows read whole where the step keeps them;
• an archive listing's member names;
• every string the sandbox report holds about the files it saw dropped.

Content the pass cannot read is listed under not_scanned and shown as not read:, never covered by a plain no:. That covers a container's compressed members or streams (a sample routed as a format the platform lists and does not extract), a packed image nobody unpacked, the dropped files' bytes, a decoder answer that failed, a source the time budget kept it from, and rows read only from a page. A decoder that was never run already has its own pack line, and is not named again here.

Each match is streamed into a group per family and normalised phrase, which holds the true count, the first and last place the phrase stands, its sources and how it was disguised. Rows are never held one by one, so a file of a million matches costs time and memory in proportion to its size. A 1.2 MB file of [inst] is counted in about a second and holds one group. The time is linear, at about 0.75 s/MB, and the pack's budget bounds it. Every phase runs under that budget: the scan, the letter-spaced and reversed views (each checks the clock at every word or run), and the building of the answer, whose listing of names checks it at every name. A step begun after the budget is spent is a not-run entry, and one the budget stops mid-way is cut cleanly. Its partial then says where it stood, and each source it did not reach is named. The letter-spaced view is streamed word by word, and a repeated regular-expression group an unbounded run meets is possessive, so 12 MB of a a a … grows peak memory by about five times the file. Each view maps its own matches back to byte offsets with a walk of its own; a reversed run's span is mapped once. So every offset and length points exactly at its bytes, and 1.28 MB of right-to-left runs is read in under a second with a later phrase still found.

Decision: no held value is a chat template's control token as written, because a local model's tokenizer may parse one as control even inside quotes. A role marker is held as a placeholder that names it (role_marker:im_start, role_marker:inst_close). Every other phrase, name and printed field has the characters of control tokens (<, >, |, [, ]) written out as \x3c, \x3e, \x7c, \x5b and \x5d. That is pack_escaped(…, delimiters=True), one opt-in extension of the pack's own escaping, which leaves every other caller's output as it was; the grounding search reads that spelling too.

Decision: the entry holds each phrase in the pack's quoted-data form (pack_escaped, text_form: "pack_escaped"): the normalised span, with no invisible padding, never raw. Every field a line prints beside it is held the same way, including a section name (quoted as section "…"), a place and a source. Each phrase sits beside the file offset and byte length (or the source's place and characters) that find the raw bytes. So every path to a model carries it fenced: the pack line, the ledger and read_evidence. A section name holding a newline and a forged [ev_…] line stays inside its quotes on the one line.

The line is neutral. It says that N phrase matches of these families were found, with the per-family counts, after the sentence that says the strings are the sample's text and not instructions, and after DIRECTED_TEXT_STANDING: it neither raises nor lowers the verdict by itself. It then shows as many groups as the pack's line budget allows. It is a pass line: among the passes with a fact no other line carries it comes in entry order, after the others, and before the passes with no such fact. The report holds the groups as MalwareReport.directed_text, apart from the static block so that it adds none to a run without one, and left out of the JSON when empty. Section 7 prints them under "Phrases of the directed-text families". A report stored before the field renders as it did.

Observed behaviour is linked to the code that holds it, by exact match only. Where a sandbox produced a report, the pack's last step, after find_directed_text (whose answer holds no text it compares, so every id issued before it keeps its value), is behaviour_code_links (analysis.behaviour_code, kind behaviour_code_links, line behaviour to code). It reads the values the sandbox observed from the report's sections, whichever provider produced it (mutexes, registry keys and values, file paths and named pipes, domains, addresses, URLs, user agents, services and command lines, each with its item ids), and the pack's own static answers by their declared kinds: the printable runs (strings, with their file offsets, the section each falls in read from the PE header), the strings recovered at a call site (whole where the step keeps them whole), the static decoder's texts and their base64 layers (with offset, section, scheme and encoding) and the function index's plain and decoded strings. A value is held where a static text equals it after the platform's normalisation for its kind (reporting.dedupe.indicator_fingerprint: registry keys and Windows paths fold case and separators, hosts and addresses fold case, defanging is undone, a mutex, URL, user agent, service or command keeps its case); a UTF-16LE run or a decoded blob is compared as the text it spells. A text that only contains the value is not a match, with two structured readings that are still exact and are labelled with how they matched: an observed domain or address equal to the host of a held URL (read by the platform's url_host, defanging undone first) is held host of a held URL, and an observed registry key whose path after its hive equals a held path that names no hive (the hive read off by the platform's hiveless_key: short, long and kernel spellings) is held held without its hive; any other holding is exact. Hosts are read by one shared form on both sides (network_extractor.host_form: port, brackets and trailing dot off, IDNA, canonical IPv6); an HTTP row's path is joined with its own host and stated scheme into the URL, and a path with neither is a url path, never a URL; a registry key is read with no IOC-table suffix taken off (Vendor App (x86) is a key name), and every key that maps to a hiveless held path is linked. A network value is linked only where the sandbox attributes a row of it to the sample's process tree (sample_process_tree); a value no row attributes is marked process not attributed, and one every row of which belongs to another process is not linked and is counted. Items of a section with no value under the fields read are counted. The step runs under the pack's time budget, like the other late steps, and stops with a partial answer. The function is the one the holding's own answer names (a blob's references, a recovered string's routine), else the one the function index places that text in, said as same text elsewhere in function X since the index places the text, not this copy of it; a section is the innermost raw range holding the offset, both named where two of equal size hold it; without a function index the answer, the line and the report say so. A value held nowhere is listed as observed only, after the held ones; a static text no sandbox observed is not listed. Where an answer holds a page of its texts (the strings head, a page of recovered strings), the answer says how many of how many were compared, decodings no code refers to are said not compared, and an observed value held nowhere then reads observed; static side partly read, as it does where a static answer could not be read or the time ran out. The join is hash lookups over each input once, so it is linear. Decision: the pack line takes the pack's own room like every other line (as many values as fit, then "the rest are in this entry's full output"), every value quoted by the pack's escaping; the ledger entry holds every link, and the report's evidence appendix prints them as the table "Observed behaviour linked to code", each value and place written as a code span.

Ghidra's emulation is not run by the pack: Ghidra's emulate_function ignores its step limit and cannot be stopped, and one emulation took 130 to 560 ms in a stored run. It stays a tool the reverser may call.

When the pack does not fit its room, the passes' lines take only the room the other lines leave. Decision: a pass fact never shortens a decoded string or any other line the pack printed before the passes existed. A pass with a fact no other line carries — a constant set no capa rule agrees with, an exact instruction or TEB read at a function no capa anti-analysis rule matched — is offered that room first. A line that cannot show one item is left out, and every pass entry left out is counted in the "N more pack entries not shown" line, which comes after the pass lines. That line may take only room the other lines leave free, or room from capa's addresses; never a decoded string or any other fact line. Decision: when neither kind of room exists, the pack stays exactly as the other lines are, and the pass entries it lacks are recorded in the run summary's pack record instead (run_summary.triage.pack_left_out: their ids and tools, with the reason "no pack room"), read at the same bound every agent is shown the pack at. So a pass is never skipped unsaid, and no fact an earlier line states gives way to a pass. On the stored benchmark runs no pass fact is new, so the pack is as dev renders it except for capa's addresses where the trailer needed room.

The pack states facts and draws no conclusion, and it never fails a job: a tool that raises or answers with an error is an entry with ok=False and a degradation reason triage.<tool>_failed, the next tool runs, and a reputation lookup that has no enabled server is an entry saying so rather than a silence. Its facts — has_signature, reputation_malicious, rule_hits and hits["<key>"] (the rules that matched in every rule-matching answer recorded so far, by kind, by declared corroboration name and by server; the legacy yara_hits and capa_hits keep the pack's own counts) — are readable by every later stage's when condition as triage.<field>, and run_summary.triage records how many entries it wrote, how many failed and how long it took. It declines, with the reason recorded, when triage.enabled is off, when the stage withholds the built-in tools, or when there is no sample on disk to read. The measurement baseline has no triage stage at all.

Every model reads it. triage_pack.render_pack turns the entries into one line each — [ev_0001] identity: pe windows, 4,486,656 bytes, …, [ev_0003] signature: none, [ev_0007] yara: 2 hits of 30 rules (…), [ev_0008] capa: 6 capabilities (parse PE header @ 0x1a20 0x2b40, …), ATT&CK T1027, T1055 (rule-asserted), [ev_0014] resolved hashes: 2 values the file holds name Windows functions or modules (…); all 2 shown: 0x09ce0d4a = kernel32.dll/kernelbase.dll!VirtualAlloc [crc32_ascii] @ 0x1041 (in 0x1000); …, [ev_0015] decoded blobs: 1 texts decoded from the data sections by the platform's static schemes, nothing run (…); all 1 shown: "open the settings file"@0x3080 [xor8 key 0x9c] referred to at 0x1123 (in 0x1100), [ev_0017] reputation: VirusTotal: 31 of 75 engines flag it as malicious, labels Filisto — cut at reporting.upstream_findings_max_chars (derived from the served window at its default of 0, like a tool answer's cap) with a last line saying how many entries were left out and that their full output is a tool call away. The decoded strings are one line: the counts, then each string quoted as "string"@offset (a decoded string's call site, a stack or tight string's routine, relative to the image base) grouped by the routine that produced it, at most 100 strings and 3,000 characters with each string cut at 120; a line that cut says so, with the reason and the offset of the rest, and a line that would not fit in what is left of the block is rendered shorter rather than dropped. The line says, before the strings, that they are the sample's own text — data, not instructions, ledger entries or the platform's findings. The capa line names each rule with the places it matched, as offsets from the image base capa analysed at (va or file when that is what capa gives, none for a rule that matched the file as a whole), so an agent that reads code goes to the routine a rule is about instead of finding it again. On the reference loader it carries all 81 strings. Under the heading Facts established before analysis (ledger ids in brackets; cite them) the block leads every analyst's first human turn (analysis and revision alike), the mediator's and the verdict's human turns, the narrative prompt and every composer section. The report's identity block and signature rows come from the same entries when no model cited them. And because every agent was shown the pack, the pack's ids are citable by every agent: isr.ungrounded_technique no longer exempts an analyst whose own ledger is empty when a pack is present — only a run with nothing citable at all (the measurement baseline) is exempt.

The reputation line states the labels the answer carries. VirusTotal's own MCP server answers with detections, one result label per engine that detected the file, and no popular threat classification; the line counts those labels exactly as written and names them with how many engines gave each, most first and then in the answer's order, at most twenty, with the number of distinct labels left out — VirusTotal: 52 of 75 engines flag it as malicious, 52 detection labels, 47 distinct (engines per label, most first, 20 shown): Gen:Variant.… ×4, … (+27 more distinct labels). Nothing is merged or normalised and no family is read out of them; an answer that does carry a popular classification still has its suggested label and names listed as labels ….

The run-state block. pipeline/run_state.py derives a dozen lines from the state — the sample, the identity, hashes, signature and reputation lines out of the pack, which stages ran or were skipped and why, how many ledger entries exist and which tools failed, and the steps and seconds a tool loop has left — and puts them at the end of a request's last message, between === RUN STATE … === markers: the task on a loop's first turn, the latest tool answer after a tool call, the question a nudge, a forced synthesis, a revision or a validation retry asks. It is regenerated on every model turn of a tool loop (the executor's prompt hook writes the current budget line) and on every turn after it: the node briefs the agent with the state it rendered the block from, and each turn renders it again with the entries the agent filed since appended (base_agent.current_run_state), so the ledger line and the failed tools are those of that turn, and a retry is never told the ledger ends before the entries its answer cites. It comes off a message again, leaving its bytes exactly as they were, once that message is no longer last, so a prompt carries exactly one block. It goes at the end because it changes every turn: anywhere earlier, the changed line would change the front of the request, which voids a hosted provider's prefix cache (measured on DeepSeek: 0 cached tokens of 3,884 with only that line changed, 3,712 with it unchanged) and makes a local server read the whole conversation again. At the end, each turn's request is the previous one without its block, plus the new turns and the new block, and the cache holds up to the block. It rides on a message rather than as a turn of its own so that no request has two user turns in a row, which strict chat templates refuse, and no turn that says only the run's state, which a model can take for the question. For the same reason a question asked right after a user turn — a retry that leaves a cut answer out, a salvage whose trim kept only the task — ends that turn after a blank line (pipeline.turns.with_question) instead of following it. It never rides on a model's own turn. The forced-synthesis trim keeps the system turn and the first human turn, so the pack is never what gets cut. It is read-only to the model: nothing a model says is written into it. The judge's, the narrative's and the composer's blocks do not change within their calls and lead their task turn, as before.

Agents exchange structured AgentISR objects — claims with an evidence_ref and a confidence — rather than raw text. Objects are built and cached in one composition root (src/maljan/core/container.py), and agents are discovered through the @register_agent decorator in src/maljan/agents/registry.py.

The organising rule is that the agent decides and the code says what is wrong with the decision. No component rewrites a claim, a technique id, a confidence, a severity, a category or a family behind the producer's back; a finding is put back to the producer as feedback and it gets one turn to fix it. What it will not fix stays on the record. tests/unit/test_no_silent_overrides.py enforces this by scanning the source for the writes it forbids.

Validation loopsCopy Anchor Link

src/maljan/pipeline/validation.py is where a wrong answer is dealt with. A Violation carries a code, a message written for the producer to read, and the path it applies to. retry_with_feedback appends the model's own answer plus "Your previous answer had these problems: … Fix them and answer again in the same format", re-runs once, and returns whatever is still wrong rather than raising it.

Two producers use it:

• Analysts (agents/base_agent.py) — validate_isr reports a technique id the ATT&CK catalogue does not have (with up to three suggestions from tools.knowledge.resolve_technique), a confidence outside [0, 1], and a claim citing no evidence. An id that survives the retry keeps the analyst's spelling and is flagged technique_id_valid=False; the report, the STIX minting step and the FP linter read the flag. The first answer goes back into the retry's conversation as the model wrote it (AgentISR.answer_text: its CLAIM blocks and its findings block, not a summary of the parsed claims — shown the summary, a model answered in the summary's shape and the parser read no claim), unless it was cut at the output cap, which is described rather than repeated. The analyst's closing line (ANALYST_FEEDBACK_CLOSING) names the block format the parser reads in place of "the same format"; when the retry is merged by claim number it asks for the claims changed alone (ANALYST_FEEDBACK_CLOSING_BY_NUMBER, below). The retry's text is logged at debug, and its claim count beside the first answer's, with which one was kept, goes on the loop's budget record (validation_retry). A retry's findings block travels on the retry's own ISR: findings and artifacts follow the answer that is kept, and a discarded retry takes its findings with it. Tool-call markup is left out of the replay. With the consistency gate on, the answer is replayed whole and the question names the claims the gate set aside (gate_removed_note). A claim is stored whole, however long: a claim stored at 300 characters was checked, retried and published as the cut text.

• The judge (agents/judge_agent.py) — validate_verdict_bundle reports an indicator whose pattern names a value no tool in the run saw, an attack-pattern with an unresolvable id, a severity outside the enum, and a family named with no evidence ids. An ungrounded indicator that survives the retry is dropped, because a STIX consumer has no way to read a caveat — and recorded, because the false positive is a fact about the run. verdict.unstated asks for the verdict when the bundle states none, and verdict.assessment_conflict asks which of two answers was meant when the stated verdict and the rest of the assessment disagree — see The verdict is what the judge states below. Two symmetric rules ask what a verdict over zero analyst claims rests on: verdict.unsupported_benign asks for the entry that establishes Benign (a signature is the usual one) and verdict.unsupported_malware for the entries that establish Malware (a reputation entry, a rule hit); either way the alternative offered is Suspicious with an inconclusive rationale, the judge is asked once, and the second answer is kept as given. Both rules run over the bundle that is actually reported, on every way the round can end — a bundle, a malformed answer the retry fixed, prose the model stood by twice, JSON that is not a bundle, and no answer at all. Where the loop ran them they were fed back once; on the endings that produce a verdict out of text nothing is asked again and what they find is recorded in run_summary.validation beside the verdict it describes, once each.

• The report's prose (reporting/narrative_agent.py, reporting/composer.py) — the shape of the answer, a capability the run does not establish (narrative.ungrounded_capability), and a bracketed citation that is not an evidence id the run issued (report.citation_not_evidence): a prompt block's heading such as [BINARY FACTS], a source's name, or an ev_ id the ledger never issued. The citable ids are the run's ledger ids, never ids read out of prompt text — a decoded string can carry any [ev_NNNN] — and the question's sentence names them. Only prose is read — a section's body or text, the narrative's summary and key findings — never a record field such as a C2 channel's packet layout or a flag, and never a code span. An ATT&CK or MBC id or an IPv6 literal in brackets is an identifier, not a citation; a markdown link and a bracket that is part of a token ([len][payload], [Content_Types].xml, [System.Convert]::) are neither. A numbered reference such as [1] in prose is asked about. A citation or an over-claim that survives the retry is printed as written and recorded unresolved; only a broken shape costs the section. A sentence the capability check flagged and the retry left standing is also recorded on the report (flagged_statements), and the Markdown and HTML reports print a mark after each place it stands, in prose and in table cells ([not established by this run: …]); its words are unchanged. A finding from the structured-output path, where there is no turn to ask on, is marked with "; not asked". A statement of absence is no claim: a negation governs the term it precedes in its own clause, up to a relative clause or a new statement ("no signs of packing in this binary, which exfiltrates the files" still claims exfiltration), where "no evidence that …" and "such as" end nothing; a noun negation ("no evidence of") also reaches through a ", such as …" list it names to the end of its clause; "to prevent|avoid|stop| block X" negates X only when X is the verb's object; "rather than", "instead of" and "prevents confirmation of" are cues too. The absence question's own readings count as well, one reading for both: "is absent", "is missing from", "is not present", "was not observed", "is not supported" and their like (a category noun such as "mechanisms" may stand between) with the term opening its clause or ending the subject's noun phrase ("the specific APIs required for persistence are absent"); an item of a negated noun list; and the term ending the object of a negated verb ("does not import the registry APIs required for persistence"). No word inside a value is read: a code span, a quoted string, a path or registry key, a record's value or endpoints, and the words of that value its other fields restate ("Configuration path for SSH authentication credentials" beside /SSH/Auth/Credentials); nor a section's heading; a slash-joined list of words is not a path, only a run opened by a separator, a drive, a hive or a share, or with a dotted or capitalised component. A sentence whose assertion is only that a rule matched — the matcher, a rule or a signature matched, flagged, hit or reported, and nothing concluded about the sample ("YARA rule X matched", "capa reports the rule Y") — is not a claim that the sample does what the rule names; "Based on YARA results, the sample steals credentials" is. A negated verb of need ("does not require administrator rights for persistence") negates the need, not its purpose.

  What grounds a capability word is what the run found: a published technique that is not a rule match only, an evidence section's key, and a word said — not denied, by the same negation reader — in an analyst's claim, a finding's title or a tool's section, one evidence item a line so a cue never reaches the next item. A technique an analyst kept after the absence question below is published and grounds like any other; the words of a claim that deny a behaviour ground nothing, by the negation reader. Three things ground nothing: a matrix row the run did not publish, a reference table (tool:api_capability, which says what a catalogue lists an import under), the words of the sample's own strings (tool:strings, tool:iocs_from_file, tool:floss), and the rule names of a rule matcher (tool:capa, tool:yara_scan) — a rule's name is its author's word for a pattern, not a finding that the sample does it — which count by their section's key. A benign control's "performs keylogging" and "attempts to evade detection and debuggers" had been grounded by capa's "log keystrokes via polling" and "check for time delay via GetTickCount". A benign control report's "likely uses these registry APIs to establish persistence" had been grounded by an id published from "does not contain any obvious persistence mechanisms" and by the catalogue row "CreateMutexA | persistence"; its "credential harvesting" by the sample's settings path /SSH/Auth/Credentials. The terms include anti-analysis (with evading detection or analysis, and packing) and anti-forensics, and a capability question names two of its term's technique ids as examples.

  Two more questions are asked where they can be decided. A value cited to the wrong entry (report.citation_wrong_entry): a value a sentence states verbatim — in quotes or backticks, unquoted where its shape makes it an indicator (validation.literal_values: a whole digest, a URL, a backslash path or registry key, a mailbox, a host under a real top-level domain, or a file name with a file's extension other than an executable every Windows host carries; never technical vocabulary such as AES-256, x86-64 or an API constant), or a record's value or endpoints — is looked for in the text of each entry the sentence (or its record) cites, as the run holds it (validation.EntryTexts: the corpus copy, else the stored output). A DLL or API name is compared without regard to case, and a bare library name is held by an entry that writes it with its .dll (validation.library_spellings): WinINet is held by an entry listing wininet.dll. A value written as a field name and its value (seed 0x5a17c0de, first_key=0x2b) is also held by an entry that pairs that name with that whole value, as a JSON member or as name=value or name: value (validation.field_value_spellings), each part whole on its own side (validation.field_pair_in): the two parts apart never count, so a value another field holds, a prefix (time: 12:30:00 does not hold time 12), a name that ends another (cfg/key) and the same digits in another radix are not held. Only the table and citation checks read pairs; a sample-string read never takes a tool's own field and value for a string. Held by a cited entry, the citation stands; held only by another entry, the model is asked once with that entry named; held by none, nothing is said, because a paraphrase or a composed value cannot be judged. "Held" means held as a whole value in one of its spellings, never as a slice of a longer run; a value that is only a number raises no question (an answer may write it another way, and every reputation report holds short numbers), and a cited entry whose text is known to be partial is never said to lack one. The id is never rewritten. An entry said to hold nothing, or one line (report.entry_contents_misstated): a sentence saying a cited entry holds nothing, is empty, or holds only a header, a line or a row is checked against that entry — the one its subject names (the capture entry names the capture summary's, and so does the entry's id), never merely the one it cites. The statement is false when the entry's text holds a value (or more than one), counted through its JSON with a zero, an empty string and an empty list holding nothing; the model is asked once, a partial entry is never judged, and the sentence is never rewritten. A sentence saying the ledger lacks what it holds (report.absence_contradicts_ledger, composer and narrative): a routine said to be "not read" (or decompiled) whose decompile answered; an address, an entry id or a value said to be "not in the ledger" that an answered entry holds (for an address, an entry given it whose answer names another address, or a decompile of it); a value said to be "not confirmed by", "not shown in" or "not listed in" the entry the sentence cites, which that entry holds. Only the head of the statement's subject is judged: the identifier the subject opens with, after a determiner and a kind noun ("routine 0x1400", "the routine at 0x1400"), with identifiers coordinated to it; a closing bracketed list of identifiers after a head noun no modifier follows ("the import names … (A, B)"); for a relative clause, the identifier that ends the words before it; a singular pronoun alone ("it", "this"), or "its" before a relation noun for a statement about the ledger ("its callers"), is the one address the sentence before it names ("they", "these" and "their" may stand for several things and are not judged). A head followed by a bracketed modifier ("Routine X (the unpacked copy)") and an identifier inside a modifier ("the caller of X", "X, called by Y", "the return value of X", "the call site of X"), a sentence scoped to the text around it ("in this section"), and a clause that negates before its statement are not judged; an offset and its virtual address are one routine, and a statement whose subject cannot be read is not judged. The model is asked once with the entry named; the sentence is never rewritten. A technique written with another technique's name (report.technique_name): an id followed by a name in brackets whose name the vendored ATT&CK table does not give that id — its own name, or its parent's name before a sub-technique's, stands — is asked about with the catalogue's name and the id the written name belongs to. Every search that compares a value a model wrote with a tool's text asks each spelling the value takes there (utils.written_forms: plain, as a JSON string carries it, as the triage pack quotes it), so a quote or a backslash in a decoded string no longer hides it.

  What a composer section is shown includes two facts the platform can state: the techniques the report publishes (its ATT&CK table), and, after each analyst claim, the entries whose text holds the values the claim quotes. A section shown only a claim once called it unsupported while a strings entry held the claimed value word for word and the report published the technique. A section's analyst claims and tool answers share what the reporter model's context window leaves after the section's output budget and the rest of its prompt, evenly; no count cuts a section's claims. A full window shows a sentence in place of a claim or an answer, and the run summary's budget line says how they are sized. A section's facts (its techniques, network values, process lines and command lines, persistence, capability profile, carved and dropped files) enter whole, with no count cutting them, and are measured as the rest of the prompt; a section whose facts alone exceed what the window leaves records a degradation naming it. A text the platform shortens before showing it — a claim's stored evidence, a tool answer cut to its share, a procedure quote in the ATT&CK table, a claim in the live transcript — ends in … (utils.marked_cut), so a cut is never read, or copied, as a finished sentence.

  Every claim in force reaches the report. Each composer section's claims and the narrative round's prompt show every claim under its label, the analyst and the claim's number in its answer in force (static claim 15); the narrative round is handed every claim whole. After the body is composed a deterministic check (reporting.claim_coverage) reads it claim by claim. A claim the body cites by its label is not listed. Any other claim is listed when the body does not name one or more of its code locations (a decompiler's own name of four hex digits or more, after a prefix an enabled server declares as auto_name_prefixes or data_label_prefixes or one the platform ships: FUN_, fcn., sub_, func., loc., LAB_, SUB_, sub., DAT_, in either case) or API-style names (six characters or more, lower case and two or more capitals), whatever share it does name; the row lists the names the body lacks. A bare 0x value in a claim is not asked for, being as often a flag or a size as a place; in the body every 0x value is read as a place. Two places are one when equal, or when the longer is the shorter plus an image base (a 64 KiB-aligned difference of 1 MiB or more, so FUN_1400068e8 and 0x68e8 are one place); no other shared ending counts. A claim that names none of these is listed when the body carries half or fewer of its words of five letters or more. The body is what the report models wrote (summary, key findings, recommendations, background, technical analysis, C2 channels); the ATT&CK table quotes claims and is not part of it. Every listed claim is stored (MalwareReport.claims_not_discussed), counted (run_summary.claims_not_discussed) and printed under §13.1 "Claims whose code locations or API names the body does not name", with the names it lacks. Nothing is decided about a listed claim. A claim is the block the analyst wrote: a block whose TECHNIQUE line listed several ids is read as one claim per id, and the coverage check, the report models' list of claims in force, §13.1, the console's list of the same claims and the run summary's per-analyst claim count read it as one claim again, numbered once, with its techniques together in its row (ClaimNotDiscussed.technique_ids), each id with the note the ATT&CK table prints beside it: "technique id not in the ATT&CK catalog" for an id the catalogue lacks, and the kept-absence note for an absence claim kept when asked. An analyst's mean confidence weighs each block once, by the confidence all its copies share; the ISR summary the mediator and the judge read (AgentISR.to_text_summary) numbers claims by block, one line per block with its ids together, and the debate facts resolve a mediation line's "claim N" to block N (debate_facts._claims_of). The line after an empty revision's summary names the blocks its validation retry added (nodes.retry_additions_text), and a claim a retry added is never one block with a claim it did not add (added_by_retry_in_round is compared). The ATT&CK table, the matrix and ttp_mappings keep one row per technique.

  A function name the run resolved at runtime from a stored value is not an import. api_capability takes such names as resolved_names and marks them in its answer (obtained, resolved_at_runtime_from_hashes); the report's projection also reads the ledger's resolve_api_hashes answers, and a name one resolved that the import table lacks is counted apart (static.api_capabilities_resolved). A knowledge-table rule row names which of its matched names were resolved (resolved_apis), and the ATT&CK table, the static properties, the narrative prompt and the string-resolution bundle say "resolved at runtime from hashes" for them; a rule that matched only such names says it matched no import.

• A judge that did not answer with a bundle — the pipeline builds one from whatever text there was, and that bundle states its verdict in x_maljan_fallback_verdict rather than implying it through its objects. The verdict is extracted when it was read out of the judge's own text and pipeline when there was nothing to read, which is what a timeout leaves; a verdict that is not Malware carries no malware object, and the record of the degraded path travels on a note instead. pipeline.outcome .decide_from_bundle reads the statement and counts nothing. Before this the fallback bundle carried a malware object unconditionally, so the bundle's shape decided the verdict: a signed sample with a clean reputation entry, no analyst claim and no technique was reported as Malware because the judge timed out, while the extraction in the same run had read "Suspicious" out of the text. Such a verdict also carries no confidence — see verdict_fallback below.

The verdict is what the judge statesCopy Anchor Link

x_maljan_assessment.verdict is the judge's answer to the question the report leads with, in the vocabulary schemas/judgement.VERDICT_VALUES fixes: Malware, Suspicious or Benign. pipeline.outcome.decide_from_bundle reads it, after x_maljan_fallback_verdict and before anything else. The object set of a bundle illustrates the decision; it does not make it.

It used to. A signed, 0/74-clean PuTTY was published as Malware, confidence 1.0 because the bundle carried a malware object, while the judge's own severity was Informational, its category legitimate-utility and its rationale read "the 'malware' classification is used here strictly as a container for the object type in STIX, but the assessment confirms it is benign". The contradiction was detected, fed back once, survived — and the shape-derived verdict was published over the judge's own words.

The judge is shown the whole answer as a skeleton, with x_maljan_assessment beside objects and the three accepted words written where the verdict is asked for. It used to be asked for in a bullet among ten others, with the STIX bundle framing around it and "Return ONLY a valid JSON STIX 2.1 Bundle" last — and a bundle is {type, id, objects}, so a model that had read the spec left the extension out. The default model omitted the block entirely on its first attempt in three runs of three and supplied it on the retry; a smaller model wrote it inside objects[0] in three of three, which costs no retry because a misplaced block is moved. Prompt text only: nothing in this pipeline writes a verdict.

The STIX rules around it ask the judge for what the judge decides and agree with the checks that read its answer. An attack-pattern names its technique in external_references, and a behaviour with no id goes in severity.rationale — the prompt used to say "Omit technique ID if unsure", which is exactly what attck.missing_id then asks about, and that code took the judge's one retry in ten of the twenty-four stored runs that retried. Ids are labels (see The published ids are the platform's), created, modified, spec_version and valid_from are left out because they are stamped after the answer — ids and stamps were about two fifths of what the judge wrote for its objects, output a small reply budget runs out on — and a relationship credits sources by the names the evidence summary gives them, which is what stix.credit_without_claim reads.

The statement is read three ways, not two, and pipeline.outcome.StatedVerdict carries the difference: the judge wrote a word this pipeline knows, it wrote a word this pipeline does not, or it wrote nothing. Only the third is a question the object set may answer.

normalise_verdict is what "knows" means, and it is the one reading in the tree, shared with the report builder that renders a decision. The whole value has to be one of the three words once whitespace, case and the decoration a model wraps a word in are taken off — Malware., **Benign**, "Suspicious". Nothing else is interpreted. A question mark is not decoration and is not stripped: Malware? is doubt, and reading doubt as the confident word is the fault this rule exists to close.

It was a prefix match, which is the right rule for the builder — whose input the pipeline has already reduced to one of three words — and a dangerous one for free model text, because a prefix cannot see what follows the stem: malware-free, Malware (false positive) and malwarebytes detected nothing all read as Malware, and Benignware is unlikely; malware as Benign. The published verdict was the inverse of what the judge wrote, with no code, no feedback turn and the judge's own confidence printed beside it.

The field's annotation is Any for the same reason its vocabulary is not a Literal: a judge answering ["Malware"] or 1 to a field with three allowed values used to fail Bundle.model_validate and cost the run every object it had. A value that is not text is stated and unrecognised like any other, shown back as its own compact JSON.

Four rules follow from the statement:

• Unstated is recorded, not guessed at. A bundle whose field is absent is still read by its objects, for stored runs and for a model that omitted it, and verdict.unstated is fed back once and recorded when it survives. A bundle this pipeline built out of text states its own verdict and is not asked for a second one.
• Unrecognised is asked about, and the objects stay out of it. The run publishes INCONCLUSIVE_VERDICT, the judge's own answer is quoted in a degradation reason the header prints directly under the verdict, no confidence is published, and verdict.unrecognised asks once for one of the three words, quoting what the judge wrote. The severity and category conflict rows are silent for that turn, and correctly: there is no stated verdict for them to disagree with, and they return the moment the retry states one.
• The conflict check compares the statement with the rest. The severity rating (Malware over Informational, Benign over High or Critical), the category (a Malware verdict whose category says the sample is legitimate), and the presence of a malware object under a Benign verdict — one verdict.assessment_conflict row per disagreeing fact, each with its own path. It is asked once. When it survives, the stated verdict is published, the conflict is in run_summary.validation.unresolved, and the console's header draws both facts on one line.
• The export declines what contradicts the published verdict. A malware object under a Benign verdict is not written into the exported bundle — neither the judge's nor one the renderer would mint — and the decline is recorded as stix.malware_object_under_benign. The relationships that would dangle go through the integrity pass that already prunes them. Nothing is rewritten: the judge's own bundle is stored with the object in it. The indicator carrying the sample's own hash says what the published verdict says, through schemas/judgement.indicator_type_for and STIX 2.1's indicator-type-ov: Malware is malicious-activity, Suspicious anomalous-activity, Benign benign, and a verdict that mapping does not name is unknown. It used to claim malicious-activity whatever the run concluded, which told every blocklist the opposite of the verdict — a stronger contradiction than the malware object the same export declines, because a consumer blocks on the indicator and reads the objects afterwards. An indicator for anything else — a domain, an address, a URL the analysts observed — keeps the type it already had (malicious-activity when the row is marked suspicious, anomalous-activity otherwise, and anomalous-activity for a file:name out of the string scan); a Benign run can carry them, because a benign sample still talks to hosts, and they are exported as they are. A judge-written indicator keeps the type the judge gave it, and on one shape the judge is asked about it first: a Benign verdict beside an indicator the judge typed malicious-activity publishes a value as malicious activity under a verdict that says the opposite — on a recorded run it was the analysed vendor's own project domain. stix.indicator_type_contradicts_verdict puts that to the judge once, through the same single retry the other verdict checks share, naming the indicator, the verdict's own word and the vocabulary's benign / anomalous-activity / unknown, and saying the type may be kept. Whatever comes back is published: nothing retypes an indicator and nothing drops one. A type the judge keeps stays in run_summary.validation.unresolved and is printed with the other unresolved findings, so a consumer reading the bundle beside the report sees the contradiction was raised and kept. The mirror — a Malware verdict beside an indicator typed benign — is not a contradiction and is not asked about: an indicator is a claim about the value it names, and a malicious sample may touch something harmless. A summary note then has no malware object to be about, so it refers to the indicator carrying the sample's own hash, which the cap keeps in a band of its own; a bundle holding nothing the note could truthfully refer to emits no note, and the summary stays in the report where a reader reads it. STIX requires a note's and a report's object_refs and forbids an empty one, and a bundle that breaks that is rejected whole rather than in part.

The published confidence is x_maljan_assessment.confidence, the judge's own number for the verdict the judge itself stated, and nothing else. It is published only with such a verdict: on the two other paths the verdict is not the judge's, and the number is about something else. Replaying the PuTTY run's recorded answer shows what that is worth — it has no verdict field, so it publishes Malware from the objects, verdict.unstated survived, and overall_confidence None where it used to print the judge's 1.00. A verdict the judge stated and put no number on is published with None too and the header says "not assessed"; the analysts' mean is their confidence in their own claims and is not borrowed for a decision they did not reach.

A misplaced extension does not cost the bundleCopy Anchor Link

The prompt asks for x_maljan_assessment beside objects. A model that writes it inside the list used to fail Bundle.model_validate outright, and one live run lost all twenty-five of its objects to a text-extracted verdict twice over. agents/judge_postprocess.lift_misplaced_extensions runs before validation: the block is moved to the property it belongs to, unchanged, and recorded as verdict.assessment_relocated with the state resolved and no retry spent — there is nothing left for the judge to fix. A top-level block already present wins, and the inner copy is set aside. Any other item whose type is not one of schemas/stix_models.BUNDLE_OBJECT_TYPES is set aside under stix.unknown_object and fed back once. So is an object of a type the bundle holds that cannot be read as written — a file or process carrying a property STIX 2.1 does not define for it, an observed-data carrying the deprecated objects dictionary, a value its model cannot hold — because each object is read on its own before the bundle is, and one object's failure used to cost the whole answer to the text fallback. The file and process models declare every property the standard defines, so what the judge wrote under a defined name is kept as written. What is left is validated.

The published ids are the platform'sCopy Anchor Link

An id carries no decision: it only says which object a reference means. The prompt asks the judge for <type>--<label> ids unique in its bundle — a short label is enough — and postprocess_judge_bundle mints every published id: a random UUID under the object's own type (a technique-derived one for an attack-pattern) with every *_ref rewritten to match. The judge used to be asked for random UUIDs, which a model cannot produce; it copied documentation-shaped hex instead, one malware id reached fourteen stored runs of six samples, and its version digit is one no RFC 4122 UUID has, so the OASIS validator refused every object that carried or named it.

A label two objects share is not resolved: duplicate_label_violations asks the judge (stix.duplicate_label), each object gets its own id, and no reference naming the label is rewired onto either. The map from each label to its published id travels with the verdict and is kept, with the judge's own bundle, in analysis_reports.judge_stix_bundle, served at /reports/{id}/stix?source=judge — the bundle every export decline row says an object "is unchanged in". That bundle is the judge's JSON as the judge wrote it ("as_written": true), not a dump of the platform's models, so it holds every property the judge wrote. A property the models for its type do not declare — an indicator's valid_until or kill_chain_phases, a relationship's description, a malware object's aliases — does not reach the export, and each object that carried one is a recorded stix.property_not_carried row naming the keys. The row is never fed back: nothing in the judge's answer is wrong, and the retry is not spent on it. A malware object's sample_refs is carried. Feedback names the judge's own positions and labels (objects[3] 'indicator--2'), not positions in the post-processed list, and a drop maps them back. Nothing is written into a judge object that the judge left out: an untyped indicator stays untyped, and a malware object without is_family, which STIX requires, is asked about (stix.is_family_missing), and an is_family the judge wrote is published as written. Two more questions are asked of a judge malware object, once each, and answered by the judge: is_family: false on an object whose name is the family the judge attributed (stix.is_family_contradicts_family), and a kind the export cannot state (stix.malware_type_vocabulary) — labels written with no malware_types (the export does not carry labels, which the validator reads from the answer as written), or a malware_types value outside STIX 2.1's malware-type-ov vocabulary, which the question lists (validation.MALWARE_TYPES). The judge's prompt says an object named after the attributed family stands for it and that its kind goes under malware_types from that vocabulary. Nothing is rewritten: what the judge keeps is published as written. When the run states a family (the judge's, else the sandbox's; "Unknown", "none", "n/a" or empty is none) and no malware object is named for it, the export adds the family's object (is_family: true, the family's ledger ids) and relates the judge's object to it as variant-of; the platform's own object, minted when the judge wrote none, says is_family: true when it is named for the family.

A judge malware object the export declines for a property the standard requires does not take the judge's relationships with it. The platform's own sample object stands in for it, and every relationship that named it moves onto that object unchanged — confidence, basis and credits as the judge wrote them — so the technique the judge numbered is used by the export's malware object and published at the judge's number, as the report publishes it.

Every indicator the export publishes indicates the malware object that stands for the sample: each was published for this sample by the one publish rule, and an indicator related to nothing was a finding missing from the export's graph. The judge's own edges are kept as written, and the sample's hash indicator has its edge from the start. Every other indicator — the network and string rows the renderer mints, the IOC table's host rows, a judge indicator the judge related to nothing — gets one edge to the sample's malware object once the integrity pass has folded duplicates (stix_renderer._every_indicator_indicates). That edge says it is the platform's in its description (stix_renderer.PLATFORM_INDICATES_EDGE), so a consumer tells it from one the judge wrote, and the report object's object_refs names it. What the value claims about the activity is still its indicator_types: the string-derived rows stay anomalous-activity. Three get no edge: an indicator the judge related to a malware object by an edge of any type, in either direction (a related-to such as "shared hosting; not specific" is the judge's word that the value does not indicate the malware, and is not upgraded); one typed benign, which says it indicates no malware; and the sample's similarity digests ("Files like the sample": imphash, ssdeep, TLSH, stix_renderer.sample_similarity_pattern), which match files that are not the sample. A Benign export has no malware object and no such edge; the judge's own bundle is never edited.

The export names its producer in STIX's own vocabulary: one identity for this platform, identity_class: system, under an id derived once (stix_renderer.PRODUCER_IDENTITY_ID) so every export carries the same one, and created_by_ref naming it on every other object — a copy, so the judge's own bundle is not edited. The report object's type follows the verdict the record states (stix_renderer.report_types_for): malware under a Malware verdict, and threat-report under Suspicious or Benign — the report-type-ov vocabulary has no term for a finding of no threat, and its general entry is the one that claims no malware instance. A Benign export was once typed malware. Every stored export before this carried software and malware-analysis, neither of them in its vocabulary, and an identity no object named.

An exported object carries the ledger entries the run's record ties to it, as x_maljan_evidence_refs: ev_ ids, each once, in ledger order. The sample's uses edge to a technique carries the entries an analyst finding naming that technique cites (evidence_ids) and the entries of the asserting tools (capa, Sigma, YARA, LOLBin, sandbox signatures) whose structured output names it (pipeline/evidence_summary.technique_evidence). A malware object the export mints from the family name carries the attribution's family_evidence_ids. Nothing else gets the property. An id in a claim's evidence_ref sentence stays in the sentence, and no object is matched by value.

The tie from a finding is per finding, not per technique. A finding's evidence_ids belong to the finding as a whole, so a finding naming T1055 and T1082 and citing one entry ties that entry to both edges. The edge says a finding naming this technique cites the entry, not that the entry names the technique; an asserting tool's entry is the one tie that does.

Every id the export writes is one the run's ledger holds, in the ledger's order: the report node hands the renderer the ledger's ids, and a run with no ledger entries exports none. A family id the ledger does not hold is left off the minted malware object and recorded as stix.evidence_ref_not_in_ledger beside the export's other decisions; the model is not asked again, because the verdict is final by then. The property is the platform's alone. A judge object that writes it is read without it and recorded as stix.property_not_carried, with no retry, and the renderer sets the property on every object from the record. The edge carries the ids and the attack-pattern does not, because the attack-pattern's id is the same in every export.

The validator gate is no new error and no new warning kind. The property draws the validator's {401} best-practice note that a custom property should be declared through an extension definition, as every x_maljan_ property does; moving all of them to an extension definition is a bundle-wide change of its own.

A sandbox's process tree is exported as STIX 2.1 observables: one process per node (pid, command line, child_refs), the image each ran from as a file whose id is derived from its name, and an observed-data naming them by object_refs with number_observed: 1 — one run is one observation. Every process the sandbox listed stays, in its place in the tree; one the sample's lineage rule (sample_process_tree) leaves out of the sample's tree says so: a process outside it carries x_maljan_sample_process_tree: false (the desktop's explorer.exe under sihost.exe), and one the two lineage facts dispute carries x_maljan_lineage_disputed with the fact that alone names it (marked or file), as the report's network rows say it of a flow's process. A process of the tree carries neither, and a judge's object never does. The 2.0 form it replaced embedded unnamed processes carrying a name 2.1 does not define and put the process count in number_observed; the OASIS validator could not read it. tests/unit/reporting/test_the_export_passes_the_official_validator.py renders a rich Malware export, a sandbox export and a Benign export through the real path and fails on any error the validator reports (stix2-validator is pinned at 3.2.0, the last release that ships its schemas; 3.3.1 validates nothing).

The technique checkCopy Anchor Link

Four parts, all in pipeline/validation.py and tools/knowledge.py, none of them a rewrite: the check produces violations and annotations, and the id an analyst wrote stays the id in the report.

This is a change of method from the tree of 2026-09-12 (commit bd511d81d). That tree carried a re-grounding pass, ATTCKValidator.correct_isr_reports, which replaced an analyst's technique id with the alignment index's best candidate whenever the gate disagreed, so the identifiers in a report were valid because the pass had made them so. Here what holds by construction is that no invalid id goes unflagged: every id is checked against the vendored catalogue, and one the catalogue lacks is reported, flagged technique_id_valid=False and kept as written — an invalid id can be kept, and then it is kept marked. The technique choice is the model's, made under deterministic challenges: an id the catalogue does not have, a domain or platform the sample cannot have, an alignment the index disputes, and a corroboration count that says who else named the technique. The gate is one of those challenges; it no longer decides.

1. Validity (attck.unknown_id, exact). Every id against the vendored catalogue. When the catalogue cannot be read the check says so instead of answering "nothing unknown": run_summary.validation.not_run lists attck.unknown_id and the run carries a degradation reason. A claim that reads as absence (attck.absence_claim). A claim whose text names the technique's behaviour only to say it is absent — "The binary does not contain any obvious persistence mechanisms" with T1547 — is asked once whether the behaviour is absent (then TECHNIQUE: NONE) or the sample does it. The reading decides only whether to ask; the platform never withholds a technique the analyst keeps. The behaviour is read with the capability check's own negation reader over the technique's vocabulary: the capability terms that list it, its catalogue name, and its tactic names as a category phrase only ("discovery mechanisms"; Stealth and Defense Impairment also by their pre-19 name, Defense Evasion). The reading is stricter than the capability check's about which cue governs a mention: no comma and no coordinator ("and", "instead", "only", "but") between them, and not a cue that opens an assertion ("no longer", "not merely", "never stops") nor "never-" before a listed past participle ("a never-exercised web C2"). A pair of dashes around an aside is read as if the aside were not there; a single dash is a clause break where a clause with its own verb follows it or the cue before it is "instead of" or "rather than". Two more readings of absence do not need the cue next to the mention: an item of a noun list a cue in the clause negates, the list joined by commas and a final "or"/"and" and ending at its head noun ("does not contain persistence, lateral movement, or exfiltration mechanisms"), and the behaviour as the subject of "is absent", "is not present" or "was not observed" (which the capability check also reads as absence). A later mention in the same phrase shares the reading of the first ("command and control (C2)"); any other mention is an assertion. An analyst that drops the id has removed it. An id kept after the question is published as usual, and the claim is noted (ClaimEvidence.kept_after_absence_question): the ATT&CK table, the judge's summary and a downstream stage's upstream-findings block print "the claim naming it reads as absence; the analyst kept the technique when asked" beside it (the table only when every analyst claim naming it is noted). A question never sent — no time left after the loop — notes nothing, and its finding says it was not asked. Long-term memory stores as a past case's techniques only ids with no such note and a valid catalogue entry, and the judge's memory query follows the same rule; a noted claim never displaces a positive claim for its technique when chunk answers are merged. A benign control run had published thirteen techniques from such claims. A claim citing only failed calls is flagged the same way once the run's ledger is known (the judge node, validation.mark_claims_citing_only_failed_calls): every reference its evidence names is an entry id and every entry it cites is a call the ledger files as failed, so it rests on nothing the sample showed; a claim that also names a sandbox item (net:3) or any other reference is not flagged (a tool's name is in its own error text, and grounding reads token overlap). It is kept as written and logged; the judge's summary, the upstream-findings block and, when every claim naming a technique is flagged, the ATT&CK table print "the claim cites only tool calls that failed" beside it (ClaimEvidence.cites_only_failed_calls). Publication is unchanged. The outcome every finding is published with in the conversation is the kept answer's: an analyst whose retry lost claims keeps its first answer, and the loop checks that answer again before it says what became of each finding (retry_with_feedback_sync(keep=)). A retry that is kept although it no longer states claims or findings of the first answer — the claims by the values of theirs it states nowhere (claim_drops.dropped_values), the technique ids the retry was asked about aside; the findings by title — is followed by one question naming each item (isr.retry_dropped, validation.retry_drop_question), with a validation_feedback event when it is asked and when it is answered. The tool results the first answer read are in neither the retry nor this question: the question names each item whole with its EVIDENCE line, and shows each ledger entry the items cite once, the way the analyst had it in view when it wrote the claim (base_agent.cited_entry_texts): an entry from its own calls, or one it read again in its loop (a row of its own repeating that entry, whole, in pages or cut; a chain of repeats followed to its end), is shown whole and uncut, marked where the ledger holds part, unless the conversation holds it verbatim; a pack entry it saw only as its summary line is named, with a note that the line is in its brief and the whole entry in the ledger; any other entry is shown whole. Each turn is measured framed, run-state block included, against the job's learned window, else the window the model's settings declare or its server reported, else the vendored table's (_window_room_chars); items whose entries do not fit together are asked in parts, each beside its own entries (_retry_drop_parts, each part built when it closes); an entry that cannot fit beside its item even alone is named by id wherever it is cited, and one named to let an item fit is named in that item's part only, each named by id as held and not shown. What the analyst answers stands as it gives it: the analyst answers KEEP <label>: <reason> or WITHDRAW <label>: <reason> per item, several labels at once (KEEP C1, C2: …, KEEP C1 C2: …, WITHDRAW C3 because …), several decisions on one line (KEEP C1: …; WITHDRAW C2: …, KEEP C1, WITHDRAW C2), or KEEP all / WITHDRAW all (all others, the rest) for every item a decision of its own does not name, all except C1 leaving the listed items undecided. A decision is read only where a clause begins: a line's start (after a list mark or a list number such as 1.), after ;, after a , (or , and) that follows a decision's labels, or after a sentence's end when a whole decision follows (KEEP C1. WITHDRAW C2., WITHDRAW C2: no. KEEP all others.). It may name its labels first (C2: WITHDRAW - guess). Once its reason opens (:, a dash, ., because) the rest of its sentence is the reason and no word in it is read as a decision, so KEEP C1: it holds. Withdraw C2 would lose data decides C1 only. Each line is read in one pass. Each item is the first answer's own claim, its sentence, technique id and block with it (claim_drops.dropped_claims), so of a technique list split on commas the claim left out is the one put back. A kept item goes back into the answer as the first answer wrote it, a withdrawn one stays out, and an item with no answer stays as the first answer wrote it. Each item, its state and the reason are recorded per analyst in run_summary.validation.retry_drops, listed in the run summary and in the report's section 13 (validation.retry_drop_row): every value masked as model text in the record is, in the case the claim wrote it, and the sentence defanged after the mask. A kept retry that restates fewer of the first answer's claims than it leaves out is more another answer than a fix of this one, and does not replace the first answer (base_agent._restated_few). Restated is read by the claim's values (claim_drops.dropped_claims): a claim that holds a value, every one of which the retry states, and that it was not asked to fold away; left out, a claim the question names. A claim whose only values left out are technique ids the retry was asked about, and a claim that holds no value, are counted neither way. The one question about what it left out then says the items stand in the answer as first written, beside the retry's claims (validation.retry_restated_few_question), and also names each claim of the first answer that holds no value and whose sentence (spacing aside) no claim of the retry writes, so no claim leaves the answer unasked. It is asked under isr.retry_restated_few as well as isr.retry_dropped: both have the same validation_feedback events, retried then resolved or survived, and both count in validation_fed_back; validation_retry_restated on the loop's record keeps the counts. The answer is read and applied as above; a withdrawn item stays out. The validation retry is shown what the answer cites. It is a turn over the brief, so in front of its closing it carries each ledger entry the answer's claims and findings cite that the conversation does not hold, the way cited_entry_texts gives it to the drops question (validation.validation_entries_text). The turn is measured framed, with the answer as it is sent back, against _window_room_chars beside an answer of the cap the technique cards are measured with, every entry's id reserved first; an entry that does not fit beside those shown is named by id, and with no window known every entry is shown (_with_cited_entries). When no entry fits, the turn is sent as it was, with no line of names. A turn that fitted the window before still fits it, so whether the cards and the cut-at-cap question are sent is decided as before. The whole answer asked for after a retry that could not be merged fits the entries again, over the turn it is sent as: the first turn, the retry's own answer and the question after it, beside an answer of the output cap. The questions after the loop carry its tools. The validation retry, the drops question and the whole-answer question each run the analyst's own tool loop over their conversation (BaseAnalyst._answer_after_loop, execute_tool_loop(asked=...)): the tools its loop binds, in their order, with the loop's guards, stall deadline, breaker and repeat guard. They are part of the loop before them and share what it left: the time to its deadline (a question that cannot hold an answer at the loop's pace is not asked) and its steps, each question spending from them; with fewer than three steps left a question is asked in the tools-free call and the loop's record says why (asked_without_tools). Their steps are not added to the agent's own (steps_spent), so a delegated callee stays inside its ask's steps. Each answer is checked against the ledger as it stands when it is checked, so an entry a question's call filed may be cited. The model decides whether to call one. A question whose loop ends at a cap, or with no text, is asked once more in its tools-free call, worded for no tools, in the time left, so it never answers less than the tools-free call did; a call is filed on the ledger as any loop's is, and an identical read-only call the analyst's loops made this round is answered from that entry (evidence_recorder.EARLIER_TURN). The answer is read as before; a loop a cap ends without an answer is an unanswered question, and the first answer stands. Each turn is recorded under the question's own call, the loop's record under the loop it follows (asked_after), and the window measures count the definitions the turn carries. The retry and the whole-answer question say the tools are attached and that a claim may be fixed by citing an entry or by reading it (validation.ANALYST_TOOLS_ATTACHED); the drops question says an item may be read or checked before it is decided. A model that cannot bind the tools is asked in the one tools-free call, and the log says so, and the reason is on the agent's and the run's degradation reasons; so does a question whose loop cannot bind them. A question a cap ends does not announce that the stage ended at a cap: the first answer stands, and the record under asked_after says why. A retry changes only what it writes (pipeline.retry_merge). A claim is named by its block number everywhere: its block's place among the answer's claim blocks, counted from 1 (validation.claim_block_indexes), which is what a flag's path (claims[<block>], the function-claim check's included) and every question's "claim N" name. When the answer being fixed was read from one written answer with every block it began read, none set aside by the consistency gate, and any number its headings wrote equal to the block's place (retry_merge.numbering_unsettled), and no whole answer is asked for (a cut or repeating answer, a chunk's cut), the retry is asked to write again only the claims it changes, under their numbers, a new claim under a number the answer did not use, WITHDRAW CLAIM <number>: <reason> to take one out, and its findings block with only the findings it changes or adds, WITHDRAW FINDING "<title>": <reason> taking one out (ANALYST_FEEDBACK_CLOSING_BY_NUMBER). WITHDRAW lines are read in any case, with lists and ranges (WITHDRAW CLAIMS 3, 5 and 7-9), each block taking the reason of the first line that names it with one and no other; any other line that holds both a claim number and a withdrawing word (withdraw, retract, remove, drop, delete), in either order ("I withdraw claim 2", "Claim 5 is withdrawn", "CLAIM 2 is withdrawn", "Drop claim 2"), is a doubt, the own number of a line the reader reads as a claim heading aside. A heading that withdraws its own claim is a doubt too: a withdrawing word in its note (CLAIM 2 (withdrawn):), "withdraw" or "retract" in any form anywhere in its sentence (CLAIM 2: This claim is withdrawn because …), or a bare "removed", "dropped" or "deleted" opening its sentence before a mark, the line's end or a reason (CLAIM 2: [Removed] as unsupported), so "Drops a.exe" and "Dropped payload a.exe runs" describe a claim. The retry is then merged into the answer by block number (retry_merge.merge_retry): the merged answer is the first answer with only the retry's changes, so its disputes and every field the retry does not write stay; a block written again replaces the block of that number, every claim its TECHNIQUE line reads at once; a withdrawn one is out; a new number is added after the answer's claims; every other claim stays as written; a finding is replaced, withdrawn, added or kept by its title the same way. The merge chooses which version of each claim stands and writes no word. Each item a WITHDRAW line names is recorded with the line's reason in run_summary.validation.retry_withdrawals (validation.retry_withdrawn_row), listed in the run summary and in the report's section 13 under "Items a validation retry withdrew", on every path. One question (validation.retry_unplaced_question) is then put about what the merge left as it was and may not be: each claim a question was about that the retry neither wrote again nor withdrew — by the flags' paths, and for the questions that name no path, the claims their checks found (library-only claims, claims a function's facts do not hold, claims whose TECHNIQUE line was not read) — and each finding the retry did not write again while it wrote findings under new titles, which may be the one it renamed. It is read and recorded in run_summary.validation.retry_drops as above, a row carrying merged and saying the merged retry neither wrote again nor withdrew the item; a claim no question was about that the retry does not mention is no drop. Where the numbers do not place the retry beyond doubt, nothing is merged and the analyst is asked once for its whole corrected answer (validation.whole_answer_after_retry_question, naming why), which is read as a whole answer always was, with the kept-retry question; the items its retry withdrew are not asked about again, and with no whole answer the first answer is kept without them. A whole answer stands as written: a withdrawal is recorded only for an item it no longer states (by its values, or for a claim with none, by its sentence), so the record never says an item it publishes was withdrawn. A retry read whole as written that both writes an item again and withdraws it is a doubt too. The doubts: a retry block with no number or a number written twice, a block left unread, a WITHDRAW line not read exactly or naming what the answer has not, a number both written and withdrawn, a retry with nothing to read, a retry cut at the output cap, a sentence written as written under another number, a claim no question was about written again with no value (claim_drops.claim_values) in common with the claim whose number it took or with no value on either side, and a retry that wrote again a claim no question was about while it left a claim a question was about neither written nor withdrawn. A retry that numbered none of its blocks and wrote at least as many blocks as the answer is a whole answer as written and is read whole without the extra question, its WITHDRAW lines applied the same way. The loop's record says which (validation_retry.merge: what the merge did, or why it merged nothing and whether the whole answer was asked for). A claim that does not describe its technique (attck.claim_does_not_describe). A claim whose sentence shares no term with the technique it carries — no capability term listing the id, no word of its catalogue name or its parent's (compared with common endings off: "obfuscation" and "Obfuscated Files or Information" share one; the verb a name opens with, when it ends in a silent "e", also by its -s, -d and -ing forms compared whole, so "deobfuscates" and "decoded" share one with Deobfuscate/Decode Files or Information while "stated", "computer" and "officer" share none with State, Compute or Office), no tactic as a category phrase, no procedure word of the technique — is asked once to keep the technique only if the sample does it, and then to say what it does. Decided only where the catalogue gives the id's name, and not asked of an absence claim or a platform mismatch, which get their own question. The answer stands; a kept id is published as stated and nothing is noted on the claim. A reference run had published OS Credential Dumping on "accesses the PEB … to bypass sandboxing". On the stored claims of every benchmark run (123 claims with a technique id) it asks 18, three of them true claims whose sentences used none of the technique's words (Ingress Tool Transfer on "downloads and writes a file", Native API on "the raw syscall() entry point"). A technique's procedure words (validation.procedure_words) are the calls, classes and artefacts the vendored data that ties an id to its procedures writes for it: the technique card's requirements and indicators and the API catalogue's rule for the id (not its import lists), plus a sub-technique's parent's. Only identifiers are taken: a name with a capital after a small letter or an underscore (GetComputerName, ITaskService, SecurityCenter2, Win32_), or a module or Windows program name the text writes as something run or called (calls into ntdll's, schtasks /create, the wmic tool; not a target such as "a handle opened on lsass.exe"); acronyms, format and platform words (HTTP, XML, MAC, Win32) and words inside a phrase the text negates ("without going through LoadLibrary") are not. A word counts only where the data of one technique family (a parent and its sub-techniques) writes it, a call of a module a family's data names counted for that family too: measured, every word is one family's but InternetReadFile, LdrGetProcedureAddress, NtLoadDriver and RtlGetVersion, which are calls of WinINet or ntdll. A sentence's word counts in the same shape: an identifier the card writes as an identifier, in its ANSI, wide and extended spellings; a program, a module or a call of a module the card writes as what is called (calls into ntdll's …) only where the sentence writes it as something run or called (a switch, "command line", or a run, call or use verb in its sentence part: "runs … through cmd.exe or wmic.exe", "calls NtQueryInformationProcess"), not where it is named as an object ("the kill list holds wmic.exe", "the hash table holds NtUnmapViewOfSection", "the Run reg key", "ntdll is loaded"). An identifier written as joined words names each word, compared with the stems of the technique's name that the names of one technique family only hold (BeingDebugged under Debugger Evasion; "file" is in twenty families' names, so DeleteFileW shares nothing with File Deletion). None of these counts at a place the absence reader reads as absent ("does not invoke wmic", "not an ordinary LoadLibrary/GetProcAddress pair"), nor anywhere in a sentence that says the behaviour was not seen, run or used ("imported but never referenced", "but no request was seen"): those are asked the does-not-describe question as before, and the absence question reads only what it read before. The vendored ATT&CK table holds names, tactics and platforms only, so the catalogue's descriptions, detection text and procedure examples are not read, and the capa rules are downloaded beside the repository, not vendored. The words are built once per technique. A sentence also describes its technique by the plain words the vendored texts of one technique id (its card's requirements and indicators, its API rule) describe it with (validation.described_by_its_words): each word compared without its inflection, its silent "e" and its plural ("decode", "decodes", "decoded"; "delete", "deletion"; "URL", "URLs"), generic English words (data/english_stopwords_v1.json: "very", "few", "made"), calls, programs and modules left out (a procedure word counts only as one, above), and each weighing one over the number of technique families whose texts write it, so a word of one family weighs 1, "encoded" (three families) a third, and a word of more than six families ("file", "command", "process") nothing. The six is a measured heuristic threshold beside the procedure words' one family, not a cap on any data. A sub-technique reads its parent's texts, and a parent each of its sub-techniques': API names found "by a walk of each loaded module's export table" describe Obfuscated Files or Information. The sentence has to write two words or more that the texts of one of those ids write, their weights adding up to one: one word alone is often an object a card acts on ("a short header" is not Masquerade File Type), and two words of two ids (one the parent's, one a sub-technique's) are not what the data says of one technique. They are read as procedure words are: none counts in a sentence that says the behaviour was not seen, nor a word the absence reader reads as absent or one after a negating word of its own clause ("no string is encoded and nothing is decoded"). Measured on every stored claim with a technique of five runs (1,103 pairs): the question fell from 399 to 292 asked, and on a hand-labelled sample of 100 asked pairs from 73 asked of true claims to 42, every one of the 27 asked of claims that do not describe their technique still asked. A sub-technique whose sentence shares terms with it only through what every sub-technique of its parent shares (the parent's name and capability terms, its tactic) is asked the same question, naming the sibling, when the sentence writes none of its own distinctive words (its vendored name's words that are not its parent's) and writes the whole vendored name of a sibling of more than one word: Change Default File Association on a sentence about accessibility features and "persistence" (validation.sibling_named_instead). It only adds a question where the check used to pass: a sentence that writes one of the sub-technique's own words, or names no sibling by its whole name, is read as before. The question as sent ends with the named technique's card, where it has one; the finding recorded is the check's message alone. Each technique's card is shown once per turn. A retry turn that carries cards is measured against the window with an answer of the output cap, on every path, and is sent without them when it does not fit with them: a card never costs a question. One reasoning card per technique (memory.technique_cards, data in data/attck_technique_cards.json beside the vendored table). A card holds its kind (behaviour-focused: the action alone is the technique; intent-critical: the action needs a stated adversarial purpose), what the evidence has to show, the indicators to look for, and the sibling techniques it is confused with, each with the criterion that tells them apart (removing hooks from a security tool is T1685 Disable or Modify Tools, the current id of the retired T1562, not T1070 Indicator Removal). The cards are written from the ATT&CK definitions of the techniques the vendored table carries and cover every technique the capability terms list and every technique the analysts named in the recorded local3, local4 and hosted run2 to run4 benchmark runs; techniques first named in later runs may have none. A card is reference shown beside a technique a model already named: in this question and in the judge's technique question. Nothing is decided from it, no question is asked because of it, and the report does not print it. A sub-technique with no card of its own is shown none, since its parent's kind and requirements need not be its own. Tests hold every card's id, name and sibling ids to the vendored table, and the leak test reads every card's words with no allowance: a sibling whose label is a term the evaluation key scores is left off its card (115 pairs).

2. Domain and platform consistency (attck.platform_mismatch, exact). The catalogue's domain and platforms for the id against the routed sample — a Windows PE is enterprise/Windows, an APK mobile/Android, an ELF enterprise/Linux, a Mach-O enterprise/macOS, an unknown platform is no check. Raised in the analyst's loop and on the judge's attack-patterns; the feedback names the technique, its domain and platforms and the sample's. CapabilityCell carries domain and platforms from the catalogue and the FP linter's C1 reads them.

3. Alignment (attck.weak_alignment, the paper's gate, heuristic, and the only part that is off by default). For every technique an analyst keeps, the claim text is ranked against the hybrid ATT&CK index; the claimed id's own TF-IDF gate score and the index's candidates — narrowed to the sample's own ATT&CK domain and platforms, so nothing out of scope is ever proposed — are written on the claim (ClaimEvidence.alignment). The ranking lives on the ISR record and in the judge's TECHNIQUE CHECK block; the report shows it only for a technique the gate questioned and the analyst kept. It runs only when the index is warm in this worker (validation.alignment_gate = auto); validation.alignment_gate_build lets the first run that wants it start the build on a thread and go without. The index never substitutes an id.

   Whether that ranking may also question a claim is validation.weak_alignment, and it is false. The end-to-end audit measured the cost of the check as it stood: the index is domain-blind, so a claim about a Windows PE was answered with Mobile and ICS candidates (T1406, T1471 for T1027; T0885, T0874, T1639 for T1071.001), and it scores a correct id near zero often enough that 81 of 92 corrections in one run, 16 of 19 in another and 33 of 33 in a third were of this kind — each batch a full extra model turn. With the setting on, a claim is questioned only when all four hold: the claimed id scores under validation.alignment_threshold (0.05); the index did not rank the claimed id itself among its in-scope candidates (wherever it ranked it, it did not fail to think of it); no in-scope candidate names the claim's own technique family or tactic; and the best of the ones that do disagree beats the claimed id's score by validation.alignment_margin (0.20). At most one weak-alignment batch is sent per agent turn.

   Measured on the audit's own recordings (188 corrections, 105 distinct rankings, replayed in tests/fixtures/attck_alignment_recorded.json): of the 36 rankings whose claimed id the audit read as right for its sample — T1027, T1071.001, T1055, T1547.001 and the ids the ELF run published, which are the ones this corpus holds rankings for — the narrowed rule questions none, where the shipped check questioned all of them. Of the other 69 it questions 5, each naming a candidate from the sample's own domain and another tactic that beats the claim by the margin. Two of the six audited runs are absent from the corpus because they produced no weak-alignment correction at all: the APK run and the Ollama-backed pair. So is T1497.001, which the brief names and which no run questioned.

   The "not ranked" conjunct cannot be measured on those recordings — the shipped gate fired only where the index had not ranked the claimed id, so none of the 105 rankings contains it. The fixture carries 105 derived rows for it, each a recorded ranking with the claimed id put back at the gate score the index gave it, marked as derived: the rule questions none of them, including the five its recorded twins are questioned on.

   That is the bar the setting is held to, and it is the reason the default stays off: 5 questions over 105 rankings is a small enough yield that a run pays the turn only when an operator asks for it.

4. Corroboration (exact). Per technique in the run, asserted_by — the deterministic sources that assert a technique from this sample: capa's attck field, a Sigma rule's technique tags, a YARA TTP rule's meta.technique_id, lolbin_lookup on one of its command lines, a sandbox signature — and claimed_by, the agents. Those tools are the whole list (evidence_summary.ASSERTING_SOURCES). A reference lookup is never a source: attck_lookup, attck_validate and resolve_technique say what an id is, and similar_cases and family_lookup return other samples' techniques, so none of them adds a row or counts as an assertion. An id any ledger entry of the run marks invalid (valid: false from attck_lookup, a row under invalid from attck_validate) is never counted as asserted, whichever rule named it. The judge's evidence block reads the same rule. The import rules (api_capability) are not among the sources either: by the platform's own rule they are a reference association, not an assertion. The API catalogue associates a technique with an import set, and an import set is what a program can do rather than what it did, so its associations travel under associated_by, shown in a Catalogue column for reference and counted for nothing. Each association carries the share of a named benign corpus the same rule fires on, so the column can be read for what it is. All but one group per platform is informational for the same reason, naming in corroborated_by the APIs whose presence beside them would mean something; the one that keeps a label carries flags_with and waits for it. An asserted id the catalogue has retired (upstream Sigma rules and the case corpus still name a few) is marked retired in ATT&CK 19.2 in the table. Two flat lists in run_summary.corroboration, rendered as a table in the report and shown on the console's technique cards. No weights, no score; a technique nothing asserted keeps its row with the empty list showing, which is the firing-rate reading the paper argues for.

What the check questioned and the analyst kept reaches the judge as a TECHNIQUE CHECK block beside the evidence summary, and the report's validation section lists the unresolved rows with their messages. What the judge decides is the judge's: severity (with its rationale), malware_category and family come back on the bundle under x_maljan_assessment and the report prints them as answered. A severity nobody assessed prints as "not assessed" rather than defaulting to Informational; a family the judge could not cite evidence for is kept and flagged unverified rather than silently zeroed.

A verdict no judge decided carries no confidence. The judge node writes verdict_fallback on the state whenever its own body raised, or the bundle being reported carries x_maljan_fallback_verdict — which is what a bundle this pipeline built out of text says about itself, however the round ended; the report node reads that one channel and sets overall_confidence to None rather than deriving a number from the analysts' confidence in their own claims, and the header prints "not assessed". The reason is recorded once: a judge that raised is filed under verdict.fallback by the report node, and a judge that answered with something other than a bundle has already filed verdict.fallback or verdict.timeout itself, so the summary carries one row and not two.

The verdict prompt states its output budget (judge_max_tokens, reasoning included) and a compact bundle (COMPACT_BUNDLE_RULES): the JSON on one line, the confidence, basis and credits on the relationship only and never repeated on the object it relates, an attack-pattern with at most one sentence of description, and no property the platform fills in — created, modified, spec_version, valid_from, and pattern_type, which is always stix. Every relationship is the judge's own: which indicator indicates the sample, and which does not, is its decision, and the platform writes no edge into its bundle. A reference judge's answer was cut at 8,192 tokens twice. Only its first 2,000 characters are stored; they are pretty-printed (22% of the characters are line breaks and indentation) and repeat the relationships' annotations on the indicators. Rebuilt from that head and the ids the log names, the objects it wrote take about 15% fewer tokens under the compact contract. That is an estimate from a reconstruction, not a measurement: the answer was cut, so its true length is unknown, and the compact contract alone fits it only if it would have closed within about 9,600 tokens as written. An answer that stopped at the budget is told so — verdict.cut_at_output_cap, with the cap, the answer's characters, the objects it began by type and its indented lines, the length it was cut at as the bound the next answer stays under and the kind of object it began most of, asking for the compact bundle — rather than that it was not JSON, which made a judge whose bundle was too large write the same bundle again. The retry is the first prompt and that question: the cut answer is described, not sent back. Sent back, it made the retry's prompt larger by exactly the cap, and at temperature 0 a benign control's judge answered with a response one byte shorter than the one it was asked about. When the retry is still not a bundle, the fallback reads the x_maljan_assessment object the answer wrote whole, if it did, through the reader a whole answer goes through and JudgeAssessment, and keeps it only when its verdict is one of the three words. The run then publishes that verdict with the judge's own confidence, severity and family, still read as fallback and still filed under verdict.fallback. The indicator objects the answer's bundle wrote whole among its own top-level objects are kept too — read item by item until the first the cap reached, never from reasoning before the bundle, a string or a nested object — as written with minted ids, asked what a bundle's indicator is asked — findings recorded, an ungrounded one dropped — and put to the one publish rule like any judge indicator, so decoded C2 hosts an answer wrote before the cut are published exactly as they would have been from an answer that closed. Nothing is read out of prose. A fallback that is not Malware has no malware object, so its record — the degraded path and the technique ids only the raw text named — goes on a note about the objects the fallback bundle holds; STIX requires a note to name at least one, and a fallback that holds none writes no note, and keeps the judge's text on the bundle's own x_maljan_fallback_verdict.reasoning instead. The judge's text is kept whole and as written wherever the fallback stores it (it was cut to 2,000 characters with its line breaks folded), and so is the mediator's text where the text path makes it the mediation summary (it was cut to 500). The ids are on x_maljan_fallback_verdict.model_only_technique_ids on every fallback. The export declines, with a record, any note, opinion, grouping or report left naming nothing, and the integrity pass lists each reference once: a reference fallback exported a note with no object_refs and a report object naming the sample's hash indicator twice, and failed the official validator.

A finding the judge was never shown — first raised by the answer to its only retry, or recorded on a fallback where no turn was left — is recorded with "asked": "false" on its run_summary.validation.unresolved row. A finding counts as asked by its code and its subject — the technique a credit is for, the malware object's name — so a credit the judge renamed in answer to the question is still the question it was asked; a finding with no subject is compared by its words with its object's position taken out. The row carries the subject, and the export's records say which happened: "the judge kept the credit when asked" only of a credit it was asked about, and "the judge was not asked about it" otherwise; the same for a malware object kept without is_family.

Two metrics record the outcome:

• run_summary.validation — how many feedback retries the run spent, a count per violation code, and every finding that stayed unresolved with the agent that owns it.
• run_summary.corroboration — per technique id, the two lists item 4 of the technique check describes, asserted_by and claimed_by, with no score. The same collection builds the judge's evidence-summary block, so the metric and what the judge read cannot disagree.

A degraded run is not capped. The judge is told in the prompt why the run is thin — no sandbox report, an analyst that failed, a container nothing could open — and sets its own confidence; the report header states the same reasons.

One more repair belongs here because it decides whether an analyst's answer exists at all. A tool loop that ends on a turn that is not a report is asked once more for one (the final-answer nudge). A live loop ended on an assistant turn whose tool call carried arguments that never parsed; no tool ran, and sending that turn back made the server fail rendering it ("Failed to parse tool call arguments as JSON", HTTP 500). The nudge and the forced synthesis now send the transcript without such a call — the turn's own words stay — and when the plain request still fails, the nudge asks once more with the loop's tools bound and tool_choice="none", the one other shape the server accepts. run_summary.nudge.retry_mode names which analysts needed which repair.

An analyst with tools whose first answer called none is told so and asked once. The loop states the fact and the tools it has, by name, in the same conversation (prompt_fragments.no_tool_call_question), and asks whether it wants to call any before its answer stands. The one word KEEP keeps its answer as written; any other answer it writes next stands. The question is asked only when a whole answer after it fits: two graph steps left (one complete model turn), the loop's final-answer reserve at its own pace, the conversation and an answer of the output cap in the model's window, and a spend ceiling that admits it. It is asked at most once per analyst, in its own loops — not after any of them called a tool, and not inside an ask another agent made of it, whose tool calls do not count as the analyst's own. The pass after it is held inside the loop's clock; a stop or a failure that leaves no answer (the spend ceiling, a call's deadline, the clock, a full window, the step cap) puts the conversation back and the first answer stands as written, as it does when tools called after the question are followed by nothing. The loop's budget record carries tool_ask: the tool calls made after the question, what followed (called_tools, answered_without_tools, kept_first_answer, no_answer) and, when the first answer stands because nothing followed, why. run_summary.nudge.no_tool_call lists them per analyst. Four of seven analysts in two local runs answered in one turn while offered 18 to 38 tools.

An answer with no CLAIM block that parses is the analyst's prose and nothing more. It used to be cut into sentences, each a claim at a flat 0.50 no analyst stated, Markdown headings included. The analyst's validation turn now asks once for the claim format (isr.unparsed_answer) — unless the final-answer nudge already asked — and an answer that is still prose leaves the analyst with no claims, its prose as its report, status no_claims with the reason, and the run's degradation reasons naming it ("analyst answers kept as prose, …"). Such an answer is kept whole in run_summary.validation.unparsed_answers, and every validation retry answer the analyst's first answer is kept over (no claim block, fewer claim blocks, a retry that repeats again) is kept whole in run_summary.validation.discarded_retry_answers with why the first answer was kept (validation.discarded_retry_row); both are masked as model text in the record is, bounded only by the answer, and an answer is kept once. A CLAIM block that states no confidence, or one that is not a number, is not a claim either: it is counted and asked about (isr.claim_without_confidence), where the parsers used to write 0.5. Every path that reads claims reads them through one reader, base_agent.read_claim_blocks: it splits an answer at every claim heading (CLAIM:, CLAIM 3:, CLAIM R3: with a label of letters before its number, **CLAIM 4 (REVISED):**, CLAIM 2 [REVISED — retracts claim 5]:, CLAIM 5 -, and a heading whose round- or square-bracketed note is its whole line, its fields on the lines after it; the rule is agents/claim_headings.py) where a block can begin, and at the model's own --- lines, so claims written one after another with blank lines between them are each read. A note written before a heading's delimiter is the model's own words on what the claim is to the debate (a revision, a retraction): it is kept verbatim, brackets and all, in the claim's heading_note (left out of a claim that has none), shown in the judge's listing of the analyst's claims and in the claim events, and never put in the claim's sentence, which every check and the published report and STIX read as before. A heading that is its note alone has that note as its sentence, and its block's key in the repeated-claims check starts with it. The heading's number is never part of the claim, and no number is given to a heading without one; a label written before the number stays in the claim's name (R3, never claim 3), so a retry is never merged into it by place. The static, dynamic and network analysts read it with an EVIDENCE line required; the base analyst's path records a block without one as unsourced. Each read counts the claim headings the answer began before its DISPUTES section against the claims it read and the blocks that stated no confidence; what is left is claims begun and not read, which is logged and kept on the answer it was read from (AgentISR.claims_unread_reason), naming the analyst, the round and both numbers. The judge node carries it as a degradation reason only from the answers in force, so an answer a retry or a later round replaced leaves it in the log. Every heading opens a block, so no claim is read with another's CONFIDENCE, TECHNIQUE or EVIDENCE, and a heading behind a list marker (- CLAIM:, 1. CLAIM:) counts. A block's fields are read in its tail, which begins at the first EVIDENCE, CONFIDENCE or TECHNIQUE label that starts a line; inside the tail a label also counts after whitespace, so fields written on one line are all read, while a label inside the claim sentence above the tail never is. EVIDENCE runs to the next CONFIDENCE or TECHNIQUE label that starts a line when one follows it, so words inside the evidence ("maps to MITRE technique: T1055") never cut it and every id after them stays cited; only when no such line follows does it end at a capitalised label later on its own line. A CONFIDENCE value is the number that opens it, from 0 to 1, or a percentage (85% is 0.85); what follows the number is not part of it, so 0.9., 0.9, and 0.85 (one part lower) are read. A CONFIDENCE label with anything else after it (a word, a bare number above one, a number that runs on into more digits) is a confidence the analyst stated and the reader could not read: the claim is unread, the unread reason quotes each such value (ClaimRead.confidence_unreadable), and the validation turn's confidence question (isr.claim_without_confidence) asks about it with the value quoted. A block with no CONFIDENCE label is counted apart as before. A revision round's answer passes the same consistency gate and validation turn a first answer passes, with the first answer's loop deadline and nudge flag cleared before it is made. A revision is merged into the answer in force by claim (pipeline.revision_merge): a claim it writes again replaces its predecessor; a claim it withdraws (a WITHDRAW CLAIM <n>: <reason> line, or a block under the claim's number that declares the withdrawal) is removed with its reason; a claim a blocking line of the round's mediation named that the revision neither writes again, withdraws nor argues in its disputes is withdrawn by rule, the line being its reason (only the mediation right before the round is read) (debate_facts.read_claim_references reads the claim numbers each line names per analyst, a list, a "claim" written again and a range of up to 20 claims, "claims 32-34" or "17 to 19", naming the analyst its first number names, every number the earlier reading read named as before; the rest of a longer range, or a "claim N" no analyst is read for, names no claim, withdraws nothing and, on a line that blocks by a mark that was read or by having none, is stated once in a sentence of the merge; a claim a blocking line reaches only by the newer reading is withdrawn by rule only when its reference's clause shares a ledger id or an address with it, and is otherwise carried with the line and stated); and any other claim it neither writes again nor withdraws stands unchanged, marked carried forward from that round (ClaimEvidence.carried_since_round, with carried_contested_by when a line that does not block named it), shown beside the claim in every summary, the transcript event, the upstream findings, the evidence bundle and the ATT&CK table's note, and counted per analyst in the report's list of claims the body does not discuss. A revision whose every block writes a number that names a claim in force the block restates, or a number after the last one, is placed by those numbers; any other is placed by what its claims state. A block restates a claim when it states four fifths of the claim's content words, or half of the claim's values of three characters or more (one of them four or more, or a technique id), or a third of them with the claim's technique id; values may be pooled over blocks that each state one of them, words never. A revision that restates or withdraws every claim in force stands as written. run_summary.negotiation.revision_replacements states each merge that carried claims, with their numbers, and each withdrawal with its reason (a withdrawal by rule also among dropped_claims, with the claim's values); a revision with fewer claims that carried nothing is still stated ("The X analyst's round-N revision replaced N claim(s) with M."). The DISPUTES section opens at its label, case-sensitive, with its colon (DISPUTES:) or as a Markdown heading; a label that says there is none on its own line (DISPUTES: NONE, N/A, a dash) opens no section, and prose beginning "Disputes …" is prose. Claims under the section are not read as the analyst's own; they are counted apart. When none of the answer's own claims was read they are recorded as unread. When some were, the analyst is asked once in its validation turn (isr.claims_under_disputes) to write its own claims above DISPUTES and leave a peer's it disputes under it. Asked and kept there, the headings are the analyst's answer: the validation record holds it ("Asked, the analyst kept N CLAIM heading(s) under its DISPUTES section; they are not read as its own claims"), logged at info, and the run is not marked degraded for it. The row carries "answered": "true": the report lists it marked "(answered)" and leaves it out of the count of findings left unresolved, and the console draws it muted. An answer in force the question was never put to (a nudged answer, a validation turn not asked for want of time, a path with no validation turn) is stated as a degradation reason apart from claims_unread_reason ("wrote N claim heading(s) under its DISPUTES section, which are not read as its own"). The code does not read the label's words to decide which they are. Both sentences are informational while the analyst still has claims read (nodes.informational_reasons_in_force): they are listed in §13 with the other limitations and counted in the header's "Notes: … see §13" line, and they do not set degraded_mode (triage_pack.run_is_degraded(reasons, informational=…)). An answer none of whose claims was read, a failed stage and any failed or missing tool still degrade the run; only the operator's choices (pipeline.operator_choice: a key never set, a server switched off, a tool a shared server withholds by policy) are listed apart and never do. The judge's RUN QUALITY paragraph (nodes.run_quality_note) says a run that is not degraded is not, and adds only the sentences that fit its limitations: that a missing tool is an absence of evidence when a reason other than such a note is listed, and that a note on part of an answer leaves the claims it read standing when one is. The techniques an analyst kept citing no evidence (isr.ungrounded_technique) are stated in the same paragraph as a fact about claims, after the run's own reasons, and are not a degradation reason: they say nothing about what the run could examine, the judge's technique question decides each, and the validation findings list each claim. A TECHNIQUE line is one id, a list of ids separated by commas, "and" or slashes (read as one claim per id, each with the claim's sentence, evidence and confidence, and each checked as a technique), or NONE or a dash for none; a closing block separator (· ---) is no part of it. An id followed by the vendored catalogue's own name for it, in brackets or not (T1027 (Obfuscated Files or Information), T1106 Native API, the name with no bracket running to the next comma, semicolon or the line's end; for a sub-technique its own name, or its parent's and its own joined by a colon) is that id. A line that opens with "none" and holds no technique id and no catalogue technique name (none asserted) claims none; one that names a candidate ("None; Process Injection is likely") is asked about. Any other line (bracketed words that are not that name, a qualifier, a negation, ids joined by another word) claims no id, is kept on the claim as technique_line, and the validation turn asks once for the ids alone, an id the claim does not assert left off the line (isr.technique_line_unread). The claims begun are counted against the blocks read, not the claims; a retry is compared with the answer it replaces by claim blocks, so an id taken off a list when asked is the answer kept, and a question about one id of a list asks to remove that id from the line rather than to write NONE. Findings name the block the analyst wrote. Every validation turn after a loop gets what that loop left of its time, not a fresh budget, and is not asked when that cannot hold one answer at the pace the loop measured (its final-answer reserve); what it would have asked is then recorded as unresolved and run_summary.budget.<agent>.validation_not_asked says why. The questions themselves share that time and the loop's steps; run_summary.budget.<agent>.questions sums the ones that ran the agent's tool loop (steps, seconds, caps) and lists each asked without its tools, with why.

An analyst answer that ended at its output cap (llm.expert_max_tokens, or the cap derived from the window when it is 0; for a call the spend ceiling held to less, the held cap it was sent with, recorded per loop turn as it is sent, so a later turn the loop did not keep never stands in for it; by the server's finish reason or by a generated count equal to the cap, since ik_llama.cpp reports stop for an answer it cut) is asked once for a whole shorter one, the way the judge's and a report section's are: isr.cut_at_output_cap states the cap, the characters the answer ran to, the CLAIM blocks it began, and the length it was cut at as the bound to stay under, and asks for the claims the evidence supports best, each written once. The cut answer is described, not sent back, and the question is asked only when the conversation it is sent in, with the turn that carries its questions, and an answer of the cap's size fit the model's window; otherwise it is recorded "asked": "false" with the reason. A whole answer that comes back is the analyst's, fewer claims and all, and the log says how many claims replaced how many; a retry cut again keeps the first answer, as a retry with fewer claims always did, and the finding is recorded. The cap is the one in force: nothing raises it. A reference static analyst answered with 42 claims in exactly its 4,096 tokens, was asked fourteen questions over that answer, spent the whole cap again and returned no claim, and every question went unanswered.

An analyst answer that writes the same claims again and again is asked the same whole-answer question once. After an answer arrives its claims are counted (claim_headings.claim_blocks): each claim is its whole block — the sentence on its heading line and every line after it up to the next heading or a --- separator, blank lines aside — compared once marks, case, spacing and the claim's number are set aside, so a label-only heading is told apart by its fields and claims under one category label by their sentences; nothing under DISPUTES is counted. When the claims written again exceed a margin — the number of distinct claims, so a second whole copy is within it, or validation.claim_repeat_margin when an operator sets one (none by default) — isr.claims_repeated states the characters, the claims begun, the distinct claims and how many repeat, and asks for the whole answer again: the claims written before the repetition and any other the evidence supports, each written once. The answer is sent back as written up to the first claim that repeats an earlier one, also when it was cut as well; such an answer is asked this one question, with the output limit it stopped at stated in it, and not the cut question, whose words would say none of it is shown. The window rule of the cut question applies. Any whole answer that does not repeat stands, as a whole answer to the cut question does; a retry that repeats again, or is cut, keeps the answer as written and the finding is recorded, however many claims it began. A claim's block also ends at the first line that is not a field once its field lines have begun, so prose after the last claim is not counted as part of it. A chunk's answer is asked inside its chunk, as a cut one is. A local triage answer began 639 claims in 32,768 tokens, 85 of them distinct. Where the answer streams (llama.cpp, Ollama, and DeepSeek, which is read as a stream for this), the same rule is read at each line's end and ends the call once the margin is crossed (llm.stream_watch): the stream is closed and the answer is what was written up to there, which the check then asks about as above. The reader (agents.repeat_watch) gives the check's verdict for every prefix and keeps no text: a claim is kept as a 16-byte hash and a line is read by automata built from the heading patterns, so its memory grows only with the distinct claims. A tool-call tag or a JSON fence still open is read as kept, as the check keeps it, and cut back to the reading before it only if it resolves as removed.

Three more questions are asked of an analyst's answer in the same validation turn, each once, and what the analyst answers stands.

• Decompiled but not described (isr.decompiled_not_described).
  • What counts as decompiled. The functions come from the analyst's own ledger entries: a tool whose name says it decompiles, and a call that answered. A call whose answer the conversation had no room for is recorded as cut (truncated, its output a statement of the cut) and counts as no function read, here, in the function map and in "Functions examined".
  • Reading a batch. A batch answer is a JSON object every key of which is an address: 0x…, or at least four hex digits with a decimal digit among them (a hex word such as cafe is no address). It gives one function per key. A key whose listing begins with Error is left out. A cut answer is read member by member from its opening brace, and keeps the functions its text still shows. Any other answer is no batch, so a plain listing is one function at the address the call was given, whatever quoted strings it holds. A batch whose answer is not keyed takes the addresses in its functions argument.
  • Reading a single call. The address is the one the call was given, as hex or as an integer, or the one a decompiler's generic name carries (FUN_, fcn., sub_). The names are the one the call was given and the one the listing's signature prints. The signature is read line by line: a line holding only the return type is passed over, and comments are skipped.
  • Merging. A function asked for by name alone is the one asked for by address that carries the same name.
  • How a claim names a function. Its sentence or its evidence line writes the address as 0x…, as …h, as bare hex with a letter and a digit in it, or inside a generic name. The address must be the same, or differ by an image base the run read (image_base in the pack's answers, handed to every agent, or in the analyst's own). With no base known, a difference of a multiple of 64 KiB counts. A run of digits alone names a function only when it is exactly the function's own hex spelling, leading zeros aside.
  • Reading an image base. An unquoted number is the number. A quoted value is hex when it says so (0x…, …h) or holds a hex letter. A quoted string of decimal digits could be either, so it is no base, and neither is a value off a 64 KiB boundary. With no base known, the 64 KiB rule applies. A claim can also name the function by a name the decompiler gave it. Citing the entry alone does not count.
  • The question and the finding. The functions no claim names are listed in one question, with their names and entries. The question says what was read: a name the decompiler gave, or the address or its offset from the image base written in hex, and that an offset written in decimal digits alone is not read as one. The functions the kept answer still names in no claim are recorded, and §13's validation list prints the line naming them.
  • Why. A reverser had decompiled two routines holding half of what the analysis needed and described neither.
• Library-only claims (isr.library_only_claims).
  • What counts. A claim of one sentence whose subject (the sample, or none) uses, imports, calls or loads libraries or their APIs. It may add a short "for y" purpose: at most six words, with no comma, no second verb joined by "and" or "or", and no quote, digit, address, host or path.
  • What does not count. A claim whose object runs on with "to" states an action and is not one of these.
  • Other conditions. The claim names no code location in its sentence or its evidence line. Its evidence line carries nothing beyond an import listing: ledger ids, library and API names, counts, and the words that say what a listing is.
  • The question. It states what was read, not a judgement, and quotes every such claim. It asks to merge them into the claims whose behaviour they support, or to detail each.
  • What stands. The answer stands. A retry with fewer claims is kept when it has at least as many claims that are not library-only as the first answer had. One that keeps the library-only claims is kept, with the finding recorded.
  • Why. One analyst's answer was mostly such claims.
• A function claim its function's facts do not hold (isr.function_claim_unheld, pipeline/function_claims.py).
  • Which claims. A claim that cites the listing of a function the analyst's own calls decompiled (read as the decompiled-not-described question reads them) or disassembled whole. When the claim cites the listings of several functions, the ones its sentence names are taken, and with none named, all of them.
  • What a claim names. The Windows function names its sentence writes: an identifier the vendored export catalogue or this run's own facts know, written with a capital after its first letter, or alone in a code span (send, send()), so neither a word of running text nor a name inside a span's expression is read as one. An item of a slash list is read exactly as written: NtCreateFile/WriteFile names both, and in InternetOpenW/ConnectA only the first is a name. And the strings it quotes, in quotes or in a code span holding quotes, of three characters or more with a letter or a digit in them, read as claimed strings only when a strings source holds them as data: a strings tool's answer, FLOSS's, the blob decoder's, or the index's rows; a quoted phrase none holds (a capa rule's name, a paraphrase) is recorded as not checked. A name or a value inside a statement of absence ("does not use X", read by the absence question's own reader) is no claimed one. Nor is a name the sentence's grammar writes as a copy of the routine, in a closed set of forms: followed by -like, -style or -equivalent or by implementation, reimplementation, clone, replacement, equivalent or substitute, or preceded by reimplements or by implements its own / implements their own. Every other place is read as a call: a plain implements ("implements CreateProcessW-based spawning"), a name followed by -based, -driven or -backed, a copula or a likeness ("is a VirtualAlloc helper", "acts as a WinExec launcher", "is a hand-rolled atoi"), an article ("a ReadProcessMemory of its own PEB") and a name used as a verb ("memcpys each"). Each name is read once, at its first place it is claimed, and the absence reader reads only the sentence holding it. The model is asked to write nothing new; the claim format is unchanged.
  • Whose a value is. A value is the function's the claim names last before it in its own sentence (an abbreviation's dot, or a dot inside a token or a number, ends no sentence). When the claim names no function at all, every value is the cited function's. When it names one anywhere, a value its sentence gives no function is recorded as given to none, saying whether it comes before every function its sentence names or its sentence names none; a value given to a function the cited listings do not reach is recorded as given elsewhere.
  • Where a value holds. In this order: the listing's own text; the function's row in the pack's function index (its imports, its calls through slots the hash resolution fills, resolved names, decoded and plain strings and capa rules); the row of every function reachable from it through call edges, a breadth-first walk over the index's whole call graph with no depth bound, read once per listed function, a claim naming several holding a value when any one's reach holds it (routines passed as arguments, a thread's start or a callback, are no call edges and are not followed); and the places the run's hash-resolution and decoded-string answers put inside any of them. Nothing else excuses a value. API names are compared without regard to case, a module in front read off, the ANSI and wide spellings read as one name as the API catalogue compares them; strings by one whole-value reading in every source (whole_value_in): a value inside a listing's text, inside any decoded or plain string, capa rule or placed value of the reachable rows, or inside an index row's string (which makes it a sample string), held at its own boundaries, so a decoded command line holds the quoted group name it passes and a URL the host it names, and a value that is only part of a longer token is held by none. The run's texts are indexed once by their runs of letters and digits, and a value is read only in the texts holding its rarest run.
  • The question. One per claim block, naming every value held nowhere: "claim n names X for function F [ev_…]; neither its listing nor its index row [ev_…] holds X, and no function reachable from F through its call edges holds it (k functions reachable); routines passed as arguments (a thread's start, a callback) are not followed, only calls; F's row holds …", the row in the pack's own words, counted instead when those run past a finding row's bound. It asks to keep the claim and say where the code shows it, to correct the name or the function, or to withdraw the claim, with a reason.
  • What stands. A correction leaves no finding. A kept claim stays, with the finding recorded; §13 folds identical findings as it folds any. A retry with fewer claim blocks is kept by the count rule the library-only question already used: its blocks, less those any question asked about (library-only or function claims), are at least as many as the first answer's blocks less its asked ones. The rule counts blocks; it does not match them one by one, so a retry that withdraws an asked claim and rewrites another is judged by the count, as the library path always was. Withdrawn asked claims are not asked about again as dropped work. A question no time was left for is recorded as not asked. No claim is edited or dropped by the platform.
  • When the fact is absent. Nothing is stated, and the loop's record in the run summary (budget.<agent>.function_claims) gives each such claim or value with no: and why: the run holds no function index, or its answer was not kept whole; the index does not know the function; the pack the analyst was shown left the function's row out for room; the decoder stopped in a function reachable from it; a quoted value no strings source holds; the facts or the check failed (its exception's type). An API name is also not checked where a reachable function makes calls the index cannot name: a call through a slot the hash resolution fills is named, and only a call through a register no load names, an indirect jump, or a slot nothing names leaves the name unchecked, since such a call may be the one the claim names; nor where the index lists no callees for the functions that are no row. The record also counts the claims checked and asked about.
  • The judge. A kept finding is shown to the judge in the note that already carries the technique check's kept findings, under its own heading, as the facts alone, without the sentence asking the analyst to keep or withdraw; a finding never asked stands under a heading of its own that says so.
  • Cost. Linear in the claims, the index rows and the listings' size, and in the call graph once per listed function, whatever the number of claims: the rows are keyed by offset once, each listing and each row is read once, the names a sentence may name and the sample strings are gathered once per answer, each listed function's reach is walked once, and only a question counts the functions a claim's several functions reach together. A sentence's own reading is bounded per value: a dot's word is read back over the longest abbreviation at most, and a statement of absence over a name within the name's own clause: each clause's cues are found in one pass and the readings that reach back over the clause (a negated noun list, the ", such as" list a noun negation names, a negated verb's object) worked out once per cue, a name then read by its place against them and within the negation window around it, and a clause holding no word a statement of absence is read from read for no name in it. The total is linear in the text however many names one clause holds.
  • Why. A reverser's claims named calls and behaviours for functions whose listings do not make them, and nothing put the function's own facts beside them.

The cap the check reads is the one the call was built with. The container records it on the model it builds (context_window.record_built_cap), and the analysts' cut check, their spend-meter admissions and the judge's checks and timeouts all read it from there (built_output_cap); nothing derives it again after the build. Derived again, it was derived from whatever the window cache held by then, and after the cache's 900 seconds that was the documented fallback of 8,192 tokens while every call carried 32,768: an answer of about 8,600 tokens was told it was cut at 8,192, and one that filled the whole 32,768 was not told at all. Only a model the container did not build carries no record, and only then is the cap derived from settings.

A chunked analysis answers each chunk's cut inside that chunk, before the merge: the cut is taken as the chunk ends (in a finally, so a chunk that raises leaves none for the next), and that chunk's own answer is asked once for a whole shorter one over that chunk's own input, the question naming it ("Your answer to chunk 1 of 2 stopped at the output limit …"; a repeated-claims question names its chunk the same way). A chunk is named by its place in the list the analyst is handed, in its prompt header as in the question: chunks from several data sources each count within their own source, and two of them both read "1 of 1". What comes back stands for that chunk alone in the merge; the merged answer is never replaced by one retry. A chunk still cut after its question is kept as it was cut and recorded as unread for that chunk. Before, a cut in chunk 1 was overwritten by a short chunk 2 and never asked about.

A later chunk is told what the earlier chunks already called. Each chunk is a new conversation, so its prompt opens with the earlier chunks' tool calls, every one, as tool(args) → ev_id lines with the headline of what each returned, a failed call marked, and its loop's repeat guard is seeded with them (seeded_repeat_guard): an identical call is not run and is answered with the result that entry recorded, stamped with its id and a sentence saying it came from an earlier chunk (earlier_chunk_answer); an entry whose result the run did not keep whole (the byte budget blanked it) is served once more, as a failure is, and the block marks it so ("result not kept; may be made once more"). A recorded result that was shortened when first answered carries the same shortening notice. A reverser's second chunk, told only where the result was, asked 24 calls for 3 new entries and ended at its repeat stop. That first answer is not counted toward the loop's repeat stop, since the model has not been told in this conversation; asking again after it counts as any repeat does. A failed earlier call is served once more, as any retry after a failure is. A replayed conversation keeps the seeds. A run's second chunk re-ran ten decompiles the first had done.

The repeat stop is a stall limit, not a cap on tool use (RepeatGuard.ENDS_AT, 8). Only a refused call counts toward it: one whose tool and arguments, as the guard's key writes them (arguments in any order, an address in either case of its 0x spelling), are identical to a call already answered. A served second call never counts, and neither does a call that differs in any argument, a page (offset, limit) included. Each refusal names the ledger id that holds the answer and says how to read it again and page through it (read_evidence with that evidence_id, offset and limit), and the seventh says the next one ends the loop. Eight is a stall limit, not a measured optimum: no stored run has a single refusal by the guard, so none comes near it (the most calls one loop of a stored run had answered without a run was four, from earlier rounds, and a useful distinct call still followed the fourth), and it still ends both live loops the guard was written from (16 of 19 steps on one pe_info; 11 identical strings calls, nine of them refused with one served repeat). A call outside a tool loop that reads the ledger (ledger_reads) ends at the same count of refused reads.

Every call the repeat guard answers without running is filed in the ledger as a repeat of the entry that holds its answer (EvidenceRecorder.record_repeat): an earlier chunk's call answered from its entry, and a refused third identical call. The entry carries repeated_of, the note the model was handed in place of a result and a duration of 0 ms, and its tool_call_started and tool_call_finished events go out like any call's, the finish naming repeated_of. The model is never shown the repeat's own id: the answer it reads carries the earlier entry's, which is the one to cite. A repeat always names the entry that holds the answer, never another repeat (EvidenceRecorder.holder_of), and later identical calls are noted under that entry, so every served or refused answer names it too. The citation check (EntryTexts.from_ledger) and the judge's evidence (question_evidence) read a cited repeat as the entry that holds its answer. A repeat's note is not charged against the agent's byte budget (report.evidence_budget_bytes): it holds no new content, and charging it could blank a later answer. A repeat is counted apart in run_summary.evidence.repeats and in neither ok nor failed; the report header and §13's evidence bounds say how many calls were answered from an earlier entry, and Appendix A marks each such row "repeat of ev_…". No report section, decompiled-function list, function map, later chunk's block or seeded guard reads a repeat: each reads the entry it names. A reverser's second chunk once made nine calls, all answered this way, and left no entry and no event.

A call another guard answers with no tool run (an argument that names its own parameter, a call made after the conversation's room ran out) is filed the same way, as the guard's answer: the entry holds what the model was told, its repeated_of is its own id, so every reader above leaves it out and its chain holds no answer anyone can cite, and its start and finish events go out like any call's. It is a failure, since nothing answered, and never a tool failure. It is counted apart in run_summary.evidence.guard_answers; the report header and §13's evidence bounds say how many calls a guard answered with no tool run, Appendix A marks each such row "guard's answer, not run", and an agent whose only entries are these has gathered nothing.

A decompile is also a repeat when its answer is a function an earlier entry already holds, whatever address it was given: a call given an address inside a function is answered with the whole function. The function the answer prints (validation.listed_function: the start a decompiler's generic name carries, FUN_00401000 or fcn.00401000, else the printed name) only finds the candidate entries; it is text the sample can shape, a forged or a shared name, so the call is a repeat only when its listing is a candidate's listing, or that listing cut shorter (the guardrail's cut marker aside). Any other listing under the same name is a new entry kept whole. The tool has run by then, so the model is still handed the answer, stamped with the entry that holds the function and one sentence saying so (same_function_notice); the entry is filed as a repeat of it and keeps the note, not a second copy. An answer that shows more of the function than the entry holding it is new evidence and holds the function from then on. An earlier chunk's listing holds its function for a later chunk the same way. One r2 analyst decompiled a function at its start and again at an address inside it, and the ledger held the same listing twice as two different calls.

An analyst that has read a function sees its function map in the run-state block on every turn (agents.function_map). The platform keeps it from facts only, and the model does not write to it. It lists:

• every function the agent's own calls decompiled, or listed (a disassembly of a whole function, or one at a known function's address), with the entries that hold the listing;
• what the analysis server tied to the function: names its hashes resolve to, texts it refers to and the call sites they are passed to, strings FLOSS decoded in it. A place after a function start is not counted inside it;
• the first sentence of the first of the agent's parsed claims that names it.

Each artefact is counted once per function, as a distinct value. A text referred to from two places counts once. So does an answer that two entries recorded, and every entry that holds it is cited. A call-site fact is one text, argument position, call and callee, so one text passed to two calls is two facts. An offset and its virtual address are one function only through an image base the run read: exactly one of the two is below the base, and they are apart by it. Two virtual addresses a base apart stay two functions. With no base, both are kept as written. A claim gives a function its summary by an address that is the same function by that rule (with no base, the same address), by the function's own hex spelling written as digits alone, or by a name the decompiler gave it; a name that is an ordinary word (entry, start, or the last label of sym.entry) counts only written as code or beside a word such as "function" or "export". No address is guessed. A visited function with neither an artefact nor a summary appears on one "also visited" line, by address. Names other than a decompiler's generic FUN_, sub_ or fcn. name are kept beside it, such as an export name.

The block has no size limit, by the rule that no limit is set by default. It grows with the functions visited and, without a function index, the functions reaching artefacts; with an index, its not-visited line takes only the room the rest of the block leaves of what the loop derives for text arriving now (the window less the reply room and what the conversation holds, at the answer share), so it does not grow with the index. On a recorded run that decompiled 89 functions it was about 5 KB per turn.

A coverage line counts the functions visited against the functions reaching artefacts, and one line names those not yet visited. With a function index in the pack, the coverage line counts against the index's rows instead ("M functions hold artefacts in the function index (ev_…), K of them visited"), because the index places every artefact the run's answers and the decoder read, the decoder's own imports and plain strings included. A visited function counts when it is one of the rows by the map's own rule for an offset and its virtual address, the index's own image base among the bases. The not-visited line then reads the same source: the index's rows no visited function is, in the pack's rank order, each with its count of artefacts, as many as fit that room, then how many more there are and that the index is its entry, served by the analysis server's function_index tool. With no window measured there is no derived room, and the line states the count, the entry and the tool, and no rows. Without an index both lines are as before. The visited lines do not change. The sources are the agent's entries of the job, copied before the byte budget trims them, and the pack's artefacts, briefed by the node and handed on to an ask.

The report's "Functions examined" section carries the map's coverage in one line.

An analyst whose loop ended with nothing at all — no claim and no prose — is given a second loop over the same material only when what is left of its stage time, its loop budget less what the node has spent, holds one turn and a final answer at the pace its first loop measured, and the loop runs under that remainder rather than a fresh budget. It is the same ISR path as the first, so what it answers is parsed and validated like a first answer. When it does not fit, or ends empty too, the stage record's agent_reasons says so. The pace is the first loop's longest turn, and a second loop's first turn re-reads the framing and the pack cold, which on the slow run took 438–908 s: on such a model the measure can be short of what the second loop then needs, and the loop's own time cap and salvage are what hold it to the stage.

Agents and teamsCopy Anchor Link

Nine agent definitions ship built in. Five have a class behind them: the static, dynamic and network analysts, the judge and the reporter. Four are a prompt and a tool list and nothing else: the three generic agents — triage, android_static and reverser — that the mobile and deep_static teams are built from, and lead, whose role is lead and whose tools are the other analysts (see Delegation below). Each definition carries its role, whether it is enabled, the tools it may call, the data it reads and — for an analyst — the static provider it reads through. The judge and the reporter are not analysts: a team names them from its verdict and report stages, and no analysis stage may hold either.

What an agent is told about its toolsCopy Anchor Link

Every statement a prompt makes about tools is built from the list the request carries (agents.prompt_fragments.tools_statement): the families the tools come from — a registry server by its key, the team's ask_<agent> tools, the sandbox report's tools, the tools of the provider the role attaches itself — or, for an empty list, that there are none, followed by the workflow text each registry server whose tools are in the list declares (its prompt_fragment), or, for a server that declares none and offers a tool it declares nothing for, its own served MCP instructions and its tools' own descriptions, quoted as its data (prompt_fragments.undeclared_server_text). A static provider's fragment has two parts: its guidance about claims (what a claim cites, the ATT&CK focus, and the verification discipline with its confidence caps, which every static provider carries, whatever it is, in generic words with no named algorithm or technique id — Ghidra's keeps the wording, and examples, it has always had; a provider that writes its whole fragment itself gets the discipline after it), sent with every call on that provider, and the workflow its block declares, sent only when its tools are in the list; none says no disassembler or decompiler comes with the analyst, and a configured provider whose tools did not attach says so. A sandbox's own tool server is named by the sandbox's display name, and its workflow is the CAPE MCP block's declared text. Resolution builds the prompt for the list it resolved, describing a built-in role's own provider as expected; the analyst builds it again, through the same composition (composition.prompt_for), for the list each request carries — the tool loop's, or none for a revision, the validation turn or a synthesis. The final-answer nudge and the forced synthesis resend the loop's conversation with no tool callable, and their system turn says so. The list is the one the loop binds, without the sample-delivery tools, and the tools an in-process source attaches are marked with it (provider or sandbox report). An operator's prompt is kept as written and the sentence follows it. Nothing forces a call: an analyst that answers from the evidence it was handed is a recorded outcome.

A team (agents.profiles.<key>) is an ordered list of stages, which is how a human analysis team works: triage, then static, then dynamic if the sample is worth detonating, then reversing, then the network and threat-intel pass, then correlation, then the report. A stage says what it is (kind), who is in it (agents), what it runs after (depends_on), whether it runs at all (when), whether its members run at once or in turn (mode), what it is told about the stages before it (inject_upstream), how hard it argues if it is a debate (debate) and whether its agents keep the built-in tool servers (builtin_tools).

The five kinds are the pipeline itself. A triage stage names no agent: it is the pipeline running the deterministic tools over the sample and writing the results to the ledger (see The triage pack above). An analysis stage runs the agents it names. A debate stage runs the mediation loop over the analysis stages upstream of it. The one verdict stage runs the judge. The optional report stage, always last, builds the report.

The teams that shipCopy Anchor Link

Five teams are seeded, and every one of them is editable only in its debate options, its built-in tool switches and exclude_servers. The rest of a seeded team is a claim the product makes about how the analysis is arranged, so changing it means cloning the team.

default is the triage pack in front of the pipeline as four stages — triage_pack → analysis (static, dynamic, network) → debate → verdict → report — the four being the architecture this project measured itself on.

measurement is the same four without the pack, with every tool server withheld and the static provider forced to none: the baseline for what the ensemble contributes on its own, with nothing established for it. It is a team rather than three tool-free clones of the definitions, so the agents it measures cannot drift from the ones default runs.

mobile is a team for a mobile sample. After the pack, triage reads the facts it wrote and says which artefacts matter; android_static reads the manifest, the permissions, the components, the DEX strings and the native libraries, and runs only when the sample really is one — when: file_type in ("apk", "dex"); dynamic detonates when a sandbox report reached the run. On a PE the Android stage is still in the graph, still declines and still says why, so the console shows what the team chose not to do rather than nothing at all.

deep_static is a team that reads the code. The pack, triage, then the built-in static stage, then reversing — a generic reverser agent that is handed the static stage's findings and asked to confirm or refute each of them at function level, with the tools of whichever static provider is configured, and told to mark a finding unresolved when none of its tools decompiles — and then network, conditional on there being a capture or a sandbox report to read.

team_lead is a team led by one agent: the pack, then a lead stage whose only agent is lead, then the verdict and the report. The specialists — static, dynamic, network, reverser and triage — are the lead's tools rather than stages, so which of them work on a sample, in what order and how often is the lead's decision rather than a fixed sequence. Their tool calls are in the ledger under their own keys and their answers are in the transcript, addressed to the lead.

It is the one seeded team with no debate stage. A debate is agents arguing with each other, and this team has one analyst: the stage would hand the lead its own report, ask it to revise against nobody, and cost a second full loop — with the asks that loop makes — for a round that cannot change a position. The disagreement happens in the lead's own asks instead, where a specialist that contradicts it does so in the answer it reads.

The diagrams are generated from the seeded profiles by scripts/goldens/render_team_graphs.py, and tests/unit/scripts/test_render_team_graphs.py fails if the committed SVGs stop matching the teams, so a stage that moves cannot leave the page behind.

The three generic agents these teams are built from — triage, android_static and reverser — and the lead are seeded definitions like any other, with their prompts in src/maljan/agents/prompts/. A generic agent is a definition and a prompt and nothing else, which is what makes a team something an operator can write rather than something that needs a class.

DelegationCopy Anchor Link

An agent may ask another agent for work the way it calls a tool, because it is a tool. ToolRef(kind="agent", agent="static") on a definition puts ask_static in that agent's toolbox, with one required argument task and an optional context, described from the static analyst's label and role. Any analyst may carry such a reference — a lead that gives out work, a static clone that checks a point with the network analyst — and an agent with none cannot ask anyone, which is what keeps the default team's analysts what they were. The judge carries two in its seed, reverser and static: a mediation whose dispute turns on a function nobody read can ask the agent that reads code. Its ask_<agent> tools are built for the instance that holds them (the mediator and the verdict are two instances under the one judge key), the debate node hands the mediator the pack, the run state and the sample's paths an ask hands on (nodes.brief_the_mediator), and what the callee's checks said is written under judge as a lead's asks are under the lead. The answer reaches the mediator as the tool's result and the callee's calls reach the ledger; the mediator still decides. A caller that writes no report, like the judge, keeps none of the callee's findings, artifacts or open questions beside them, and the log says how many reached it only in the answer and the ledger.

Calling it runs the named agent under the same job: the same container, the same sample paths (its own provider's mirror first, as a stage agent gets), the same triage pack at the head of its first turn and the same run-state block at the end of each request's last message. The callee's human turn is the task, with the context after it and the claim format it answers in; it runs its own tool loop, its answer is parsed into claims and checked by the technique check in its own conversation, and the resulting ISR text — the claims with the ledger ids they cite — is the tool result, word for word. Nothing between the callee and the caller edits a claim, a confidence or a technique id (tests/unit/test_no_silent_overrides.py holds for agents/delegation.py like for everything else).

Everything the exchange did is in the machinery every other tool call is in. The callee's own calls are ledger entries under the callee's key, handed to the caller's buffer so the stage node that drains the caller writes them all. The ask itself is a ledger entry under the caller's key with server="team", tool="ask_<key>", the task and context as its arguments, the answer as its output and the callee's wall clock as its duration — so a report can cite the ask (ev_0012) or what the specialist looked at (ev_0009). The callee's turns carry a budget of their own (core.agents.delegation_steps, core.agents.delegation_timeout_seconds, both no limit unless an operator sets them): the caller's step budget is not spent by its specialists' work, only its wall clock is, and where the caller's loop has a time limit an ask is cut to the time the caller has left and refused when that is below what a first model turn needs. A caller with no time limit waits for a busy callee, unless that callee is itself waiting, directly or through others, on the caller. A callee that reaches its step cap writes up what it gathered, the way an analyst at its own cap does — and so, now, does a caller. A lead's report is the only channel its stage has, so a lead whose own loop ended without one used to take every answered ask down with it: one audited chunk spent 1,830 s, collected six answers and 52 ledger entries, and merged zero claims. The lead is given one bounded turn to write its report from the answers it already holds, and when that turn produces nothing either the specialists' own ISRs are promoted into the stage's merge, with their own claims and confidences untouched. Every answered ask is promoted, in the order it was asked: a lead asks the same specialist about the imports, then the strings, then the packer, and those are three answers, so the key carries the agent and the ask's number (deep_static#2) rather than the agent alone. Nothing is promoted beside a report that exists. Two agent_message events carry the exchange, each with stage, round and addressed_to: the caller's ask, addressed to the callee, and the callee's answer with its claims, addressed to the caller. The console draws the arrow live, and in the replay window the events are still in; agent_messages has no column for stage or addressed_to yet, so a transcript read after the events expire shows the lines without the arrow until the event model carries them.

What the callee's answer is checked against is the task plus what the callee's own tool calls returned, read from its ledger entries — which the ledger has already trimmed to its per-entry cap. A stage agent's answer is checked against its full data chunk, so with use_claim_consistency_gate on a delegated claim citing something past that cap is dropped where the same claim in a stage survives.

Four guards, each a tool error the model reads rather than a job failure. A callee that is not defined, or is disabled, is refused by name. An ask that would nest deeper than core.agents.delegation_depth (2: a stage's agent asking a specialist is depth 1, that specialist asking another is depth 2) is refused with the chain that reached it; the depth bounds the nesting, never how many times an agent may ask. An ask back up the chain — the callee asking its caller, or anyone already waiting on this answer — is refused as a cycle. And an ask that would come back with a server the asking stage withholds is refused naming the stage and the servers: a callee's effective tool set is everything it is bound to — the mcp references on its own definition and the servers whose agents list names it — narrowed by the tool policy of the stage doing the asking, so a stage with builtin_tools=False cannot reach knowledge or network through a colleague that no stage narrows, whichever way that colleague was bound to them. The settings model refuses the static cases at save time: a reference to an agent that does not exist, to the definition itself, to the judge or the reporter, or on the reporter. A judge row an earlier release stored with its former seed list (knowledge and reputation alone) reads as the seed (config.former_seed_tool_lists). The judge's asks follow the stage it asks from and the profile, never its verdict stage's tool policy, and a profile that withholds every server from the judge builds it no ask. The agents only the mediator may ask, in a team with a debate stage, get the sample mirrored and a roster line, but neither the job-start probe gate nor the provider readiness check refuses a job over them: a failed ask is a failed call on the ledger.

One agent does one thing at a time, on both sides. A caller's asks take its own lock, so two ask_* calls in one assistant turn — which langgraph gathers and runs at once — go one after the other rather than putting two nested loops on one llama-server slot. The judge's asks, as mediator or verdict, run at once where the asked agent's models serve concurrent requests (delegation.asks_run_at_once), read the way the job's analyst run mode is (see The pipeline): llm.parallel_analysts where an operator set it, else each provider's declared concurrency — a hosted API serves any number, a runtime taken to serve one request at a time keeps them serial, a local server serves as many as its /props slots — and only when the job's analysts run in parallel; never by a provider's name. An asked agent in no stage is read by the auto rule over its own models whatever the setting says, once per job. The ask tool tells a judge whose asks run at once so, and every other caller reads the sentence it always read. Each answer is its own call's tool result, in the order of the calls, and the asked agents' ledger entries are merged into the judge's in ledger-id order, never in the order the asks finished. A caller that merges answered asks into its own report (a lead) keeps them serial, since it promotes them in the order it asked. An ask of an agent, a second ask of it and its own stage run take its lock, because all three drive the same buffers and the same call chain. The two are different objects, which is what lets an ask made from inside an ask still nest. A caller waits for a busy callee only as long as it can still read an answer in, and one that does not free up in that time is a refusal like the others. An agent asked twice with the same task is served the second time and refused from the third on, by the same repeat guard every tool has.

The stage graphCopy Anchor Link

pipeline/builder.py turns a team into a LangGraph workflow and pipeline/topology.py names the nodes. An analysis stage contributes one node per agent, <agent>_analyst; a parallel one also contributes a barrier <stage>__join when its dependents start at more than one node. A debate stage contributes negotiation and revision, prefixed <stage>__ only when a team holds more than one debate. The verdict stage is judge and the report stage is report. A triage stage is one node named after the stage itself. Edges follow depends_on; a stage with no dependency starts at START, a stage nothing depends on ends at END, and a debate's way out is the router's conditional edge — with one rule on top: a triage stage that has no dependency is where the graph starts, and every other stage without a dependency follows it instead of START, so a team gains the pack by having the stage inserted and nothing else rewritten.

A node runs once, after every stage it depends on. In LangGraph, separate single-source edges into one node are separate triggers: the node runs in the superstep after any of them finishes. A stage that depends on two stages of unequal depth — detonation after static and reversing, network after all three — would run once per upstream stage, and everything after it again, up to two judges and a report sharing a superstep with the second one. So the builder enters a node with more than one upstream tail through one list edge, add_edge([tails], head), which is a barrier that waits for all of them. The debate's revision → negotiation loop edge and its router stay single-source, so a loop pass never waits for a tail that already ran. The router's edge is conditional and a barrier cannot wait on it: a debate whose next stage also depends on another stage leaves through its own <stage>__join, and that node is the tail the next stage joins. A stage whose condition declines still runs its node, so every barrier fills. tests/unit/pipeline/test_every_node_runs_once.py runs the compiled graph of every seeded team and the all-tools example with stub nodes and counts.

The default team therefore builds exactly the graph the project has always built, node for node and edge for edge — tests/fixtures/golden/graph_default.json pins it in both analyst modes.

A stage's condition never changes the graph. when is evaluated inside the stage's nodes at run time, so a stage that declines to run is still a node and still writes a StageResult saying it did not run and why. A topology that depended on the sample could not be drawn, compared or reasoned about before the sample arrived. What each stage did lands in state["stage_results"] and reaches the reader as run_summary.stages.

run_summary.elapsed_seconds is the whole run: the worker's own clock reaches the pipeline as state["run_started_at"], and the report node closes the figure when the report is composed, so it is the same span the job row's duration_seconds measures. The report prints the per-stage durations from run_summary.stages beside it — the list the console's stage headers are drawn from — so the two surfaces cannot disagree about where a run spent its time.

Each stage also announces itself live, once: stage_started from its first node, stage_skipped from that node instead when the condition is false, and stage_finished from the one node that runs after everything in it is done. That last node is usually the stage's own — a sequential chain's tail, a barrier, the judge, the report — and for the two shapes with no single terminal node of their own, a fan-out without a barrier and a debate that loops, it is the single node of the next stage. Nothing replays the events at the end, so a run with reporting disabled still terminates every stage it ran.

An agent whose stage was skipped reaches neither the debate nor the judge: both read the roster from stage_results rather than from the profile, so a stage the condition turned off does not arrive as three empty reports. A debate whose upstream analysis stages all skipped skips itself and says so.

A custom agent runs as a ConfigurableAnalyst with the tools its definition names. A team may not put one agent in two analysis stages — the node name is the agent's — may not name the judge or the reporter as an analyst, and may not name a disabled agent while it is the active team.

Built-in tool serversCopy Anchor Link

Every analysis capability the pipeline used to run in-process is also a tool an agent may call. Four stdio sidecars ship built in, each a single-file FastMCP server under services/, launched with the same interpreter the worker runs on and registered in _builtin_servers(). A fifth entry is registered there without being a process of this deployment at all: VirusTotal's own server, reached over HTTP and off until an operator registers an agent token.

The two tool sidecars carry agents: [] and are bound only by the ToolRefs in the agent definitions, so the definition's tool list is the single binding and a clone that drops a reference really loses those tools. Both bindings are composed the same way for every agent, under one collision rule that keeps the agent's own tool names bare: its static provider's and sandbox's tools first, then the built-in servers bound to its role, then the servers its definition references, and only then an operator's server bound to the role by agents. Where an operator's server offers a tool under a name one of those already holds, it is the operator's tool that is offered as <server>__<tool>, beside the agent's own, never in its place.

The implementations live in src/maljan/tools/ as plain functions — explicit arguments, JSON-serialisable returns, no Settings access — so the sidecar is a @mcp.tool() wrapper and nothing more, and the same code backs an in-process caller. Two rules hold across all of them: they report facts rather than verdicts (a packer section name is a match, not "packed"), and an optional dependency that is missing costs one tool's answer, never the server.

Each sidecar also answers capabilities: which of its tools need an optional library, a binary or a setting, and which of those are present on its host, probed when the server starts. The registry keeps the manifest on the server's entry when it attaches, the settings probe returns it so the console's server card names the unavailable tools before a run, and each tool the manifest marks unavailable is recorded as server.<key>.<tool>_unavailable(<reason>); <remedy>. A tool marked unavailable is also kept out of the list the model is given, because offering one is offering a step that can only fail — unless the manifest says what the tool still answers without its library, in which case it is offered and the reason says what is missing from its answer. A tool that cannot answer returns an error with a code and an authored remediation (maljan.tools.errors) rather than raising, and the sidecars' guards rewrite an implementation's flat error into that shape. See Writing a tool server in configuration.md.

The dynamic analyst's tools are the exception: its sandbox report is already in the worker's memory, so ToolRef(kind="sandbox") resolves to in-process tools over that report (src/maljan/providers/sandbox_tools.py) with no transport to open — the process tree, the network activity, the sandbox's own signatures, the files written, the registry keys touched, the API-call histogram, the mutexes held, the services and scheduled tasks arranged, the platform channels, and a bounded reader for any section the rest do not model.

A tool server reached over HTTP does not share the worker's filesystem, so it is handed the sample rather than a path to it; a stdio sidecar is handed the path. See the remote-delivery section of configuration.md.

The sample's path is not the model's to give. On the three built-in sidecars, an argument whose name means the file under analysis — path, file, file_path, binary, sample, target and the rest of tool_pinning.SAMPLE_ARG_NAMES — is taken out of the schema the model binds to and filled by pin_paths with the path that server can open. program is not a path argument on any server: a decompiler names a program in its project with it (Ghidra: "Program name (default: current program)"), so the name the model gives reaches the server as it was written. The sidecar's own signature is unchanged; only the model-facing copy is narrowed, and the platform's own calls still pass the argument. A qualified path argument — pcap_path for a capture, a rule file, a member inside an archive or an APK — names something other than the sample, which is a choice, and stays where it is. A server an operator added is theirs: this project does not narrow what its tools advertise.

The correction that preceded it is still there for those arguments, and it was never enough on its own: it recognises the spellings the model was shown and the sample's own basename under a directory that holds no such file, and a live static analyst typed a sample path with three characters missing from the sha256 in its name, which matches none of them. It then spent its whole step budget guessing directories — /, ., samples, staging, carved, uploads, private — and nineteen of that run's thirty-five tool calls failed. An argument the model cannot see is an argument it cannot mistype.

put_sample, put_sample_begin, put_sample_chunk and put_sample_finish are the platform's delivery primitive and never an analysis step, so they are not in the toolbox the model is shown. The same run called put_sample with {"sha256": "null", "content_b64": ""} and was told, correctly, that the empty string's digest is not the sample's.

A file an earlier call produced is still the model's to name. Hiding the sample's path would otherwise have taken the carved payloads with it: carve_payloads writes each embedded payload under the staging directory and returns the paths, and with path gone there was nothing left to pass one to. carved_path is the qualified argument that gives that back, on the fifteen analysis tools that read a file — identify_file, hashes, signing_info, strings, iocs_from_file, pe_info, elf_info, macho_info, apk_info, carve_payloads, archive_list, document_info, yara_scan, capa and floss. It is held to the carved tree of the file this call is pinned to, and that file itself — <staging>/job-<id>/carved/<the sample's sha256>/, which is exactly the key carve_payloads writes under and which the sidecar derives from the bytes it was handed. Not the staging base: a base-wide bound let a run read another run's payload and another run's upload. A sample is adversary-authored content this model reads, and it can carry another sample's digest in its own bytes beside one instruction to point a tool at it; samples are not only malware, either, since an operator submits a suspicious document that may hold somebody's data.

Staging is per job, and that is what makes the bound the directory rather than the tree. MALJAN_STAGING_DIR stays the operator's base; the process that spawns a sidecar composes one leaf inside it per job and passes it as MALJAN_STAGING_JOB, which the sidecar joins to the base itself — two variables, because child_env applies a server's own env map last and a composed path would either lose to the operator's value or overwrite it. The job's owner removes that directory on every way out of the run, and the TTL sweep prunes whatever a killed worker left. So put_sample uploads are not nameable across jobs either, and two runs of the same sample no longer share a tree.

Both spellings a model writes are understood — the absolute path carve_payloads returned, and the tail of it relative to this job's staging directory or to the tree — and whichever it is, the resolved path must land inside the tree or on the sample. Symlinks are followed on both sides first, so a link planted under staging and a climb out of it land where they really point and meet the existing remediation-bearing refusal. The value must resolve onto a regular file: a directory, a FIFO, a device or a socket is refused with its own sentence, because a reader that opened a FIFO with no writer would wait for one forever. Given, the file is read in place of the sample and the answer carries read_path saying which; left out, the sample is read.

A quoted search is the same search. A model writes a search the way a person types one, between quotes, and a quoted needle matches nothing the bare one would. Every argument a sidecar tool searches for or looks up by is read without the pair of ", ' or ` that encloses the whole value (the same character at both ends and nowhere between) — pattern on strings and floss; text, technique_id, ids, api_names and query on the knowledge lookups; ip_address, domain and file_hash on threatintel — by maljan.tools.arguments, with nothing else rewritten and a value without a surrounding pair passed through exactly. The repair is recorded the way carved_path's is: the ledger keeps the arguments as the model wrote them, and a structured answer carries read_as first, the value each argument was read as (a threatintel answer is prose and names the value it looked up). Each such tool's description says to give the argument the value itself, and that a value that is only the parameter's name is asked about, not run — so a search for that literal word cannot be made; it used to say "pass pattern as the raw text or pattern itself", and a static analyst sent "pattern": "\"pattern\"" twice. A call whose argument is nothing but its own parameter's name — bare, quoted or in a placeholder bracket — is not run and is filed as the guard's answer, which holds nothing to cite: the model is told which argument named its parameter and asked for the value it meant, the value is never rewritten, the question is counted under tool.argument_names_its_parameter in run_summary.validation.by_code, and asking the same again counts as a repeat. Content arguments — the text iocs_from_text and yara_scan scan, the command lines lolbin_lookup matches — are left as they arrive, because a command line can begin and end with a quote that belongs to it.

pin_paths needs no rule for it — a qualified name is not in SAMPLE_ARG_NAMES, which is what the naming rule was built for. A payload carved out of a carved payload nests under the sample's own tree rather than opening one of its own, so everything a run produces is the one tree it may read back and the one tree the staging sweep prunes — which it now does: the sweep deleted files and skipped directories, and everything carved lives a level down, so carved payloads never expired at all. No tool extracts an archive member anywhere today, so a member stays the business of the tools that already take a member name; when one does, it writes into the same tree and the same argument serves it.

ProvidersCopy Anchor Link

The provider layer (src/maljan/providers/) puts one interface in front of each class of external tool, so the choice is configuration rather than code.

• LLM — openai, anthropic, ollama, gemini. Each has its own credentials, endpoint and model names; only the selected provider is used. Separate model choices exist for the analysts and for the judge.
• Static — ghidra (Ghidra MCP), r2 (radare2 MCP), capa_yara, generic_mcp for a server of your own, and none.
• Sandbox — mock (the default), cape2, triage, upload for a report produced elsewhere, and rest, a mapping-driven adapter for a sandbox Malspark has never heard of.
• Tool servers (MCP) — additional servers declared in the settings store, each with the tools it is allowed to expose and the agents allowed to call it.

No sandbox observation where no sandbox ran. mock executes nothing: it returns a recorded fixture for a sample it has one for (marked recorded_fixture), and an empty stand-in marked synthetic for any other. The marks are the platform's (sandbox_document.PLATFORM_MARKS): only the mock's reader sets them (ReportReader.platform_marks), and at the intake of every report a provider hands the run, live or attached, a mark its reader did not set — a sandbox's own top-level synthetic or recorded_fixture key — is taken out with a warning, so a live report always reads as observed. pipeline.sandbox_status reads the run's report once — no report or a stand-in is not run, a fixture is recorded fixture, anything else is observed — and every reader says the same thing. Where no sandbox ran, the triage pack writes one sandbox_status entry with the sentence that says so ([ev_0010] sandbox: No sandbox ran for this sample: …) and none of the sandbox views, sigma_match_sandbox or lolbin_lookup, so a stand-in's empty sections are never rendered as "0 processes"; the in-process sandbox tools answer the stand-in with the same sentence; the dynamic and network analysts are skipped; the run carries the degradation reason no sandbox ran … (or, with no report at all, the reason it always had); run_summary.sandbox holds {status, statement} and the report's run summary prints it; and the entry becomes the report's Sandbox section, which the console files on the dynamic tab. A recorded fixture is said to be one — the same entry, then the sandbox views as before. A live sandbox's report is read as it always was.

Every provider that can be reached over the network has a probe behind a Test button in the console; see configuration.md.

Which agents open a static providerCopy Anchor Link

Two kinds, and only two (composition.reads_static_provider): the static role, whose class opens its provider when it runs, and a generic agent whose tool list holds a provider reference, whose provider is opened when it is resolved. Each reads its own provider — the team's forced one, else its definition's static_provider, else the global one — and the container keeps one provider object per id. Everything that depends on the provider follows the agent rather than core.static.provider: the worker mirrors the sample once per provider any such agent of the team (or any agent they or the mediator can ask) opens, so a reverser on Ghidra under another global provider has a path the Ghidra container can read; the open of the sample and the sink-reachability pre-pass (providers.base.prepare_sample) run for every such agent through its own provider object: the provider opens the sample where its session needs it (open_sample; Ghidra over http loads, switches and analyses it, radare2 opens its mirror), and a provider that reads a call graph (call_graph, in the neutral analysis.sink_reachability.CallGraph; Ghidra over http does) gets the ranked priority functions, followed by its own sentence on what to do with them (priority_follow_up), while one that reads none gets no hint; and submitting a job checks every such provider that does not degrade (A team that needs Ghidra waits for it in configuration.md). A provider that degrades and does not attach — an r2mcp that is nowhere to be found — lets the static analyst run without it, and the run summary names it as static provider '<id>' unavailable: … with the remedy.

When a provider failsCopy Anchor Link

A Ghidra that cannot open the job's sample. Before an agent on Ghidra over http starts its loop, the load of its sample is made once, and the sink pre-pass reads the program it opened. Ghidra answers a load it could not make with HTTP 200 and {"error": "File not found: ..."} — the path is one its container cannot see, most often a sample_mount set to a host directory — and every call after it answers "No program loaded". So a load that opens nothing raises SampleNotOpened with "Ghidra could not open the job's sample: <the server's words>; check core.static.ghidra.sample_mount / the container mount", before any model turn. The same holds inside a loop over stdio, or on a later load: the pinned load_program of the held path that answers with an error is filed on the ledger as a failed call with the server's words, and the exception ends the loop at once, with nothing salvaged from calls made against no program. The provider remembers the path, so no later loop of the job (another chunk, an ask) calls Ghidra for it. The stage records the agent as failed with the sentence, the run's degradation reasons name the analyst failure, and the rest of the team runs. An agent that asked the stopped one reads a failed ask and carries on. Any Ghidra reply of the shape {"error": ...}, a bare "No program loaded" answer and an HTTP error are failed calls on the ledger in the server's words.

A load that got no answer from Ghidra at all is a different failure and says so: "Ghidra at <scheme://host:port> did not answer the load of the job's sample (<the error or HTTP status>); check the Ghidra container is running at that address and core.static.ghidra.auth_token matches its GHIDRA_MCP_AUTH_TOKEN". A connection that failed is asked once more first; an HTTP error (a 5xx, a refused token) is not. Such a failure stops the agent the same way but is not remembered, so a Ghidra that comes back is asked again by the next loop. The failed ledger entry of a pinned load records the path the platform sent, not the one the model wrote. An agent stopped this way is recorded once, by its stage, with the reason "stopped: its static provider could not open the job's sample", and is left out of the debate's rounds.

Ghidra closes no program a load replaces, so each import past the first leaves one more copy of the program in the container's memory for the life of its process. The note below keeps that to at most one import per sample per job (none beyond the triage pass's when it ran).

A load imports the file afresh, in the place of any program of the same name, and an import is not analysed: its functions come from the file's tables and no call or code reference is recorded, so callers, callees and cross-references read empty for every function, which read as "nothing calls it". The stored runs show each load_program a model made replacing the program the triage pass had analysed. The fix is not Ghidra's: any server whose open resets its analysis declares, as data in its settings block (sample_open), which tool opens a sample and optionally which selects one already open and which runs its analysis, and the general opener (maljan.providers.sample_open) keeps a note per job and per server of each path opened. A later open of the same path, by a model, the load before the loop, the triage pass or the function-hash pass, is answered from the note after the declared select; a select the server refuses opens and analyses the path afresh. Ghidra's block ships declaring load_program, switch_program and run_analysis (A server whose open resets its analysis in configuration.md).

What stays in the Ghidra adapter is Ghidra's own transport and its own failures: the REST client (each tool is an endpoint, and the client makes a loaded program current, since Ghidra sets its current program only when none is), the path pin that replaces a model's path with the job's mirror (the mount Ghidra's container reads, kept even with no declaration), and the stop with a sentence naming that mount when the job's own sample does not open. Ghidra's answers are handed on as they came; the ledger entry beside an answer holds the arguments the call sent.

A model that fails as a provider. An agent's entry under llm.agents may name an ordered list of models (fallbacks), held as one model object (maljan.llm.fallback.FallbackChatModel). The next model is asked only when the one before failed as a provider — a refused or dropped connection, a timeout, an HTTP 5xx, 408 or 429, a model the server does not have, a refused credential, or a refusal the provider reports as an error. A timeout is real because every model on a list but the last has its own turn deadline: core.llm.fallback_turn_share (a half by default) of what is left, at that turn, of the budget the loop runs under — an ask's ceiling included, so an agent asked for help under a shorter clock gets a shorter deadline — never less than one second. Worked out per turn, so a model that stalls late in a loop is still replaced before the loop's clock cancels it. The reporter's list starts over twice per report stage, measured against the narrative round's 600 s and then against one composer section's core.reporting.composer_per_section_timeout. A model that stops answering raises inside the list rather than being cancelled with the whole loop (on the blocking path the abandoned call is left in a daemon thread, so it never holds up the process's exit); and every provider's client has a request timeout (1800 s, PROVIDER_REQUEST_TIMEOUT_SECONDS — Ollama's had none) until the model's pace is measured; then an OpenAI-compatible, Anthropic or Gemini request whose output cap takes longer at the measured pace carries that time as its own (generation_rate.with_sized_request_timeout; Gemini's fixed 90 s is gone). httpx reads a client's timeout as the longest silence, so it only ever ended an answer on a server that sends nothing until done. Malspark's own whole-call deadline starts from the same values; where nothing is measured it bounds only the silence before a call's first generated piece. A call whose pieces arrive is held to its output cap (or its window's room after the prompt) at the pace they show from the first to the last (generation_rate._CallDeadline), and that pace is recorded for the model if the call does not complete. A llama.cpp server's answer is read as a stream for this. A 429 or 503 that asks, in Retry-After (seconds or an HTTP date), for at most thirty seconds is waited out on the same model once before the list moves on. The switch is sticky for the loop: the model that took over answers the rest of that loop, so a stalled first model costs one turn deadline rather than one per turn, and the next loop (the next stage, the next chunk) starts at the first model again. Only the explicit cause chain of an exception is read, and an HTTP status only from the provider SDKs' own exception types. A turn a model answered is never moved: an answer the validation loop rejects goes back, with the feedback, to the model that wrote it, because asking another model would be the platform choosing a different answer (tests/unit/test_no_silent_overrides.py holds a case for exactly this). Every answer carries the model that gave it in response_metadata (maljan_model) and, when a fallback gave it, the reason in words (maljan_fallback) — on the turn the list moved, once per switch; that is what the ledger entry, the model_fallback event and the run summary read. Every model on the list passes the probe gate the first one does, and the context-window budget counts every model on every list — the smallest window governs.

What a run spent. Every model call's usage, as the provider reported it — prompt and completion tokens, and the cost an OpenAI-compatible router reports where it reports one — is added to the run's TokenLedger under the agent that made the call and the model that answered. Every path that asks a model records: an analyst's tool loop (including the turns of a loop its hard cap or a failure stopped), its revision rounds, a delegated ask, the forced synthesis and the final-answer nudge under the analyst; the mediator's fast path, tool loop, reasoning salvage and structured extraction, and the verdict with its retry, under judge (the mediator's against its own model, llm.agents.mediator or else the expert model); the narrative and every composer section, on the structured path as well as the manual one, under reporter; and the function summariser under summarizer, against its own model. A structured call asks for the raw turn beside the parsed answer, because the parser hides the usage. A call whose answer names no model is recorded under the model its caller was built on. run_summary.tokens holds the sums for the run and per agent, and run_summary.models the per-agent model count and the fallbacks with their reasons. A call whose provider reported no usage is counted as not reported: its tokens are not estimated, and a figure the report prints as a count is always a count a provider gave. Each such call is recorded by the agent that made it, the call it was (tool loop turn, verdict, mediation, report section, …) and the model that answered, in run_summary.tokens.unreported, and the token sentence names them beside the count. Two parts of a call are recorded where the provider reports them: the input read from its prompt cache (cached_input_tokens, from the client's cache_read or DeepSeek's prompt_cache_hit_tokens) and the output spent reasoning (reasoning_tokens). Each is part of the input or output count, not added to it, carries the number of calls that reported it, and is absent where no call did. There is no price table; a cost appears only where the provider reported one.

A tool server that keeps failing. Each tool server the job's registry attaches — the built-in sidecars and every operator-configured server — has one guard (maljan.providers.server_guard), shared by every handle the registry opens for it. The Ghidra static provider and the CAPE sandbox provider build their own toolkits outside the registry and are not guarded; bringing them under it is a recorded follow-up. core.mcp.breaker.failures_to_open calls in a row the server did not answer — a timeout, a refused connection, the server's process gone, or a call that did not finish within its caller's budget — rest the server for core.mcp.breaker.cooldown_seconds. A call made while it rests is not sent; the platform answers it with a tool error in the structured shape (maljan.tools.errors, code server_resting) naming the server, that it is resting and when it will be tried again. A timeout counts: every call is sent with a deadline — the larger of the tool's budget in the server's own capabilities manifest and the server's own budget (call_timeout_seconds on its block; for a block that declares none, every built-in, the longest budget configured, capa's, as before; or core.mcp.breaker.call_timeout_seconds for every server where set), plus thirty seconds — and a call still waiting when its caller's own budget runs out counts too. After the cooldown one call is let through, and a success ends the rest; that call's own failure is the only one that starts another rest, and only while the rest it was let through for is still on. A tool that answers with its own error — a bad argument, a missing file — has answered, and never counts. core.mcp.breaker.max_concurrent_calls caps how many calls one server has in flight for one job, so parallel analysts queue rather than pile onto one slow sidecar. Each rest is published as tool_server_rested and kept in run_summary.server_rests.

MemoryCopy Anchor Link

Past analyses and family fingerprints are vectorised and stored in Qdrant, and retrieved by similarity during a run (src/maljan/memory/). The collections, the neighbour count and the Qdrant endpoint are settings. The ATT&CK corpus and its embeddings are cached on disk; on the compose stack that cache is a named volume, because rebuilding it costs the judge node about a gigabyte of resident memory and a minute and a half on the first analysis.

One factory builds the store memory.backend selects (maljan.memory.store_factory.build_memory_store), and every caller uses it: the analysis container (the store a run writes its case to), the enrichment worker, the API's purge and its dry run, /health?deep=true, the function-hash attribution steps and the command line. No caller names a backend. Each backend implements the one MemoryStore interface — store, retrieve, count, clear, purge_low_quality (with dry_run=True counting what the same gate would remove), readiness(), function_hash_store() and close() — and says what it cannot do through it: the in-process backend's function_hash_store() answers None, and function-hash attribution is then left out the way it is for any backend that keeps no function hashes. A backend that derives from MemoryStoreDefaults gets those answers for what it does not implement; the factory refuses a store without the interface, naming what it lacks. The function-hash store is built once per backend and settings and handed out as a hold: a settings change builds a new one, and the one it replaces is closed only when the last holder lets go — the judge's hold ends with the job's corpus write, or at teardown for a job that never wrote — so a running job keeps reading and writing the store it started with.

memory.backend is the id of a registered backend: saving any other id is refused (a settings PATCH or import), while a stored id whose package was removed or failed to load still loads with the rest of the settings — the factory then reports that backend not configured or unavailable, with the reason, to every caller, /health says so, and a run goes on without long-term memory as it does when any store cannot be built. Each backend's own settings live under memory.<id>.* (memory.qdrant.url, memory.qdrant.collection, memory.qdrant.function_hash_collection, memory.qdrant.api_key); the console's memory guide asks for the keys under the selected backend's id and tests them with the probe those keys declare. A backend from an installed package registers through the maljan.memory_backends entry-point group — an entry point named after the backend id, naming a callable that calls register_memory_backend(id, builder, settings_model=..., annotations=...) — loaded once the plugin allow-list names it (memory:<id> in plugins.allowed; see the configuration guide's "Provider plugins"): by the analysis worker at start and as each job starts, by the enrichment worker before it builds the store, and by the API, off its event loop, for a save or import that writes its settings block, its connection test, and the purge and the deep health check while it is the selected backend; its settings model's leaves join the catalogue under memory.<id>. with the annotations it registered once the API has loaded it, and until then its stored rows are shown as stored. A backend may declare a short label the console shows beside its id (the in-process backend's is "in-process"); the catalogue serves the labels as choice_labels on memory.backend. A backend also says where its store is, for a run's disclosure block: in_process=True for one kept in the process (the built-in memory), or address_leaf for the leaf of memory.<id> that holds the store's address (url for the built-in qdrant); a backend that declares neither is one whose store the block says it cannot place. A plugin backend declares the same in its own register_memory_backend call, read once a process has loaded it. A plugin that fails to load is reported against its own id; a selected id whose installed plugin is not allowed, or failed, is reported unavailable with the reason, and an id nothing declares is not configured. The flat keys stored before the move (memory.qdrant_url and its siblings) are still read, through the one map of moved keys (settings_annotations.RENAMED_SETTINGS): revision 20261010000000 renames the stored rows, an older export or a settings PATCH naming an old key writes the new one, and an environment's flat values land under the backend.

The case a run adds to long-term memory, and the function hashes it files under the judge's family in the attribution corpus, are decided by the judge and written once, after the job is recorded as completed: the judge holds both on the container (pending_memory_case, pending_function_hashes), and the worker, once the completed row is committed and the completed event is published, calls MaljanApp.remember_the_run, as the command line does once its run returns. A job that fails after its judge — a later node, or the worker storing its report — leaves neither, so a verdict nobody kept does not reach the next run's few-shot prior block or its family matches. The judge builds the case from the techniques the analysts claimed, before the report decides which are published; the report node then hands it the published ids (long_term_memory.with_published_techniques, from report.ttp_mappings), so the case, §8, the export and mitre.json count one set. Its total_techniques, its corroborated_count (the kept ids more than one source named) and its search text (the claims' own words and only the kept ids, which a later run's attribution reads) follow. The thin-evidence gate — nothing corroborated and one technique at most — decides on the published set alone: the judge does not ask it of the claimed set when a report node follows (nodes.a_report_node_follows), and the report node drops a case thin in what was published. A run with no report node (reporting.enabled off, or a profile without a report stage) publishes the judge's bundle, so the judge moves the case to the technique ids of that bundle's attack-patterns (a reference to a tactic, group or software is none) and asks the gate of them (nodes.case_for_the_judge_alone); when the bundle cannot be read there is no published set, and the case keeps the claimed techniques and the log says so. The judge still skips a run with failed analysts or no negotiation round. An id the case leaves out of memory (a claim kept after the absence question, an id the catalogue lacks) stays out although the run published it. The judge's log line counts the claimed techniques and says so.

An earlier run on the same sample reaches a later run only as hypotheses. Every similarity read (the judge's prior cases, the report's similar samples, similar_cases, the function matches) leaves the sample's own case out; the case an earlier run stored for the same sha256 is read apart, by the sample's id and under the owner rule (long_term_memory.earlier_case, through a backend's optional case_of; the in-process and Qdrant backends offer it, and a backend without it shows no earlier run). Each analyst, the mediator and the judge are shown it once per job after the triage pack, under the heading "AN EARLIER RUN ON THIS SAMPLE: hypotheses, not evidence". The pack's room under its bound (reporting.upstream_findings_max_chars or the derived one) shrinks by the block, and the block itself is never cut, so a block longer than the bound leaves the two past it. It holds the day it was stored and the technique ids its case keeps, never its summary, whose evidence ids name the earlier run's ledger, and never its category, an earlier verdict's word no tool can check. The report writer is not shown it. It is no ledger entry, so it has no evidence id, no claim can cite it and it adds no source to any technique's corroboration row. The judge's bundle records what was shown (x_maljan_earlier_run, set by the platform on every bundle, never exported), as a fact that decides nothing: the capability matrix publishes by the same rules as without it, so a run publishes the same set whether or not an earlier run is recorded, and a run repeated on one sample does not alternate what it publishes. A recorded technique with no independent source in this run's corroboration row (a lookup, an external assessment or a citation placed nowhere is none; a row the record does not hold has none) carries the note "an earlier run on this sample also reported it; no source of this run stands behind it". A job with no earlier case, or whose store cannot be read, is briefed as before.

A job submitted with ignore_earlier_runs (the job option, or maljan analyze --ignore-earlier-runs) starts without any earlier run's memory of its sample: long_term_memory.earlier_case_of answers no case for it without asking the store, so no prompt carries the block and the bundle records no earlier run. The similarity reads are not affected, since they already leave the sample's own case out. Once the job completes, its own case is stored as any job's is (remember_the_run), and so replaces the case its owner held for the sample, as on every job: the switch decides what a job reads, never what it writes, and a later job that wants independence sets it too. Its run summary carries earlier_runs_ignored: true, absent on every other job, so a score can state that the run did not see an earlier one. Every benchmark run sets it (scripts/benchmark/jobs.py).

The switch leaves the similarity reads to the owner's whole memory, so run k of a benchmark series under one account still read, through the judge's similar cases, the attribution's similar samples and the function-hash families, what runs 1..k-1 stored for the other samples. A job submitted with isolated_memory has an owner of its own instead (long_term_memory.memory_owner_for): its creator's key with /job/ and the job's id after it, which the analysis worker hands the job's container and the enrichment of its report reads alike (app/worker/job_memory.py). Every reader is scoped by that owner under the owner rule, with no special case: recall, match_functions and earlier_case read only what the job wrote, which is nothing before it completes, and its own case and function hashes are filed under the job's key, so they never replace the owner's. Without the option the owner is the creator's key, byte for byte as before. A container given the switch without an owner (the command line's unscoped memory) does not record it, since that job reads the whole unscoped memory. Its run summary carries isolated_memory: true, absent on every other job, and the benchmark's score and gate count a run as independent only when its summary says both switches (or its score states a fresh account's memory). Every benchmark run sets it. A case corpus mined from the memory (scripts/knowledge/build_attck_case_kb.py, read by the knowledge server's similar_cases) is not owner-scoped: every job reads it, an isolated one included. It is built from the unscoped cases alone, so no case filed under an owner, an isolated job's among them, is ever copied into it.

Another run's ids never reach a run in its own form. Ledger ids (ev_0007) and sandbox item ids (net:4) are each run's own sequence numbers, so a past case's ev_0007 names a real entry of this run that says something else, and a judge that copied it would cite that entry with every id check passing. Wherever a stored case's text reaches a run (the judge's similar past cases, their summary, category and techniques, and the report's similar samples, their summary and category), long_term_memory.foreign_ids_written_out renames each entry id, in any case and at any boundary, to other-run-entry and each item id to other-run-item, before and after the quoting, so an id a written-out control character completes is renamed too, and again after any cut, which can end an item id where its text went on (net:44x cut to net:4). Neither form is read as an id by any reader, alone or beside the text around it. One pass, linear in the text; a case with no id is shown byte for byte as before.

A similar case of another sample decides nothing either. The judge is shown up to three of them as weighted priors, read once per job (long_term_memory.similar_cases, kept on the container by the sample's sha256, so every verdict prompt of the job shows the same cases; a read that fails is not kept). A technique such a case carried can reach the verdict, or an analyst claim the judge keeps, with no source of this run behind it, so the judge's bundle records which cases' techniques its verdict prompt carried (x_maljan_similar_cases, each case's sample id and technique ids, set by the platform on every bundle). Both this record and x_maljan_earlier_run name other runs' samples, so they are in no STIX export and not in the report's bundle (the judge's draft stored as the report's when no export was made is written without them, stix_models.JUDGE_ONLY_PROPERTIES); they are kept on the judge's stored bundle as the run's facts. A case the fitted prompt cut before its header and techniques lines (matched with its number in the block, so two cases with the same techniques are told apart) is not recorded, since the judge was shown none of its techniques. The capability matrix publishes by the same rules as without the record, so the published set and every row's reason not to publish are the same with and without the similar cases, and a run repeated across samples that are each other's similar cases does not alternate. A recorded technique with no independent source in this run's corroboration row carries the note "a similar case from another sample also reported it; no source of this run stands behind it", beside the earlier run's note when both apply. A stored run from before the record carries none and replays as before.

The run summary's stix_object_count is the exported bundle's object count once the report node has built the export, on the state's summary and on report.run_summary alike; the judge's own bundle size is kept as judge_stix_object_count. A run whose export was not built keeps the judge's count in both.

A cached vector records what produced it, and is reused only by the same thing. maljan.memory.embeddings has two backends — the sentence model and a bag-of-words projection it falls back to when the model cannot be loaded, on an air-gapped install or in a container that is briefly out of memory — and the fallback projects into the model's own 384 dimensions so the vector store's schema stays stable. Nothing else tells the two apart: the numbers are the same shape and the same width. So embeddings.active_backend is the one fact three decisions read. It is in the cache key, it is in the stored file's header, and a file whose backend is not the one in use is ignored with a line saying so — including every file written before the field existed, which is read as an unrecorded backend rather than as this one.

A run on the fallback writes nothing into that cache and deletes nothing from it. The cache is shared with every later process on the host, and a model that failed to load once is a condition of that run, not of the host: re-embedding costs the run that could not load the model, while a stored bag-of-words corpus costs every run after it and says nothing about itself. The stale-file sweep is held to the same rule — it removes what its own backend wrote and what predates the field, and leaves another backend's file where it is — so a fallback run cannot clear the model's cache on its way past.

Long-term memory is off while the embedding model cannot load: a Qdrant store stores no case and finds none, rather than mix bag-of-words vectors with the model's, and each job's memory is its owner's alone (long_term_memory.recall). On a server, memory stored before owner scoping is kept but is not read by owned jobs: it carries no owner, and no owner is chosen for it automatically. An admin who wants it kept for one user adopts it explicitly with POST /system/ltm/adopt ({"user_id": ...}, a bearer session only): every ownerless case and function hash is filed under that existing user, a second call finds none, an unknown user is refused, and the call leaves an ltm.adopt audit row naming the actor, the owner and the counts (adopted, dropped, skipped; outcome=failed with the counts so far if it stops part way). Where the user already holds the same case the newer copy by created_at is kept, and a sample's function hashes are kept from one side only. Run it while no jobs are running.

Memory filed under an owner key nothing reads again (a job's own key below its account's, <account>/job/<job id>) is removed with POST /system/ltm/purge-owners ({"owner_prefix": ..., "dry_run": ...}, a bearer-session admin only): every case and function hash filed under an owner at or below the prefix goes, from the in-memory store, from Qdrant and from the function-hash collection beside it, and the answer gives the counts per kind; a dry run counts and removes nothing. The prefix is read a path segment at a time (long_term_memory.owner_under): <uid>/job names that path and everything below it, <uid>/job/ (a trailing separator) only what is strictly below, and neither names <uid> itself, <uid>/jobs, another account whose id begins with the same characters, or an unscoped entry; an account id written in upper case is read as it is filed. A prefix of one segment is a whole account and is refused unless whole_account: true is sent. A prefix that names no owner path, a backend that cannot purge by owner, and a purge that matches nothing (a mistyped prefix) are refused. The call leaves an ltm.purge audit row with the prefix and each kind's count, or outcome=failed with the error class and what each kind had lost.

The evidence ledgerCopy Anchor Link

Every tool call an analysis makes is written down as it happens. The tool loop wraps each tool, times the call, records the arguments, the outcome and the result — parsed when the tool answered JSON — and hands the answer back to the model with the entry's id stamped on the front:

[ev_0007]
{"machine": 332, "sections": [...], "imports": [...]}

The entry holds the answer the model was handed, whole — a second cut here would make the stored record smaller than the thing the citation points at, and the one bound on it is the per-agent byte budget, which keeps the call, drops the output, flags the entry truncated and is counted.

Ids (ev_0007) are monotonic across the whole job. The triage pack's calls are the first entries of every run that has one, under agent="pipeline", and the judge's own calls — threat intel on a disputed indicator, a knowledge lookup, an ask of the reverser — go through the same recorder under agent="judge", so a verdict that leans on one can cite it. An agent's ask of another agent is an entry under server="team", tool="ask_<key>", and the calls the asked agent made are entries under its own key (see Delegation).

Each entry names the model whose turn asked for the call (model, as provider/model with the endpoint as its scheme and host): an agent may fall back to another model mid-loop, so which model a call came from is a fact of the turn and not of the agent's settings. A row written before the column existed names none.

A call that failed is an entry with ok false whichever way it failed: a tool that raised, and a tool that returned an error. The entry keeps the message in error and, when the tool authored one, the remedy in remediation; run_summary.evidence.failures lists each distinct failure once with its count and the report header prints that list. The console does not read that summary — its evidence row shows the message and the remedy under the call itself, from the ledger entry.

The tool loop also meters itself. budget_tick events carry an agent's steps against its cap and seconds against its limit every five steps and at the end of each loop, with its prompt characters and tool_definition_chars, what the loop's tool definitions weigh with every request (the context budget counts them beside the conversation); stage_ended_at_cap says which cap ended the work when one did (steps, time, repeats, no_room, spend — the operator's spend ceiling — or the triage pack's budget_seconds); and run_summary.budget sums the spend per agent, with the caps it hit and the largest tool_definition_chars of its loops, so a reader learns that an analyst ran out of steps from the summary and the pipeline panel rather than from a log line. No loop has a step or time cap unless an operator sets one: the defaults are None end to end (loop_limits, LoopBudget, langgraph's recursion limit, the hard cap, an ask's ceiling), and a loop with none ends by its model answering, by the repeat guard, by its conversation's room or by the job's spend ceiling (core.spend.SpendMeter, priced from each call's reported usage), with the arq job timeout as the last resort. Its run-state block says "no step limit" and "no time limit" in words. Where an operator did set a time limit, the time cap ends a tool phase the way the step cap and a full window do: with the salvage writing the answer from what was gathered. The spend ceiling ends it the same way, for every running loop at once; a loop that starts after it answers once without tools, and the verdict and the report still run. It has to end early to do that, because the thirty seconds of grace past the budget are a fraction of one turn of a slow model. So the loop times its own turns — from one model answer to the next, the tools it asked for included — per answering model, and leaves out the turn on which a model list switched, which holds the dead model's deadline and not the new model's pace. Once the time left cannot hold the longest turn plus a reserve for the final answer, it stops calling tools and salvages. The reserve is 1.5 (the margin the per-call timeouts use) times the larger of the longest turn and, where the model's generation rate is measured, a 1,000-token answer at that rate — the size of the slow run's own final-answer calls, 222 s and 158 s at 3.8 tokens a second — and at least the salvage's 60 s floor. On a model at about 100 s a turn with one 240 s turn and a measured 3.8 tokens a second, 1,000 / 3.8 ≈ 263 s is the larger, the reserve is about 395 s, and the tool phase ends once under 635 s of a 1,500 s budget are left. The turn the clock ended holds calls that never ran; they are taken off it, its text kept and the record saying so, because a hosted provider refuses a transcript with an unanswered call. A model list's turn deadline is held at the reserve for the final-answer turn, and the answer asked for after it gets only the time that turn left. A turn longer than any measured can still reach the budget itself; the loop then keeps what it gathered instead of aborting the analyst, and the salvage gets what time is left. Either way the cap is recorded as time; a budget that runs out with nothing gathered says so rather than naming the hard cap. The hard cap stays the hard cap. The salvage is sized to finish in the time it is given. It re-sends the conversation without the loop's tools, so the server reads all of it again before it writes the answer. Where both of the model's rates are measured — the generation rate, and the prompt reading rate from Ollama's prompt_eval_count/prompt_eval_duration or llama.cpp's timings.prompt_n/prompt_ms, both under run_summary.generation — the request holds what the time left can read once a 1,000-token answer has been written, with the same 1.5 margin: 393 s left at 150 tokens/s read and 5.5 written hold about 35,000 characters, where the slow run re-sent 50,000 and ran into its hard cap on every PE sample. The task and the pack are always kept and the oldest tool calls go first; when not even the task can be read and answered in the time left, the salvage is not sent. It never exceeds what the window allows either, and where a rate is unmeasured the window alone bounds it. The call is the model's own async one, so its timeout cancels the request instead of leaving the server generating into the next loop's first turn. What each salvage sent, how it was sized and how it ended is on the loop's budget record and in run_summary.budget.<agent>.salvages. That stamp is what makes a report checkable: the model can cite the call it read a fact from, a report section lists the entries it was built from, and GET /api/v1/jobs/{id}/evidence serves those entries back. Every id the job's counter issued reaches that ledger: whatever no stage node drained — an analyst asked at the verdict stage, a revision that raised, a mediation loop's late calls, a delegation answered after its caller's loop ended, a triage pack stopped on its thread — is collected from the container's holders (ServiceContainer.collect_undrained_evidence) by the report node, and again by the worker before a completed, stopped or failed-after-report run stores its ledger. The rows are written in seq order.

How wide the prompt allows. What "too wide" means is not a constant. preprocessing.max_tool_output_chars is 0 by default, and 0 means the limit is worked out at the moment of each call from the context window the served model was found to have, less what the conversation already holds and the room kept back for the model's own reply, converted at a measured three characters per token and multiplied by the eighth of what is free that one answer may take. A positive value is an operator's own cap and is used unchanged. The limit never exceeds the room that is really left: a floor of 2,000 characters applies while the room affords it, and when what is left cannot hold an answer at all the model is handed no answer and one sentence saying the conversation has no room left — a deterministic fact, with the whole answer still on the evidence ledger under the call's id. The window is learned free of charge from the server's own metadata endpoint or from a vendored table — never from a generation call — and where nothing answered, nothing is derived: the documented 6,000-character cap applies and every surface says the window is unknown. run_summary.truncation records which of the four applied and the smallest and largest cap the run used. The whole arithmetic and the probe are maljan.llm.context_window; the job's budget travels with every attach the way the truncation ledger does, the run-state refresher tells it what the loop's conversation weighs before every model turn, and what it hands out is charged as it goes so a turn that calls several tools spends one turn's room between them. See Configuration for the numbers.

Old answers cleared when the window refuses, or past a price tier. A tool loop sends its whole conversation on every turn, so what the caps above bound is each answer, not what the loop reads again. Three things clear the oldest tool answers, each replaced by one line naming the evidence id the recorder stamped on it and how to read it again — the first two only where the request would otherwise end the loop, the third only where it loses nothing and saves money:

• A refusal. When the provider refuses a request as over its window (the same errors the window_full ending reads), one batch is cleared and the turn is sent again — again only while each resend is refused and something is still clearable. Otherwise the loop ends as it did before: with what it gathered, or by failing its agent where nothing had answered. A loop that ends at no_room ends the same way.
• A prompt past the agent's own window. A request whose prompt alone is past the window the agent's own model serves (its built window, else its assignment's — never the job's smallest) is refused by every server, so it is cleared before it is sent. A prompt between the window less the output cap and the window is sent as before.
• A prompt past the agent's model's price tier. Where the agent's own model is priced by its prompt's length (its price row's tiers, read from the operator's llm.model_prices, else the vendored table: Claude Haiku 5.5 bills every token of a prompt over 100,000 tokens at five times the rate) and the request is past the first boundary, the oldest answers whose evidence id one of the model's own turns has already written in its text are cleared — never one it has not cited yet (an id named only in a call's arguments or in its reasoning is no citation), so no fact it has not used leaves the conversation. The clear is made only where what no tier clear can take (the above, plus every answer not cited yet) is already under the boundary — a clear that cannot bring the request under it would give up the cached prefix and keep the dearer price — and where the request it sends, written to the cache whole, costs less at the model's prices than the one it replaces with its cached prefix, the turn's answer priced at this loop's mean and every write priced for an hour where the model's cache entries live that long (tool_answer_clearing.tier_clear_pays). A model priced by no prompt length is never cleared for it. On the stored haiku5 run no loop met both conditions at either cache lifetime — the reverser's first request alone was 131,680 tokens, and the other loops that crossed the boundary had cited too little of what they read — so that run is sent as it was.

A clear takes the oldest answers until the request weighs what no clear can take (the framing, the pack, the definitions, the agent's own turns and reasoning, its newest answers) plus half of the room between that and the point — the refused request, the window or the tier's boundary — so the loop has room to go on. A cleared answer stays cleared under the same line on every later turn. Never cleared: the newest turn's answers, an answer without the recorder's stamp, the system prompt, the task and its pack, the run-state block, the agent's own turns and the reasoning a provider requires back on them (DeepSeek's reasoning_content). There is no setting to clear earlier: priced on run 7's reverser, clearing a loop that would have gone on cost more than it saved on Claude Haiku 5.5 and on DeepSeek, because the first clear changes the tool list and the provider reads that whole request again uncached.

read_evidence answers an id with the output the ledger keeps for it, sized by the job's guardrail. It is filed as a repeat of that entry and shown under its id, so the ledger, the byte budget and the run's corpus hold the answer once and no second citable id exists. With an optional offset (a byte position) or limit (bytes) it reads the answer page by page instead: from the full copy of a cut answer the job's store holds, else from the stored answer, each page opening with a line naming its bytes, its copy and where the next page starts. A call with neither is the read above, and a page's text reaches the run's corpus under its own key. Before the request that carries a loop's first clear the tool is nowhere — not in the loop's graph, the request or the no-tool-call question — so a loop that never clears sends what it always sent; the graph is built again with it before that request. On a prefix-bound Claude model that change of tool list makes every earlier thinking block stale, and the provider's recovery drops them. The nudge and the salvage after the loop send the cleared answers as the loop last sent them and bind the tools the loop last offered. Each clear is in the agent's log and is published as tool_answers_cleared (agent, turn, answers, characters before and after, and refused, window or tier). The judge's tool loop clears the same way, with the same read_evidence tool, which it offers from its first turn. The code is maljan.agents.tool_answer_clearing.

The calls outside a tool loop read the ledger too. The judge's verdict and its technique question, the mediation's block question, the report composer's sections, the narrative, the report's question round (and a follow-up question asked of a finished run, over its stored ledger) and its section agreement round each offer read_evidence from their first turn, with the same definition, beside the answer's schema where the call is structured; the technique question's system text says the tool is there. On OpenAI and Gemini a structured call that offers the read is sent as function calling (the schema's tool and the read, bound together), where the call without it uses the provider's own structured-output method; the schema tool's answer is parsed as that provider's function-calling structured output parses it. A read is answered from the run's ledger by id, fenced under the id of the entry that holds the answer (a repeat's id reads its holder), sized by the job's guardrail; an answer the byte budget blanked is read from the job's store of whole answers, and offset/limit page through it. A reply that reads is answered and the conversation sent again, each turn admitted, held and recorded as the call's own, until a reply makes no read: that reply is the call's answer, parsed, retried and published exactly as before; a reply that calls the schema's tool beside a read (its arguments parsed or not) is the answer too, kept without its reads, so the schema's call is the one parsed, salvaged and answered by a retry; a reply whose only read did not parse is its text alone. A read of an entry the platform cut states the cut under it, as an analyst's read-again does. An id the ledger does not hold is said to be none the run's ledger holds. Nothing caps the reads; an identical read is served twice (the second, of an entry that recorded a failure, with the notice the analysts' read-again gives then), refused after that, and three refusals end the call with the reply kept without its calls. A dropped socket sends the call again from its first turn, under that turn's admission, and the reads made before it stay counted. The one limit is physical: a call's wall clock (the verdict's and the technique question's wait sized from the model's pace for one answer, where one is set) covers all its turns, reads included, and a call that reads past it ends as a call that ran past it always did. A read is filed nowhere: the entry it reads is already on the ledger, and the report is built over a fixed one. The reads are counted instead, in run_summary.efficiency.ledger_reads (reads by call, the ones that named no entry, the repeats refused; reads: 0 where a model bound the read and made none), and the efficiency block says so in a line of its own. A model that cannot bind the tool is asked in the call it always was, with no tool, and the run's degradation reasons say so once per agent. The reporter's calls share one definition, so the composer's shared header and the prefix its sections read from the cache are unchanged; priced offline on haiku7's 25 such requests with no read made, the definitions add about 0.003 USD to the run. The code is maljan.agents.ledger_reads.

The mediator's own loop reads the run's ledger the same way: the debate node hands each round the ledger, and the loop's read_evidence reads an entry any agent filed by its id (a repeat's id its holder, paged as above), not only the loop's own. Such a read is filed on the judge's ledger as a repeat of the entry it reads, as a read of the loop's own entry is, so no second citable id exists.

An answer wider than the prompt allows. Before any of that, a tool result over that limit meets the output guardrail, which now has three outcomes rather than two. A JSON object is shortened as a document: elements come off the end of its largest lists, then characters off the end of its largest long strings, until it fits. No key is ever dropped, the answer's own truncated flag is set, and one reserved top-level key — shortened — maps each shortened value's path to what was kept and what was left out, so a count can be reconciled without reading it against one of the tool's own numbers that means something else. Nothing else is written into the tool's vocabulary. Anything that is not a JSON object — a decompilation, any plain text — goes to the FunctionSummarizer when preprocessing.use_function_summarizer is on and to the character cut otherwise, exactly as before. A summary that ended at its output limit, by the analysts' rule, begins with a note saying its end is missing, and the cut is recorded with the run's shortened inputs, in one sentence per output limit that counts the summaries cut at it.

The shortening runs before the summariser, and for a JSON object it is the better of the two: the summariser answers in English prose, and prose is what leaves the record with no structured at all — which is the defect the shortening exists to remove. For the decompilation the summariser was written for, which arrives as plain text, nothing changed. Deciding what to drop is arithmetic over sizes measured in one walk, it runs on a thread rather than the event loop, and a monotonic wall backstops it; a document the shortening cannot help (its keys alone over the limit) is recognised by one subtraction and takes the character cut at once. Two things bound it: a size ceiling, because the wall cannot pre-empt the one parse everything depends on, and past the parse a monotonic wall checked at every phase. An answer this system has already shortened is not shortened again — a second map would count against a baseline the first one moved. run_summary.truncation counts the three outcomes apart, and the wall firing among them — on the job's one truncation ledger, which the server registry puts on every toolkit it opens, so a bound a tool server's answer hit is counted where the run summary reads.

What the model is told about it. A shortened answer carries one sentence for the model: the key the arithmetic is under, that an identical call returns the identical shortened answer, and this tool's own arguments that reach what was left out — limit, offset and pattern for strings, nothing at all for a tool that offers no such argument, which the sentence then says. The arguments are read off the schema the tool offered (agents.output_shortening.narrowing_arguments), never guessed per tool, and the same list is what the repeat notices name, so one tool has one answer to "ask it differently" however the model arrives at the question. Nothing re-issues a call and nothing edits an argument: the text is the model's to act on.

A parameter name is a tool server's own text on its way into the model's context, so only a plain identifier of at most forty characters is ever named, at most six of them, in schema order; anything else is left out rather than escaped or trimmed, because a name this refuses is one the model could not pass anyway. That bound is also what makes the sentence priceable: both guardrails — the MCP toolkits' and the Ghidra HTTP client's — shorten to output_shortening.shorten_target(limit, narrowing), one function, so an answer and the notice appended to it are together inside the limit the operator set. The room the sentence may take is capped at MAX_SENTENCE_ROOM, the exact width of the widest sentence those bounds allow, so a server declaring two hundred long parameters cannot shrink the budget its own answer is shortened into. An answer no guardrail saw — an in-process tool's — is not shortened at all and carries no notice.

How complete an answer is. A page of rows read as the whole is how a short or empty page becomes "none". Every tool answer the recorder hands a model carries one more line, of fixed platform wording beginning Completeness:, when the answer is known to be partial, and nothing when it is not or when that cannot be read (schemas.answer_completeness). The rule is the coverage record's: never say "partial" about a complete answer, and where the structure cannot bind a number to a list, say nothing.

Paging words are read in the answer's paged mappings: its top level, and any mapping that holds a list and is not itself inside a list (a row is data, never a page), each together with its list-free mapping children, where an answer keeps its paging block whatever it calls it (meta, links, pageInfo). A flag is read in any mapping. The line is built only from:

• the answer's explicit words, from one generic list: a true flag (truncated, more, has_more, hasNextPage, IsTruncated, matched ignoring case and underscores); a given next field (next, cursor, <part>_next_offset, or a next… name ending in offset, cursor, page, token, url, link or marker: nextCursor, next_page_token, NextContinuationToken). A paged mapping that carries any of these has said whether it is complete, so a total of runs scanned beside a filtered last page is not read as a missing page;
• counts the structure binds to a list: total when the mapping holds exactly one list, total_<name> or <name>_total for the list <name>, a totals entry for the list of its name. A total beside several lists binds to none and says nothing. A bound count is partial only when no placing of the page makes it the last: the page starts at the answer's own offset field, else the call's offset argument, else page N times its size counted from 0 or 1, else 0. A last page (offset plus rows shown reaching the count) gets no line;
• page fields: page N of M only when it is before the last whichever way pages are counted (page 0 of 1 is complete), and a page number with no count, no bound count and no explicit word, the one case "unknown" is said;
• the call's declared paging arguments: a call that passed a bounding argument of its tool's schema (limit, k, max_…, …_limit, page_size: output_shortening.bounding_arguments) and got back a primary list (the answer itself, or the top level's only list) exactly that long, with no explicit word, bound count or page field at the top level, is told it holds as many rows as that argument allowed;
• the platform's own cut: the characters the guardrail left out (chars_dropped), whether it cut the text, summarised it or left it out. A JSON answer shortened as a document carries the sentence above: the cut is not stated twice, and its counts and top-level truncated are not read, since the shortening may have made them. Where the job keeps a store the whole answer is kept beside the entry, and the line does not say so: what the model reads never depends on whether the job has a store.

A count, page, offset or size whose digits outnumber the characters of the answer's own text cannot have come from it: the shape reads as unknown and no structural clause is written. The line is therefore fixed wording, a handful of names of at most forty characters (anything but a plain identifier is written a field, and a name is written escaped), and numbers no longer than the answer; no value the tool sent is quoted.

Every line ends with "Anything not shown here is unknown, not absent" and how to read further. Only the paging arguments of the tool that made the answer are named (output_shortening.paging_arguments: offset, limit, cursor, page, k and their declared forms, never a filter such as pattern or query), and only where what is partial is the top level they page; a partial part further down is "no argument of this tool pages that part". A read_evidence answer names the paging arguments of the tool whose answer it reads, not its own.

Both guardrails keep the line's room back: beside a text cut or a summary (answer_completeness.cut_line_room) and from a shortening's target (answer_completeness.shortened_line_room, read off the original, which the shortening leaves every paging word of), so a cut answer and its line together stay inside the limit, while some of the answer still fits beside the line: a limit too small for both keeps the answer's place as it always did. The guardrail says which on the call (context_window.note_answer_line_room), and any line whose room was not kept back is charged to the agent's conversation. The line appears under a call's own answer, under a decompile answered with a function an earlier entry holds, under a read_evidence answer (with the cut the held entry recorded, or the read's own if larger) and under an earlier chunk's or round's recorded result (with the cut its first showing stated); never in the ledger, which keeps what the tool said, and never in a system prompt.

The coverage record reads the same answers with the same reading (read_answer(...).capped, platform_cut): a call is capped exactly where the line speaks of its structure, a complete total caps nothing, and an answer with a malformed number reads as of no readable shape.

The sentence a reader sees is drawn above the section's table, not as a row in it: the bookkeeping is this system's account of its own handling, and a key-value table is a table of facts about the sample. The map's every path resolves in the answer that carries it, and for each one what it says was kept is what is there.

Two bounds keep the ledger from becoming the thing it records. Each output is trimmed on the way in, and each agent gets a byte budget (report.evidence_budget_bytes); past the budget an entry keeps its arguments, its outcome and its timing and drops its output, and the count of what was dropped reaches the run summary. The ledger lands in the pipeline state as an append-only list and is persisted with the report, in the same transaction.

An entry that lost its output that way says so with truncated, and the column is the only thing that says it: a call that failed carries an empty output too, so a reader inferring the trim from the emptiness explains a failure with a cause that did not happen. truncated is persisted alongside repeated_of (the earlier identical call a repeat was answered from), symbol and started_at, and the evidence endpoint returns all four.

An answer the tool-output guardrail cut, shortened or summarised to fit is truncated too, and carries chars_dropped, the characters it lost: the guardrail tells the call it is answering (context_window.note_answer_cut), and the entry keeps exactly what the model read. A compact form, which loses no value, is not a cut. run_summary.evidence counts such entries apart from the budget's trims (cut, chars_dropped), and §13's evidence bounds say "N cut by the tool-output guardrail (X characters dropped)"; a summary written before the count reads the guardrail's own count from run_summary.truncation. A cut entry still holds its answer for a later chunk, which is answered from it as from any kept result. Two decompilations once cut by thousands of characters were stored as truncated: false, and the report said nothing was cut.

The rows are written in one batch when the run ends, so created_at used to be the flush for every one of them — thirty entries of one run had one distinct value between them, and a ledger sorted by it said nothing about when anything happened. It is now the moment the call returned, started_at + duration_ms, computed as the row is built. A call the recorder never stamped keeps the write time, which is honest about being the batch's.

EventsCopy Anchor Link

A run narrates itself. Every node, every tool wrapper and every retry loop emits events through one sink (src/maljan/pipeline/events.py), the worker publishes them (_publish_event in apps/api/app/worker/analysis_worker.py), and the console draws the running analysis from them.

agent_message.kind is one of says, tool_call, tool_result, validation_feedback, judge_question, verdict, system, delegation_ask, delegation_answer. An ask and its answer are the last two, with addressed_to naming the other side, which is what draws a delegated exchange as an arrow between two participants rather than as two lines to the room.

A violation is published as retried where the producer is shown it and again as resolved or survived once the loop knows which; one the retry introduced is published once. (agent, code, path) is the key those two lines share, so a reader that draws one line per violation folds on it, and two violations of one code on different claims stay apart. A finding the producer was never shown — the judge appends its timeout, its fallback and its two verdict checks after the loop — is published once, as survived.

Sequence. The publisher stamps every event with seq, a per-job counter taken from a Redis INCR. Nothing in src/maljan numbers anything: the core does not know which job it is running under, and a second counter would order one conversation two ways. seq is the ordering key, the dedupe identity and the cursor a client resumes from — ?since=<seq> on /ws/analysis/{id} and on GET /api/v1/jobs/{id}/events return only what is newer, in order.

The stored transcript row carries the payload its event carried: its kind, the stage it was said in, the addressee of a delegated line and the display_name its speaker was known by. A replay therefore groups by stage and keeps the arrow between an ask and its answer, rather than re-deriving a kind that cannot distinguish the two. A run recorded before those columns existed carries none of them, and the console falls back to deriving what it can.

The stored transcript row is written with the number its event went out under, so a live message and its replayed twin are one message. That changed what agent_messages.seq means: it used to be the message's position within the report, 0, 1, 2, …, and it is now the publisher's run-wide count, so it is monotonic and sparse — a conversation of twelve lines in a run that published four hundred events has twelve numbers scattered through 1..400. Ordering is unchanged, and ORDER BY seq is still exactly the order the messages were said in; what is no longer true is that the numbers are contiguous or that they start at zero. A run recorded before this release keeps its old contiguous numbers, which still sort correctly among themselves; because those are a different number from the same run's live events, the report endpoint sends them as null rather than let a client mistake one for a publisher number. It tells the two apart from the rows themselves: a numbered run's largest seq is at least its row count, and the old enumerate numbering's is exactly one less.

Two stores. Events go to the PubSub channel analysis:{job_id} for the live fan-out, to the Redis stream analysis:{job_id}:events (1 000 entries, 24 h), and to job_events against the job, written in batches of fifty events or two seconds. The table is what makes a failed or cancelled run readable: no report is written for one, so before it the whole conversation vanished with the stream. Both readers ask Redis first and the table second — when the stream has expired, and when the cursor is older than the capped stream reaches. core.events.retention_days (default 30) bounds the table; the analysis worker sweeps it nightly (an arq cron at 03:17) and once as it starts, beside its job slot: a cron fires only in a process alive at its minute, and arq does not run a window it missed while no worker was up. The sweep reads the retention from the stored settings or skips. The transcript, the agent findings and the evidence ledger are kept by the report and the job and are not touched by the sweep.

The count is the last number. Every event takes a sequence number from the run's counter, so the rows stored for a job equal the last number issued for it — that is what the events endpoint pages by and what the console checks its history against. enrichment_complete is published after the run has ended, by the other worker, so the enrichment task opens the job's feed for that one line and closes it again; otherwise the number would be issued and the row never written, which is what one measured run's 71 published and 70 stored was. The console already tolerates an event that arrives after the run.

The counter itself is a Redis key with the stream's 24-hour life, and the rows outlive it by core.events.retention_days. So before that late event is numbered, the counter is seeded from the table — the highest seq the job holds, set only when Redis has none — and the number continues where the run left off instead of starting again at 1 and colliding with the row that has it (uq_job_events_job_seq). Enriching a month-old report is exactly that case.

What never travels. Tool arguments and results go out as short summaries, and every string of every event — a message's text and its report, a correction, a cap's detail, a summary — is scrubbed once by the publisher, for all three sinks at once: anything shaped like a credential is replaced, a URL keeps its scheme and host only, and every path is cut to its file name. A Windows function name the vendored export-name catalogue holds, one this job's hash resolution on the analysis server read, or a hash-algorithm id of the vendored algorithm catalogue, is a name and travels as written, as it does in the report (Configuration, "Long agent keys in the conversation"). A producer may scrub as well; the publisher is what makes it a guarantee rather than a habit, and the transcript's copy is scrubbed as it is taken, so a replayed run reads exactly as the live one did.

The fields that name something rather than say something are exempt, by field name (analysis_worker.IDENTITY_FIELDS): the ids this system issues (report_id, job_id, sample_id, error_id, evidence_id, technique_id), the agent, stage, server and tool keys (speaker, agent, agents, addressed_to, stage, stages, via, server, tool, key, profile), the labels an operator typed (label, display_name) and the words the console switches on (role, kind, status, phase, cap, code, verdict). They are exempt from the shape rules only: a value the operator configured as a secret, a short one as a whole word, is masked in them as everywhere else.

The model that answered (model, models, and each key of a models mapping; analysis_worker.MODEL_FIELDS) is not exempt, because the whole scrub reads anthropic/claude-haiku-5-5 as a key by its length. It is scrubbed as a model label (events.scrub_model_label): configured values are masked and a URL loses its userinfo and its credential-named query values. Then each side of @ is kept as written only when it is an endpoint label (a scheme and a host, nothing else) or a provider and a model id split at the first /, each written as a model id is: parts between -, ., _, : and / that are words in one case (claude, Llama, UD), numbers of up to eight digits, or letter-and-digit runs of up to six characters in one case (35b, Q4), fewer than three of the last, and no vendor key prefix (claude-sonnet-4-20250514, meta-llama/Llama-3.1-8B-Instruct). Any other side is given the whole scrub, as every label was before. A process that has registered no configured values, or whose registration failed, holds the label to the whole scrub instead, as it holds a finding row; the API process registers none, so a model label it writes itself (a follow-up's usage rows) can still read ***.

Nothing is exempt for the shape of its value beyond a digest and a canonical UUID, because a credential does not become safe by being lowercase.

A failed call travels as the remedy the tool offered, not as its error text, and a failed node travels as the class of its exception, never its message. The arguments and the output as they were are on the ledger entry, behind the same ownership check as the report.

Names. roster carries the label an operator gave each agent, and GET /api/v1/jobs/{id} carries the same roster, so a reader who is not an admin — and cannot read the agent definitions through the settings endpoint — still sees "Lead analyst" rather than lead, on a live run and on a finished one. Its servers names each tool server by the label its block gives it, so a server's own tab is drawn under that label; its key stays the id everywhere (the tab's route, the ledger, the events).

The findings blockCopy Anchor Link

An analyst may end its answer with a fenced maljan-findings block holding JSON: artifacts (a kind, a label, and either a value or columns and rows) and findings (a title, techniques, a confidence), each naming the ledger ids it came from. It is optional in both directions — an analyst that emits nothing loses no claim, and the CLAIM/EVIDENCE/CONFIDENCE/TECHNIQUE contract the negotiation runs on is untouched. What the block adds is the table a claim cannot carry: the import list, the permission set, the endpoints.

Anything that fails validation is dropped and counted rather than repaired, and the block is stripped before the prose reaches the transcript or the report.

A third key, open_questions, holds what the analyst could not establish: the question, why it stayed open (no_capable_tool, tool_failed, obfuscated, out_of_turns, needs_sandbox_run or other), what would answer it (a tool kind, an agent, a run) and the ids it rests on. The questions travel on the ISR (AgentISR.open_questions) into the analyst's summary, where its peers, the mediator, the judge and a lead that asked it read them, and into the report's "Open questions" table, which names the agents of the run that called a tool of the kind each question names. An open question names an unknown. It is never read as an absence: no grounding, value holder or corroboration reads the table.

A job may also be submitted with questions of its own (config.questions, the "Questions for this run" box of the submit dialog). After the narrative round the report model is asked once to answer each from the run's evidence with one outcome of a fixed set: established, partial, limited negative, not determinable from this run, out of scope (reporting/question_round.py). The model picks the word and cites the entries; code checks them. Every cited id must be one the run issued, "established" needs an entry of a call that answered, "limited negative" needs a coverage record (looked_at, the calls that looked), and an answer resting on an analyst's open question is never a limited negative. The model is told what is wrong and asked once more; a word still refused is printed as not determinable from this run, with the model's word and the reason beside it. The answers lead the report as "Questions asked of this run" and are drawn on the console's summary. A job asked nothing runs no round and renders as before.

A finished job can be asked a new question as well, from the console's summary or POST /jobs/{id}/follow-ups (reporting/follow_up.py, app/services/follow_up.py). It is answered by the same round, with the same checks, from what the job stored and nothing else: the ledger rows read back as entries, the report, the claims in force from the per-agent findings, the open questions from the report's own "Open questions" table and the run state rebuilt from the report's identity, the ledger and the run summary's stages. No tool is called. The model is the reporter the run's settings snapshot recorded, served where its provider is served now (no endpoint is taken from the snapshot), else the current one. The answer is a record beside the report (job_follow_ups), which it never changes; it names the digest of the stored report it was answered from and goes onto the audit chain as a keyed report.follow_up row. The sandbox report is not read back, so a sandbox item stands only as an id the stored report cites: issued, never an answered entry.

A repeated tool call is a message to the model and nothing else. The third identical (tool, arguments) call in one loop is not run; the model is told which entry already holds the answer, and whether that entry was an answer or a failure. Nothing is written to the ledger for it and nothing is drawn in the console: no tool ran, and recording it as a successful call — which it was — inflated the ledger, the report's tool-call count, and gave the model an evidence id it could cite for evidence that did not exist.

ReportingCopy Anchor Link

Every run emits a structured MalwareReport (src/maljan/reporting/), and it is assembled from what the run gathered rather than recomputed beside it:

• reporting/ledger_report.py turns the ledger into report.sections — a builder per known tool, generic fallbacks (a JSON object becomes a key/value block, an array of objects a table, anything else a capped text block) for a tool nobody has written yet, the agents' artifacts grouped by kind, and their findings as one table. Every section carries the entry ids behind it.
• reporting/ledger_projection.py fills the typed blocks — static, dynamic, network, persistence — from the same ledger, because several layers still read them. A tool that was never called leaves its block empty and every layer downstream of it degrades to silence.
• Identity comes from identify_file and hashes when they ran, and from the routing minimum (format, platform, and hashes the builder computes) when they did not.
• Severity, malware category and family attribution are the judge's, read off x_maljan_assessment on its bundle. Nothing in the builder computes a replacement — the CVSS-shaped sum that used to print a score out of ten was arithmetic over constants chosen in the builder, by code that had read no evidence.
• The capability matrix is a projection of the judge's technique list and the analysts' claims, carrying each source's own confidence unadjusted. A judge relationship's technique is the attack-pattern it points at (x_maljan_technique_id wins where written, which the judge never does), so the number the judge put on it is the judge's number; reading the property alone published all twenty judge-only techniques in the stored runs at 0.0. A relationship with no number adds none, and a number off the 0–1 scale is no number (stix.annotation_out_of_schema asks about it; the annotation is kept as written rather than lost to a plain relationship). A technique no source numbered has confidence: null and is printed "not given" — the case for every technique the judge names alone under a verdict with no malware object to hang a numbered edge on. A technique's contributing_layers are the judge and the analysts whose own claims name it: the agents a judge relationship credits are its words about the evidence, published on the relationship and not counted as sources, so one analyst's claim the judge credits to two analysts is not corroborated. A credit is still asked about when it names an agent that did not name the technique: the judge node passes the evidence summary as data (evidence_summary.collect), and stix.credit_without_claim tells the judge which sources did name it, by the summary's names — a parent or sub-technique counts. Nothing rewrites the credit in the judge's bundle; one the judge keeps is left off the export's copy of the relationship and recorded as stix.unpublishable_credit, so no surface prints it. A technique the judge names and no analyst claims is the judge's own claim: asked the catalogue and platform questions every claim is asked, and published with the judge as its source and the judge's own number. Its ATT&CK row says so ("stated by the judge and claimed by no analyst; a technique the judge states is published as its own claim"), so a row with no analyst beside it reads as the rule it is published by and not as a gap. When analysts named it on a finding and no claim carries it, the row names them instead ("stated by the judge; named on a finding, not on a claim, by …"), since the run's corroboration record lists them as its sources. Corroboration counts independent statements (capability_matrix.independent_statements): each analyst statement naming a technique is compared by its normalised text (case, markup and punctuation out). Two count once when they are the same text, when one is inside the other word for word, or when at least 90% of the shorter one's words are in the other (the overlap coefficient over their word sets, REPEATED_WORDS_SHARE): a copy cut short or with a word put in or taken out is one statement, and two analysts' own sentences about one tool's output stay two. The repeat is the shorter of a pair: statements are read longest first (word count, then normalised text, then layer) and each is compared with the ones already kept, so each group is credited to the layer of its longest statement and a short statement can never absorb two longer ones that share only its words; the count does not depend on the order the analysts are read in. is_corroborated is the corroboration record's own decision (analysis.corroboration.corroborated), the one the judge's count and the console read: at least two independent sayers (independent_sayers: the analyst layers credited so, plus the rules that assert it) and, where the ledger was read, at least two independent sources with a behaviour source among them (validation.technique_sources). Every ledger entry or sandbox item a statement naming the technique cites is a source, rooted or not, and every asserting entry naming it: one pack row is one source however many analysts restate it. Each source is read for what it is (evidence_roots.reading_of): a listing of code (schemas.evidence.lists_code, the platform's one rule for a tool name that decompiles or disassembles); a run observation (its roots are sandbox processes, flows or DNS queries); a rule match (an asserting tool's entry whose own rows name the technique, or one the statement places a row of: a capa match by its address, a sandbox signature by its name, sandbox signature <name> being a signature row's own root; a sandbox's own technique tags on a signature, as its report declares them, ride on sandbox_signatures rows as technique_ids and make the citation a rule match for those techniques, and a signature's name is never read as a technique); an artefact of the file (a place in it, its tables, the file itself, or what its answer states as a whole: a count, a scheme, the routine an emulator ran, a value every row holds, which a statement writing it in a sentence or evidence item citing the entry places, evidence_roots.answer_facts; never a reference lookup, a reputation answer or a run's answer, and a count of zero places nothing); an external assessment of the whole file (a reputation answer, whose root is "an external assessment of the whole file", read from the platform's one table of reputation tools, evidence_roots.FILE_ASSESSMENT_TOOLS); or a citation placed nowhere. A run observation or a rule cited by a sentence or evidence item of the statement that says it was not seen or holds no record (_NOT_SEEN_RE, _HOLDS_NO_RE: "capa has no injection rule", "no write is recorded"; a negating word that says nothing of the source, "resolved, not imported", is not one) is cited for its absence and placed nowhere; a citation written only in the evidence line is read against the claim's sentences too. independent_sources counts the sources that stand behind a fact about the technique, joining citations of one reading kind whose roots overlap (two tools reading one string are one source; a rule match and an index row on one function are two methods, never joined); a citation placed nowhere stands behind no fact and an external assessment of the whole file states nothing about any one technique, so both are listed and counted by kind (source_kinds) and add nothing to it, and a row whose statements cite nothing has no source and is not corroborated. A technique no source of which is behaviour is published all the same and labelled: support: capability where its placed sources are all artefacts of the file, support: unobserved where one is an external assessment or none is placed. Neither is ever corroborated. Its ATT&CK row prints "published as a capability, not observed (3 sources: 2 artefacts of the file (…), 1 citation that gives no root; no sandbox observation, code listing or rule match stands behind it; …)" or "published as not observed (…)", one sentence (analysis.corroboration.support_sentence) that the judge's evidence summary, the report models' published-techniques lines and the export carry alike; a row short of two independent sources adds "they cite 1 independent source, each counted once". The export keeps uses and marks this run's uses edge to the technique, a judge-made one included, with x_maljan_support (capability or unobserved) and x_maljan_support_note (the sentence): on the edge, not on the attack-pattern whose id every export shares; the judge may not write either (PLATFORM_ONLY_PROPERTIES). The matrix carries the decision on every cell (CapabilityCell.is_corroborated, support, sources, independent_sources), and the console's capabilities page reads it: a capability shows "capability, not observed" with "N cited, M independent", never "corroborated". The judge's corroborated count (the verdict line, the degradation gate and the memory case) uses the same rule; a row stored before sources were read keeps the count of named sources. The row says how many statements were identical or near-identical (identical_statements); a row fewer than two layers stand behind that way prints "not corroborated (N analyst layers name it; K of them in a statement of its own; …)". A finding's detail is a statement and its procedure, and its title is neither: an analyst's one summary title was listed under five techniques. The console's badge and the narrative prompt (independent=) read the same list. A knowledge-table rule that matched only names resolved at runtime (every matched name in its resolved_apis) is named as a source "rule match on names resolved at runtime from hashes only, no import; not counted as corroboration", and under the table each analyst statement naming its technique is printed verbatim, by analyst (CapabilityCell.statements); the platform classifies none of them. Corroboration also counts evidence roots (analysis/evidence_roots.py), beside the layers and never instead of them. Every ledger entry states the places in the sample its facts were read from, derived from what the entry holds: a place written as its offset from the image base and the section that holds it (0x1a40 in .text) for a strings row's file offset, a FLOSS row's call site, a decoded blob, a hash occurrence, a capa match address, a function index row, the start of the range a transform_bytes call read (or the no: sentence its answer states when no section holds it), or the address a decompile, disassembly or memory read was given; a table of the file (the PE header, the import table, the export table, the resource table, the debug directory, the overlay, a section by name); a sandbox process, which a Sigma match's or a LOLBin hit's command line is joined to; a network flow, named the same whether the sandbox or the capture states it, and a DNS query by name; or the whole file, for hashes, identification, signing and a file reputation answer. A FLOSS row the blob decoder ties to a blob at the same call site with the same decoded text has that blob as its root, so the two tools reading one encoded string are one root; a call site holding blobs none of which decodes to the row's text gives the row no root. A Sigma match or a LOLBin hit is joined to a process only when one process the sandbox recorded has its command line. The two directions of one connection a capture lists are one flow, named by the end it was first seen going to; a host name the sandbox states joins no capture address it does not itself state as that name's resolution. Each file has its own layout. An entry is about the sample only when the path it names is the sample's (the path the triage pack states, a path with the sample's file name, or one whose stem is the sample's SHA-256), or when it names no path and its server's program is the sample: a server holds the program its latest program statement or open names, the sample until one names another file. Any other entry (a file the run carved, a dropped file named by its path, a disassembler's program of another file) is placed against that file's own section table and image base, and its roots name the file by the digest the run states for it or by its path (0xa100 in UPX0 of file sha256 1a2b3c4d5e6f); an entry whose file cannot be told gives no root. An address is read against the nearest image base below it, found by bisection. A file that states an image base and no section table gives a file offset no root, since it cannot be placed against the file's addresses. A place inside a function is that function's root, function 0x2c10 in .text, so a capa match inside a function and a decompile of it are one root, only by the ranges the file's own exception directory states. The pack's function index carries them beside its answer, never in it (LedgerEntry.function_ranges), so the answer is what it was and the evidence byte budget, which charges the answer alone, displaces nothing for them. A range is used only when it lies inside one section and holds no other function start the run knows (the index's starts, exports, the entry point, call targets); a disassembler's stated size and Ghidra's size_bytes are not ranges. A place that kept ranges of two different functions both hold belongs to neither; two places in one function with no kept range stay two. The analysis server's served function index gives a root per row its lines state, by the row's address. An entry whose root cannot be read has none and says why in a no: sentence: a reference lookup reads nothing of the sample, a failed call read nothing, a call naming its function by name gives no address, an answer with no offset, address, section, event or flow has nothing to place. A statement's roots are those of the entries it cites; an entry holding several gives the ones the statement picks out by a number, or by a quoted or backticked value or name, or a name written as an identifier in its own case, that only one of the entry's roots holds (an import, an export, a section, a resolved name). A number is read in the coordinate the entry's rows state: a file offset for a strings or YARA row, an address otherwise; a number that names one row so and another in the other coordinate names neither. A name several rows hold, a prose word, or a passing mention of a table ("the imports", "the header") picks out nothing. A statement picking out none of a many-row entry's rows gives no root for it and says so ("no: the statement names none of ev_0007's rows"): which row it read is not a fact. An asserting row that names the technique and gives no place (a capa rule with no address, a Sigma match with no one process joined) gives none either, with its reason. The capability row and the published technique carry the distinct roots (evidence_roots) and one <entry>: no: <reason> per cited entry that gave none (roots_not_read); the corroboration record carries the same two lists, adding the rows of each asserting tool's entry that name the technique; the judge's technique question states "2 layers, one evidence root (0x1a40 in .text)" under each technique's mentions, the same layer count (independent_statements) and the same roots, read from each claim's text and evidence line, as the report row. The report's corroboration words carry the count of roots inside their parentheses, and name the root only when there is exactly one ("one evidence root (0x1a40 in .text)"); the full list is in evidence_roots in report.json and in the run record; a single-layer row states its layer and roots on their own. No publish rule reads the count. The roots are read from one job's ledger in the step that needs them, with no cache shared between jobs, in time linear in the entries and their rows. A stored report built before roots were read renders as it did. The ELF run credited STATIC ANALYST with T1490 and T1048.001, which no source named. A bundle the pipeline built from the analysts' claims because the judge's answer was not one credits those analysts, not the judge. A technique id is read only from a reference filed under MITRE ATT&CK (analysis.technique_ids.attack_reference_id). It is where an id the ATT&CK check rejected stays on the record, marked technique_id_valid=False and spelled as the producer wrote it. Every id that reaches the report is collected into it, from all three carriers: the judge's attack-patterns, claims[].technique_id, and findings[].technique_ids — the second place an ISR keeps technique ids, and the one no check ever saw. A recorded Android run's final ISR carried one claim with no id at all, so no domain check fired anywhere, and the report's Findings and Corroboration tables printed three enterprise-only ids with nothing saying they were not published. Every id still standing is asked the catalogue question here as well as the domain one, so an id that arrived on a finding gets the same answer an analyst's claim got in its own loop.
• ttp_mappings is the published technique list, and every other technique surface is built from it: the report's ATT&CK section, its References, the attack-pattern objects of the STIX bundle — minted with ids derived from the technique id, so the same technique is the same object across exports — and the mitre_techniques column behind /reports/{id}/mitre. What the judge said about a technique travels with it: its relationship, with the confidence, the evidence basis and the contributing agents it annotated, is re-linked at both ends to the rebuilt object of the same technique and carried unedited, and the rebuild mints no second uses edge for a technique the judge already used. A relationship to a technique the checks rejected is removed with that technique and recorded in run_summary.validation as stix.unlinked_technique — counted once, as the technique's loss, and not again by the integrity pass as a dangling ref. Two checks keep a technique out of the published list, and both write their reason into CapabilityCell.not_published, which the markdown prints under Claims that were not published as techniques: an id the catalogue has no entry for, and one whose ATT&CK domain or platforms the routed sample cannot host (attck.platform_mismatch, asked with the same platform_mismatch_message the analyst and the judge were shown, and falling open for a sample whose platform is unknown or cross-domain). The judge has the last word on what it did not name. After the verdict the judge node asks the judge once (JudgeAgent.decide_techniques), in one tool-free question with the verdict's framing and sizing, about the techniques an analyst claimed that its bundle carries on no attack-pattern and no edge, the ones named only on a finding, and the ones every claim naming which the ATT&CK check says does not describe it (validation.claim_does_not_describe_violation) — carried by the bundle or not, asked once either way with the check's finding under it (undescribed_technique_finding) — (capability_matrix.judge_questions), each with the claim or finding text and its evidence ids: keep or drop, with a reason. The check is asked as the analysts' check asks it (claim_asked_whether_it_describes: not of a claim that reads as absence, or whose id the catalogue does not know or the sample cannot host), and its finding is stated as the term match it is: no claim naming the technique uses the catalogue's terms for it. The review keeps each finding it asked with (undescribed), and the row prints it beside the judge's answer and reason. Each asked technique that has a reasoning card shows the card's lines under its claims, as reference, with one line above the techniques saying what a card is; the techniques asked are the same with or without cards. The cards go in only where the judge's window has room left after the reports and the evidence, so they never shorten either. Each id is named as the vendored ATT&CK table names it (attck_loader.technique_label), in the list, in the techniques the question says the bundle carries and in the evidence summary: asked about bare ids, a judge dropped a Winlogon Helper DLL id as "Scheduled Task/Job". Every technique name the platform writes comes from that table, the reference the export back-fills on an attack-pattern included. The question shows what it asks the judge to decide from — the analysts' reports as the verdict call sees them (verdict_reports_text), the verdict and the techniques the bundle carries, and the text of every cited evidence entry — and when the entries do not fit the judge's window less its output cap, each is shortened to an equal share with the cut marked, a notice in the question, and the notice recorded on the answer (shortened). The answer is asked for as a JSON array, read from the schema where the provider has structured output and otherwise by read_technique_answer: JSON arrays and objects first, then each line on its own (table rows, a name after the id, arrows, a "Decision:" label), a <think> block taken out and the last answer per id kept. The decision is read from its position — a JSON decision of one whole word, or the word straight after the id's separator, else the last standalone keep or drop — never from a word in the reason. Each cited entry is shown as stored (question_evidence), with its tool, and marked when the run holds only part of it or only its lower-cased search copy. An id the catalogue rejects or the sample cannot host is not asked and is recorded in not_asked. The answer is kept on the judge's bundle (x_maljan_technique_review, never exported) and the matrix publishes per it: a dropped technique is not published and reads "the judge dropped it (<reason>)", a kept one is published — a finding's technique included — with "kept by the judge when asked (<reason>)" on its row. The record keeps the reason whole; the report's ATT&CK table prints it by one rule for both (reporting.judge_reasons.judge_reason_shown), in the table's Status column and in the list of claims not published under it alike: the sentences that are the model's own working ("Wait, …", "Let me …") are left out wherever they stand, a sentence a retraction takes back ("Wait, no.", "No, …", "Actually no, …") with them, the others printed in order as many as fit the cell (200 characters in the table, 300 in the list), a reason that is all working prints its last sentence, a first sentence longer than the cell is cut at a word, and the cut mark stands where anything is left out; every network value in it is defanged. With no answer — the question timed out or failed, the verdict itself timed out, or no line of the answer is in the form asked — nothing is withheld: each technique is what it would have been without the question, and a published one is marked "not confirmed by the judge". An APK run published enterprise-only T1027 and T1005 on all three surfaces with both mismatches unresolved; they are in the matrix, with the reason, and on none of the three now. The check's own carve-outs decide what survives, and PRE is the one that matters most now that the answer is read to publish by: a technique whose only platform is PRE happens before any host is touched, so nothing about a sample contradicts it — including its domain, which is why that carve-out is asked before the domain comparison. ATT&CK files every PRE technique in the enterprise matrix and mobile has none, so asking the domain first made each of them cross-domain on an APK and would have taken T1583 Acquire Infrastructure off an Android infostealer's C2 registration. An isr.ungrounded_technique alone is not one of the two: it is advisory, and the technique is published and flagged. The three surfaces used to be built from three sources and disagreed inside single runs: ten techniques in one report against zero attack-patterns in its bundle; three attack-patterns with no ATT&CK reference and ids copied out of the STIX documentation against an empty ttp_mappings; a rejected id published in all three.
• Every surface that prints a technique id says whether the run published it. The markdown's ATT&CK section names the unpublished ones under Claims that were not published as techniques; the Findings table writes T1027 (claimed, not published) in its Techniques column; each run_summary.corroboration row carries not_published, written by the report node from the capability matrix's own reasons, and the tables print it through technique_label; the run summary's own line counts both — "3 claimed, 0 published", because "3 named" over a run that published none of them reads as three findings. An id in neither the published list nor the matrix's reasons — dropped by its analyst in revision, so no check was ever asked about it — says exactly that. The console's ATT&CK tab draws from capability_matrix rather than from ttp_mappings, so a claimed-and-unpublished technique appears there too, with the words claimed, not published and the check's sentence under them rather than a colour.
• An attack-pattern with a name and no technique id is asked for one (attck.missing_id) — before this it skipped every ATT&CK check, because all of them key on the id, which is why the Mobile-domain check never ran on an Android sample's techniques. One that survives is reported as a behaviour, in report.unmapped_behaviours and under its own heading in the markdown, and is never published as a technique.
• run_summary.evidence counts the calls and run_summary.sections_without_ evidence counts the sections that can name neither an entry nor a finding — the number that says whether the report is standing on anything.
• The section-wise composer shows each section the exact JSON object it has to answer with, built from the section's own schema so the prompt and the validator cannot drift. This is the manual-parse path, which is the primary path on a local server — structured output is skipped there — and on it the prompt's own rule said "conform to the provided JSON schema" with no schema provided: the only key name a model ever saw was the bundle's opening line, and that line read SECTION: <name>. Two unrelated models answered six runs out of six with SECTION/content or with the section's own name as the key, and every one of those runs authored zero sections. The heading is a sentence now.
• One shape the models produce is accepted as a move rather than a guess: {"<section name>": "the prose"}, where the key is this section's own name and the value is a string, is put into the field that holds the section's prose — text when the schema declares one, otherwise its single string-typed field. A schema with several (a ransom note, an encryption scheme) or none (a channel list) has no such field and is left alone; so is a renamed key, a second key, or a value that is not a string. Anything not accepted is dropped and named, as before.
• The composer keeps the fields a section's schema declares and drops the ones it does not, rather than refusing the whole section over an invented key — which is how two runs shipped with no conclusion. What it dropped, and any section it lost outright (still off-schema after its retry, timed out, or failed), is added to the report's degradation reasons, which the header points to under Notes on a run that is not otherwise degraded. The same goes for a list the composer caps (the flow at 20 steps, the configuration at 30 items, the commands at 40, the flags at 30, the channels at 6): an answer past its cap leaves "report section '…' was trimmed: the report keeps the first N of the M items the report model wrote".
• A missing parser degrades a run only for a sample of the format it parses: the pack skips macho_info on a PE, and a server's …_unavailable reason about a format tool the sample does not need is not added to the judge's degradation reasons.
• The rendered report reads as a vendor's malware analysis, in three labelled voices. The Markdown — and the HTML and PDF made from it — follows one numbered layout: a title block naming the family and category when the judge named a family, with the TLP, the report number and the date; §1 key findings; §2 sample overview; §3 verdict and assessment, with the judge's rationale quoted unedited; §4 execution flow; §5 technical analysis by capability, each subsection's prose followed by the measured or observed tables that prove it; §6 observed behaviour; §7 static properties with the rule hits; §8 one ATT&CK table with procedure, source, confidence, status and evidence columns, the import-table rules among its rows; §9 the indicators; §10 detection; §11 recommendations; §12 attribution with the similarity scores and the background; §13 limitations, where the tool failures, the evidence bounds, every unresolved finding and the export decisions are said; and four appendices — the evidence index with every ledger section, the run summary, the references and the methodology. Every H2 ends with its voice, one of nine tags (renderers/markdown.py:VOICES): Measured, Observed in sandbox, Assessed, Assessed by the judge, Written by the report model, Generated by template, Source per row, Source per subsection and Reference; a section of several voices tags each subsection, and a §5 subsection holding both the report model's prose and a measured table is tagged Source per row and labels the prose the way each table is labelled rather than being split in two. A confidence is printed as a number, a fixed word for it and its producer — moderate-to-high confidence, 0.86, stated by the judge — the word a deterministic reading of the number (≥ 0.90 high, 0.70 moderate-to-high, 0.50 moderate, 0.30 low, below that very low) and never printed alone. Model prose ends with its citations, or with no evidence cited and one sentence saying to check it; the renderer adds tags, citations and words around the model's text and changes none of it. Every numbered section, every §5 subsection and the §10 and §12 subsections are printed; one with nothing in the run prints one line in the platform's voice that says whether nothing was found or nothing looked, naming what did look — "Nothing recorded in this run: the tools that ran over the file (capa, yara_scan, …) recorded no discovery command, and the sandbox recorded nothing for this sample; the report model wrote nothing on it", "Not written in this run: the report model wrote no execution flow"; "Not examined" only when no tool looked at the file at all — and the table subsections of §6, §7 and §9 are unnumbered headings that appear only when they hold a table. An absence is said only for what a tool looked at: "no persistence observed" only when a sandbox recorded the host (a dynamic block whose registry and file operations it provides), with the failed and trimmed entries named when the evidence was partial, and "No sandbox observation is recorded in this report." for a stored report that cannot say. The numbering is fixed, so a comment can cite §7 whichever sections a run filled.
• A degraded run's first screen is one sentence. The header builds it from the stage and agent records — the failed-analyst list, each analyst's recorded skip reason or no-data flag, its claim count — and the sandbox's state: "The static analyst failed, the dynamic and network analysts were skipped (no sandbox fixture for this sample) and the sandbox recorded nothing for this sample; the verdict above is tentative. See §13 for what this run could not examine." It never prints a reason code or an operator's install command. §13 lists every degradation reason verbatim, with its remedy where the reason carries one, and prints each analyst's state under What ran. A run that is not degraded but recorded limitations points to §13 in one line. §3 does not claim consensus among analysts that claimed nothing.
• Every number printed has an owner. A technique confidence prints with its producer ("high confidence, 0.92, stated by the judge"), read from CapabilityCell.confidence_source, which the matrix sets to the source of the highest number; a stored cell without it says "producer not recorded". A confidence nobody stated prints "not given"; a packer match, a function-hash match, a similarity candidate or a carved payload with no value prints "not recorded", never 0; a similar sample the long-term memory returned without a distance is counted and not listed ("No similarity measure was recorded for these samples."). A finding an analyst wrote without a number carries none (Finding.confidence is None), and the matrix records neither a number nor a producer for it. The sample's reputation lookup is one measured sentence in §2 ("VirusTotal: 52 of 75 engines flag it as malicious"), from the engine counts ledger_report lifts into rows.
• A model's table is never a measured row. The import table, the string table, the process tree and the persistence mechanisms are projected from tool output only (ledger_projection.static_from_ledger, dynamic_from_ledger, persistence_from_ledger take no analyst reports); §5.2's import count, §7's import table and capability profile, §8's rule matches, the IOC table, the corroboration corpus and the detection drafts read them. One run's analyst listed names it had resolved from hashes as KERNEL32.dll imports, and the report counted 23 imports against the tool's 5 and matched rules on them as imports. An analyst's table of imports, IOCs, processes or persistence stays in Appendix A under its kind, with a line naming the analysts who listed it (markdown.analyst_list_note, from the section's artifact: source) and saying no measured table, count, rule match or capability profile reads it. Appendix A is tagged Source per subsection: each of its sections carries its own voice, Measured for a tool's answer and Assessed for an analyst's table or findings, so no model's rows sit under a Measured tag. A kind more than one artifact listed rows under is one table whose first columns (Listed by, Evidence) say which analyst listed each row and the ids that row's artifact cites, and the note says where else the table's rows are shown; the §5.4 Assessed block cites each row's own ids. The body still shows them as the analyst's. §5.4 keeps the tools' table and adds an Assessed block of the persistence the analysts listed (Kind, Target, Payload, Listed by, the evidence the table cites), read from the analysts' Appendix A tables (ledger_report.analyst_persistence), never from persistence; the narrative is handed it as its own persistence_assessed fact. The IOC table carries each mutex, path, registry key, scheduled task and service an analyst listed (ledger_projection.listed_non_network_values) as an analyst row, "listed by the <analyst> analyst", with the rule's refusal, after every tool row, and not where the judge names the value (the judge's row answers it). A row of any kind only an analyst listed is listed-only to the rule, so it publishes nothing.
• The proof sits beside the prose. §5.1 and §5.2 print every capa rule the run recorded in the anti-analysis, obfuscation and encryption namespaces, and in the runtime-linking, PE-export, hashing and checksum namespaces (with the PEB-access rule), with the capa section's evidence ids; a rule that speaks to resolution is printed there once, not in both. In §8 a rule naming a technique a row already holds is folded into that row's Procedure and Evidence; a technique only rules named is one row with the catalogue's tactic and name and the status "not published: a rule matched it and no producer claimed it".
• A list item, a step and a heading are built by one helper each. _item, _step and the heading helpers flatten a value onto its line, and model prose cannot open a heading (ATX, or setext through a line of = or -), a code fence or a table (a delimiter row is escaped); fenced blocks use a fence longer than any backtick run inside them. test_a_list_item_is_never_assembled_by_hand fails the build if a string literal elsewhere starts a bullet, a step or a heading, as the table guard does for rows.
• Who is speaking is who spoke. The platform's "No summary was written" fallback is headed Source per row with a voice per line; the platform read from the file format is a Measured row of §2, not the judge's; §12.1 is tagged by who named the family (the judge, the sandbox's classification as Measured, or Assessed when a stored report does not say). The title names a family only when the judge named it with evidence ids. The report model's unresolved findings print under §1. The HTML anchors and contents are the section titles alone, so a link does not change with a voice tag.
• Network indicators are defanged for reading, by their kind. reporting.defang.defang(value, kind) writes hxxp://, hxxps:// and fxp:// with the host's dots bracketed, [.] in names and IPv4 addresses, [:] in IPv6 and [@] in mail addresses; a hash, a path, a registry key, a mutex, a pipe, a user agent and a command come back unchanged, so update_data.dat is never bracketed. The same rule reaches model prose and the evidence dump through ProseDefanger, which touches exactly the values the run's network block and IOC table hold, as whole tokens. Strings of note, every indicator column, the platform's findings (section 13, the verdict, the export decisions), a tool failure's error, a draft rule's source line, compile error and comments (each <value>: published because <reason> line of a YARA or Suricata draft; the strings and contents the rule matches on stay as they compile), the command-line flags table, the sandbox's command lines (§5.5 and the process tree), the persistence targets and payloads, the registry keys and value names, the file operations and dropped files, the shadow-copy commands, the mutexes, the notable APIs, the kill and spared lists, the file name as submitted and the internal and export names, and model prose and cells beyond the run's own values defang every URL of any scheme, www. host, mailbox, IPv4 or IPv6 address and host under a real top-level domain (the string sweep's list, the root zone's; any number of labels, in capitals, .onion): everything a viewer could link. A closing pass reads every section of the rendered Markdown once more with the same defanger, so a cell or code span a section did not pass through it prints defanged too. It leaves only what the renderer itself set aside when it wrote it, under a token drawn for that render: each draft rule's body, which prints as it compiles, and in the run summary's appendix a model's endpoint where a generation or prompt-rate line names the model (<model> @ <endpoint>) and the endpoint is one the run's own settings configured, as its disclosure record keeps the labels (disclosure.endpoint_labels), so a stored report prints the same on any machine and one recorded without them keeps no endpoint. The same endpoint anywhere else, or a URL that begins with it (http://127.0.0.1:8080/gate beside a configured http://127.0.0.1:8080), prints defanged. No heading or fence in a sample's or a model's text makes a region the pass leaves. The host reader the publish checks, the run summary's sentences and a cell's state note use (validation.network_values_in) reads a .onion name of any labels by the same form reader, and an IPv6 address whole (an IPv4 tail included) when it is bracketed or has at least three groups and a digit, so a scope name such as dead::beef is no value; the defanger still brackets any shorter form. What a viewer can link is decided by form alone, never by a TLD or an exemption: a scheme before //, a scheme a link or autolink syntax opens (<…>, [x](…), [r]: …), a mailto:, xmpp:, javascript:, vbscript: or data: before a target, a www. prefix, and a mailbox. Each is defanged wherever it stands, after any character (_, *, ~, (, /, a digit) and at any nesting depth: http, https and ftp, read whole from the scheme's first letter, become hxxp, hxxps and fxp, any other scheme's colon is bracketed (ws[:]//, irc[:]), and the host's dots, the @ and an IPv6 address's first colon are bracketed. The TLD list and the file-name rule below decide only bare hosts and addresses, which no viewer links. A kept reference lookup is split off first; the rest is read once, in time linear in the text, with no character used as a placeholder. The HTML report links no bare text (CommonMark, no linkify); it makes an anchor only of an http, https or mailto target, a place in the page (#…) or a relative path with no leading / and no backslash, so neither a defanged URL nor a protocol-relative //host is one; it renders a Markdown image as its alt text and fetches none; and its <meta http-equiv="Content-Security-Policy"> is default-src 'none'; style-src 'unsafe-inline'; img-src data: (the inline stylesheet and the figures' style attributes need 'unsafe-inline'; the figures are inline SVG and need nothing more). A version number ("FileVersion 10.0.0.1"), a .NET name ("ASP.NET") and a two-label name in free prose under a TLD that is also a file extension (.zip, .mov, .py, .so, .sh, .ps, .ai, .md, .rs, .pm, .cat, .one, .cab: "lib.rs", "install.sh") print as written unless the run recorded them; under a scheme, a //, www. or @ such a name is always defanged; a name of more than four labels opening with a reverse-DNS root (com., org., android., java., …) is read as a package, not a host, unless the run's network evidence holds it; a two-label name whose first label is two characters is read when that label holds a digit and a letter (c2.ru), and one of two letters (ab.ru, to.do) only by a check that asks the run's network evidence, or defanged where the run recorded it, while every name read before is still read; a draft rule's body is printed as it compiles; an ATT&CK lookup (/techniques/…, /tactics/…, /software/…, /matrices/…), and a link the report itself holds (one of its references, which are the operator's lookups and those of the lookup services the run asked, or a link one of its reputation records carries), with no query and no dot segment, backslash, @ or second // on its decoded path, after a sentence's trailing punctuation is trimmed, and kept exactly as matched, stays a link unless the run's indicator is in it; a report stored before reputation records also keeps a VirusTotal (/gui/file|url/<hex>, /gui/domain|ip-address/<value>) or MalwareBazaar (/sample/<sha256>/) lookup, as it always rendered; anything else on those hosts is defanged, and the configured model endpoint stays as written. The JSON report, the STIX bundle and /reports/{id}/iocs carry every value live, and the indicator section says so under its tables. A §7 string is printed as the file's bytes are, and says it is not an observed endpoint.
• A sandbox row is the sample's when the sample's process tree made it. The Triage mapping carries each flow's procid, pid and AS facts into its tcp/udp row and states sample_process_tree: true when the flow's process is the sample or a descendant of it through procid_parent, false when the report names another process, absent when it does not say. The sample's processes are read from two facts: the processes Triage marks orig, and the processes that run a file whose name equals the submitted name or is the sample's digest with an extension — equal, never contained, so a guest's MicrosoftEdgeUpdate.exe is not a sample submitted as update.exe. Each fact gives a tree through procid_parent. Where both name processes, a process in both trees is the sample's (true), a listed process in neither is not (false), and one in exactly one tree is disputed: the facts disagree, so its attribution is absent and the row says which fact alone named it (lineage_disputed: marked or file, with lineage_marked_by naming the sandbox whose mark it is, the display name its report format declares; a row stored before says orig for marked and is read as such, and its sentence names Triage, the one sandbox that marked one). Where only one fact names any process, its tree is the answer. A flow outside the tree or disputed carries the image of the process that made it (process); the address's row states those processes (outside_processes, marked_only_processes, file_only_processes, as <image> (procid N)), and the publish rule's no: and the IOC table's context name them with both facts. A disputed row, like any unattributed one, is published only when the judge keeps it after being asked once with the sandbox's fact: the verdict's own question names each judge indicator on such a value with the fact beside it (validation.unattributed_indicator_violations, the facts read by nodes.judge_sandbox_facts from the network block the report is built from), and a keep after that question is recorded answered (stix.indicator_unattributed_flow, answered: true, subject kind:value). The publish rule reads that answer (stix_renderer.sandbox_row_kwargs): the row's reason states both the keep and the sandbox's fact, and a judge's keep it was never asked about publishes nothing and says which case applies: the judge wrote the value in its last answer and no turn was left to ask it, or no question with the fact is recorded for this run (a report stored before the question, or a verdict with no readable network record). A judge URL is asked about its host, the value its keep stands on, and a URL row on an address says the judge kept, or named, its address. Every published row says why, on every surface: the IOC table's yes: reason, /iocs' publish_answer, the end of each exported indicator's description ("Published because: …") and a comment beside each value in the YARA and Suricata drafts. CAPE, REST and mock reports carry no process on a flow, so every address they record is unattributed and is published only when the judge keeps it. The network block is projected from the job's whole report, never from a paged view; the in-process sandbox views answer every row and page on request, and their answers go through the MCP toolkit's own guardrail (ServerRegistry.answer_sizer: the job's limit and ledger, the context budget charged, a JSON answer shortened as a document whose notice names offset and limit), and an address somebody watched is kept whatever its class and answered with no: when it cannot be published. The sandbox view marks public DNS resolvers, and the network block carries the attribution, the resolver fact, kept_by (the analysts whose artifact lists the value) and mentioned_by (an analyst's claim holding the value). A value is listed by an analyst's artifact (ledger_projection.kept_network_values) of a keeping kind only — endpoints, network, iocs, c2 and their plain spellings (network_iocs, c2_endpoints, indicators); a table of contacted hosts is an observation and keeps nothing. A row has one type cell: the column a heading names type, or else the first short cell (at most three words; a longer one is a note) naming a type, read by its last word with a :port taken off ("C2 domain" is domain, "ip:port" is ip). The type applies to one value cell — the heading's value column, or the cell after the type cell, or the one before it when the type comes last or the cell after it is no value of that type — and a network type (ip, ipv4, ipv6, address, domain, host, hostname, fqdn, url, uri) keeps that value. A row whose type cell is a file, a path, a mutex, a registry key, a hash or anything else keeps nothing; a note cell never drops a typed row. Every other cell is read untyped, and only in an endpoints or C2 list: an address is kept, a name only when it could be a host and has no file extension. A name the model typed as a domain, host or URL is kept as written, whatever its TLD (.zip, .mov and .app are real ones). The value is read tolerantly: a port taken off, IPv6 brackets, any case, a URL's host. The judge's URL indicator keeps its host the same way. A well-known benign host is kept only as itself, never through a URL on it. FINDINGS_BLOCK_FRAGMENT states the shape it asks for (ENDPOINTS_ROW_SHAPE). The publish rule (stix_renderer.sandbox_row_kwargs, asked through emulation_kwargs by the table, the export, /iocs and the judge's values alike) holds back a sandbox address the tree did not make, and a well-known benign name the guest resolved — Windows resolves through its DNS service, so a name is judged by what it is — until the judge's indicator keeps it. A model's list never overrides what the sandbox says about a value. An analyst's artifact listing the value is named in the reason and publishes nothing (one run's endpoints artifact published every conversation the guest had, the public resolver included), and a claim that mentions the value keeps nothing (one run's analysts named two background addresses in claims calling them noise). The row reads no: <reason>, and no model kept it as an indicator, or, when an artifact lists it, no: <reason>; <artifact> lists it, and a listing does not change what the sandbox recorded about it; the judge did not keep it as an indicator, naming any claim that only mentioned it, with the AS fact in the reason and the table's context. A public DNS resolver is never published, whoever lists or names it, the judge included: the reason states the sandbox's fact, that it is a public resolver and who listed it. A sandbox URL whose host is an address takes that address's row facts: it waits for the judge when the address is unattributed, and a resolver's URL is never published. A value's standing comes from where the platform saw it. The capture (pcap_summary) is a sandbox view like the flow table: its conversations' addresses and its TLS names are sandbox rows, with no attribution. A name only the capture's TLS list recorded, which no DNS or HTTP view names, is capture_only and reads no: a TLS name only the capture recorded, which does not say which process made the connection, and no model kept it as an indicator until the judge keeps it; a name a DNS or HTTP view also names keeps the name rule. A row the sandbox view holds is decided by the sandbox rule above, a row a tool read out of the file (the string sweep, a recovering tool) by that source; a listing never lifts a row a tool recorded (ledger_projection._DOMAIN_SOURCE_RANK ranks analyst below strings). Every value an analyst lists is looked for, whole, in every tool answer of the run at build time (ledger_projection.tool_sightings, stored as tool_sightings, keyed on both sides with ledger_projection.value_key, so a bracketed or capitalised address is found). An entry whose call arguments hold the value is no sighting of it: a lookup's answer repeats its question, and a search returns the match it was asked for. Such entries are kept apart (tool_queries), and a value only they hold reads no: named only by an analyst (<artifact>); only the answer to a query for it holds it (ev_NNNN <tool>), ..., so "no tool in this run saw it" is said only when no answer holds the value at all. A row only an artifact created and some answer's text holds takes the string sweep's standing (strings), whichever tool printed the text — a sandbox signature's description, a command line and the sample's strings a sandbox re-serves are text, not observations; only a structured network record (a flow, a DNS query, an HTTP request, a capture conversation) makes a sandbox row. A URL's HTTP method is the one its request record states and is absent on a URL no request carries (NetworkURL.method, null): every URL used to default to GET, which contradicted a POST beacon decoded from the file. A name's DNS answers are its resolved_ips. Such a value, with no second source, reads no: seen only in the text of <entry> (<tool>), and no second source in this run records it; <artifact> lists it. A value no answer holds (source analyst) is asked the string sweep's questions and otherwise reads no: named only by an analyst (<artifact>); no tool in this run saw it, and the judge did not keep it as an indicator — said only after that search. A report stored before the search is searched in the tool sections it keeps: a value its kept capture or flow-table section holds is answered as a fresh build answers it (an unattributed address, a capture-only name); a value another kept section holds is answered as strings, the reason saying it is read from the sections the stored report keeps; otherwise it says only that no tool answer it keeps holds it. /iocs?include=all carries the analysts' listed non-network rows exactly as the report's IOC table shows them, both read by one reader (builder.ioc_table: rebuilt from the stored report, the stored rows only when the rebuild fails), so an old report reads the same in both. The judge naming such a value keeps the standing it had before, so it is published. One run's sixteen capture addresses were told no tool saw them before the capture was read. The drafts read the table's answer, the Sigma selection included. A published URL carries its name. The host of every URL the rule publishes — the network block's and the judge's — follows the URL's decision (published_url_hosts, in_published_url), except a well-known benign host, which is published only when the judge keeps the host itself; the table, the export and /iocs add it as a domain row and indicator when nothing else did. The export carries every row the table publishes, whatever their number. The rule's report-wide lookups are built once per table, export or feed (one_reading).
• The IOC table is the one publish rule's answer, row by row. build_consolidated_iocs stores every indicator live with its kind, who recorded it and published: yes: and the reason indicator_publish_reason gave, in words (stix_renderer.yes_because), or no: and the half of it that refused the row (stix_renderer.publish_answer), asked with the arguments /iocs and the export ask it with. The renderer rebuilds the table on request from the stored report, the way /iocs does, so an enrichment that ran later is reflected and a report stored before the table carried kinds prints in the new shape. A row the export mints nothing from says so rather than borrowing an answer. One decision for the judge's values. The export asks every value a judge indicator compares the one publish rule, exactly as the report's own row for that value is asked (stix_renderer.judge_value_answer): with the network row's source and reputation where the block has one, as the sample's identity for its own digest, and otherwise as the string sweep's with the run's second-source record. The judge asserting a value is not a second source. A refused value declines the indicator (stix.indicator_not_published); the judge's own bundle keeps it. The builder stores the judge's single-comparison values on the report (judge_indicators); the table and /reports/{id}/iocs ask the same rule of them through one helper (judge_indicator_rows), so a value the table has no row for is a judge row with the rule's answer, and a row the table never asked (a sandbox's file write) is asked now. The rule answers two kinds it used to leave open: a hash is publishable when it is a whole digest a second source knows (the sample's identity, a dropped file), and a command line is not an indicator this run publishes. A run once exported two C2 names decoded from the sample's strings while the table listed four hashes; under the rule both are unpublished rows ("seen only in the file's strings") and the export declines them. A test holds the export and the table to one decision.
• A decoded value the code passes to an API argument of its role is a row of its own. A decoded mutex name, file path or user agent has no standing by its shape: a run decodes user agents the code never uses. The builder binds a decoded text (reporting.call_bindings, stored as bound_values) only where the run's answers state the whole chain: the static decoder's reference passes the encoded bytes to a function of the file, the frame slot that call was given (never its return value) is an argument of the next call, directly or inside the function that call reaches (inside), that call is an import the file's table names or a slot one function index entry alone names, and the argument-role table (data/api_argument_roles_v1.json, written from the Win32 prototypes) says that argument of that API takes a mutex name, a file path or a user agent in the text's encoding. A file path is listed only where the call makes or removes the file (a copy's or a move's destination, a download's file, a delete), and CreateFile only where its creation disposition is a constant that creates the file, read at the call; a path a call only reads is as often the system's own. The row's source is call_argument, its context the argument and the call, and its yes: reason the chain, which §9, /iocs, MISP's comment and the STIX indicator's description each carry; a user agent's pattern compares the User-Agent request header of http-request-ext. A judge value the report binds is asked as the binding. A bound value publishes nothing under a Benign verdict or one the judge stated no confidence for. A bound user agent that begins as the common browsers' do (the table's browser_user_agents) keeps its row and chain but is refused by the rule, with the reason, on every surface; the prefix rule is conservative and also leaves a browser-shaped agent with a token of its own unpublished. A user agent nothing binds is refused with that reason, and every other decoded text stays a candidate.
• A value a tool recovered from hidden text is a source of its own. Two tools recover text the sample hid: FLOSS, by emulation (its decoded, stack and tight strings), and the static decoder (decode_string_blobs), which undoes the simple encodings a sample keeps text under in its own bytes, by arithmetic. One reader finds the candidates in both tools' texts (stix_renderer.decoded_indicators): the text as one value, as an analyst's endpoint cell is read, and the string sweep's own indicator scan inside it, over the decoder's result text and each base64 layer under it and over each FLOSS string, which is also kept whole as before. So a host:port, a Host: line or a URL inside a sentence yields its value from either tool; until this a FLOSS string was read only whole, and such a value from FLOSS was missed. A text that holds no domain, address or URL stays a string fact and is no candidate. A recovered value is publishable when it passes every other question of the rule (the host question, the address classes, the reputation half, the URL host denylist) and is not a well-known benign host; the reason reads "recovered by emulation (decoded strings), ev_NNNN" or "decoded from the file's own bytes (decode_string_blobs), ev_NNNN", the recovering entry's own id. A recovered value keeps its standing when the capture also holds it. An address or name a recovering tool read that the capture holds a conversation to, or has in its TLS list, is admitted by the recovery before the unattributed hold (_recovered_and_held), under every refusal the recovery has (a Benign or unstated verdict, a well-known host or public resolver, a value also in the plain strings); the rule's reason states both facts, and a refusal names the sandbox fact and the recovery's own reason. A recovered value is a candidate row whether or not a model named it. The builder reads each domain, address and URL the record holds, as the recovering tool spelled it (EmulatedStrings.spelled, read by stix_renderer.recovered_network_values), into the network block with the string sweep's source (network_from_ledger(recovered=)), classified by the reader an analyst's endpoint cell is read with; the rule above decides it like any other row, so a value a model did not name is a yes or a no: row in the table, /iocs, STIX and the drafts rather than absent. One live run's second decoded C2 URL, recovered by FLOSS and the decoder, had no row anywhere and was printed live in Appendix A. The Markdown's defang index takes every value the record holds, so a recovered value is defanged wherever it is printed, a FLOSS or decoder table included. Hiding a host behind encoding is a deliberate act benign software rarely performs, while a plain string in a binary is routinely benign, so a value only the static string sweep read stays unpublished — and so does a value a tool recovered that the sweep also read as a whole value in the file's plain strings (a strings or iocs_from_file entry): text the sample did not hide is not recovered, and the refusal names the sweep's entry. Under a Benign verdict it publishes nothing, nor under a verdict the judge did not state with a confidence (a fallback's default word), and the table's refusal says so. A well-known benign host is read by its registered name (*.co.uk included), and a public resolver's address is one too. The record (emulated_strings on the report) is built at build time from every FLOSS, decode_string_blobs, strings and iocs_from_file entry on the ledger, so no kept-row cap of a section decides an answer; the first entry to recover a value answers for it. The record keeps, for each network value, every tool that recovered it (recovered_by), each with its own facts only: FLOSS's string kind, and for a decoded string the routine that decoded it and where that routine was called; the decoder's scheme with any base64 layer, the blob's file offset, the functions around the code that refers to the text and that code's addresses. The IOC table states it on the value's row (recovered_by; the report prints it in the row's Context cell), and /iocs carries the same words. It says why it is partial when no FLOSS entry listed every string it recovered, no decoder entry listed every result, or no strings entry listed every plain string, and the reason carries that. A report stored before the record existed is read from its kept tool_floss_strings and strings rows with the same reader, and the reason says the record is partial. The export, the IOC table and /iocs read it through the one rule. Replayed on the benchmark's stored runs when FLOSS strings were read whole only, the two C2 names the sample decrypted published on both models' runs (the static sweep's complete listing does not hold them), and nothing new published on the benign control. Replayed again after the one reader was added (23 stored runs, under each run's own verdict and with the verdict forced to malicious), no published row was added or dropped. No stored run holds a decode_string_blobs entry, so the decoder half is not measured by that replay.
• Draft detection rules match only what the run publishes. The YARA, Sigma and Suricata drafts (reporting.detection_signatures) are generated after the export. A YARA string or a Suricata alert matches on the IOC table's rows published yes; the import names a rule fired on are no longer YARA strings, since an import is not an indicator. A Sigma selection names a registry key or an image path only when the table publishes it or a sandbox recorded it, and the sandbox's own signature names (sigma_admits); an analyst's persistence target the table does not publish selects nothing. A registry key is compared in one form on both sides — without its hive (HKCU, HKEY_CURRENT_USER, HKU\<SID>, \REGISTRY\USER\<SID>, stripped until the text stops changing) and without the table's trailing value name — admission is asked of every value before anything is collected, and no count cuts a selection. The selection names the key without its hive (TargetObject|contains: '\Software\...'), since Sysmon logs a user hive as HKU\<SID>\... and a HKCU selection would match no event. A Benign verdict publishes no malicious indicator, so it gets no draft, and §10.2 says so. A signed benign tool once got twenty trojan-activity alerts for certificate hosts and a "C2 IP" rule for a version number.
• A drafted YARA rule is checked against the sample it was drafted from. The draft's strings and clauses are declared once, and one function writes both the rule the report publishes and a probe ruleset from them: one rule per string (condition: $a, the draft's own text and modifiers), a reporter rule per clause of the draft's condition (the sha256, the imphash when the draft has one, and the strings clause as the draft's quantifier over the probe string rules), and one reporter for the whole condition over those parts. Once the draft compiles (includes refused by the engine, so no file is opened at compile time), the same engine scans the probe ruleset over the file the run analysed, mapped read-only where it lies, in its fast mode and within core.reporting.detection_rule_check_seconds (the report node passes both, and drafts off the event loop). The draft itself is never scanned: its N of them lists every match up to the engine's limit of a million per string, which a sample repeating a published name could turn into gigabytes; a probe string stops at its first match. The rule's record carries matches_sample (the whole-condition reporter's answer), matched_by (the clauses whose reporters held, in the draft's order, empty when none did) and sample_strings (each string with the offset of its first match, or none), or sample_not_checked with the reason, which never names a path: no sample handed to the drafter, no path recorded, an unreadable file, an unread budget, no engine, an engine whose case folding is broken in this process's locale or whose self-test raised (quoting its message), a rule or probe that did not compile, a scan past its budget, an engine that refused the scan. Before anything else the engine is asked, once per process, whether it folds case (core.ctype_locale.yara_case_folding_problem: a nocase run of 32 i, far longer than an atom, matched against 32 I, since a string that fits in one atom is matched without the engine's locale-built case table); under a locale whose tolower leaves a capital I alone its nocase strings and its import-hash clause would be wrong, so the draft is not checked rather than said to miss, and the platform's processes pin LC_CTYPE so that this does not arise (see Native runs pin LC_CTYPE). A drafted rule carries the sample's own sha256, so it always matches by that clause (but on an empty file, whose hash the engine leaves undefined). Its imphash is pefile's, the identity table's value and the one external services publish; for a sample that imports WSOCK32 by ordinal the engine names those ordinals through its WS2_32 table and computes another import hash, so matched_by then truthfully lacks imphash. Since the sha256 clause always holds, §10.2 and DETECTION say which clause held — "its strings match it (k of n strings found)", "the rule matches it by its sha256 only; its strings do not", "the draft declares no strings", "the rule does not match it" — with the strings found at their first offsets and the strings found nowhere, or "Not run against the sample it was drafted from: …". A rule that does not match is kept. Sigma and Suricata drafts, which no engine runs on a file, carry no check, and a rule stored before it renders as it did. Every drafted rule's record also carries printed (whether the analyst report prints its body) and standing (the sentence it prints beside the rule's name: the Precision line, or why the body is left out), both set where the record is built from detection_signatures.rule_standing, their single source, which the analyst report prints from and the console reads; a rule stored before them carries neither.
• A technique only a rule match stands behind says so. A published technique a deterministic rule asserted and no analyst claimed is marked in the ATT&CK table: "rule match only (yara rule, N string(s)), no analyst claim", the count read from the scan's answer (distinct string identifiers, kept as rule_match_strings, each row with the asserting layer that matched it, so any signature-rule tool's rows are named under its own label). The publish rule is unchanged. Such a technique grounds no capability word: neither its id, its name nor its rule's row in the evidence counts toward narrative.ungrounded_capability. The report writer is told so per technique — every section's list of published techniques and the summary's carry the note, with a line saying to write that a rule matched — and a sentence that names such a technique by id or catalogue name as something the sample does, with no word of a rule or an estimate, is asked about once (report.rule_match_as_action) and, if it survives, marked where it stands ([a rule match only, stated as an action: …]). A capability word behind such a technique is told the same in the capability question.
• What the models write is asked for as the exact object, with an example, and printed as written. The narrative round answers executive_summary, key_findings (each {text, evidence_ids}) — the prompt asks for three to six and the schema accepts two, so two good bullets are kept rather than the round failing and taking the summary with it — and the recommendations; its capability paragraphs are no longer asked for. The composer writes the background, the execution flow (FlowStep{order, action, voice, evidence_refs}, voice observed or assessed), the prose subsections for packing, API and string resolution, discovery, persistence, evasion, command and control and payloads, the configuration (ConfigItem{key, value, how_obtained, evidence_refs}), the host identifiers (HostIdentifier{kind, value, purpose, evidence_refs}: what a responder can search a host for, each value as the entry the model read it in records it — the model decides what goes in and the platform copies no string in), the commands (CommandRow{id, name, description, evidence_refs}) and the C2 channels, which now carry their endpoints and citations; the conclusion is no longer asked for. No section's prompt reads another section's answer or anything one changes, so the sections are written at once where llm.parallel_analysts lets the reporter's models serve concurrent requests and one after another where it does not, with the same requests either way; each section's answer, findings, degradation sentences and flagged sentences are applied in the fixed section order (ReportComposer._author_at_once, _settle). Every section's contract (composer.section_contract) says that a list item is written only with a value and never with nulls, and that a value is a JSON string, numbers included: a configuration section whose items carried "value": null — as the contract then allowed — failed its schema twice and was dropped. Five checks across the composer and the narrative round are shown to the model once through the existing retry-with-feedback and recorded unresolved when they survive, and none drops what it is about: narrative.ungrounded_finding (a key finding cites an id no ledger entry carries), report.flow_voice (a step marked observed cites no sandbox entry; or cites one beside entries that are not sandbox entries, since every statement of an observed step is one the sandbox watched; or names an address or a host no flow of the sample's process tree reached, by evidence_bundles.sample_flow_fact, a name judged by the addresses its DNS answers gave (NetworkDomain.resolved_ips); or states persistence where the sandbox watched the registry and the files and recorded none, the fact the Persistence section prints as "no persistence observed", evidence_bundles.sandbox_saw_no_persistence), report.persistence_not_observed (the Persistence section's prose states persistence under that same fact with no word that it was not observed in this run; asked once with the fact and the sentence's start), narrative.unpublished_indicator (the narrative round's: a recommendation's action, rationale or detection names an address or a host the IOC table does not publish, a well-known reference host no row holds aside; asked with the table's answer), narrative.unpublished_technique (the narrative round's: a recommendation's action, rationale, detection or technique column names a technique id the report's ATT&CK table does not publish; one question per recommendation, naming the ids), report.configuration_uncited (a value said to be decrypted or observed cites no entry), report.identifier_uncited (a host identifier cites no entry of the run), report.value_not_in_cited_entry (a host identifier's or a configuration value's whole value is in none of the entries it cites; a configuration number is held in decimal or hex, or by its number beside a known time or size unit, and a field name written with its value by the entry's pair of the two; rows citing the same entries are one question, a kept row marked beside its evidence) and report.unpublished_value (a section's prose — a body, the introduction, a flow step — names a network value the IOC table does not publish with no no: <reason> beside that value; one question per section, each state said once with its values and sentences; each kept sentence marked in place with its own values' states). A configuration, identifier or endpoint cell is not asked about: the report prints the IOC table's state beside an unpublished value in it. A field a model did not supply is absent from the report. The recommendation's category is the model's own. The Markdown prints the host identifiers in §9 under the report model's voice, unpublished, and the console draws them in the technical-analysis panel.
• What a technical section is shown, and when it is asked. A section's analyst claims are picked by its keywords (evidence_bundles.mentions): a keyword shorter than six letters matches a whole word or a word's prefix, words split at camel case (rsa in RSA1 and rsaenh, encrypt in CryptEncrypt), or a word's end with a plural, verb, agent or API suffix after it (rc4 in ARC4, key in pubkey, http in winhttp, task in schtasks, hash in apihashing, mutex in createmutexw), never inside another word (rsa in rehearsal), never in an ordinary word that ends with it by chance (key in monkey, rsa in versa) and never starting or ending inside a number written in hex (c2 in 0xC2C4); a longer stem matches anywhere (obfuscat in deobfuscation). The communications, command-and-control and configuration sections are shown entries_holding beside the run's urls, domains and ips: each value with the answered entries whose captured output, one-entry section or self-naming table row holds it, read once per report and only for the wanted values, so a section can cite the entry behind a value whether or not an analyst did; a value no entry is known to hold is left out. The encryption, discovery and evasion sections are shown sandbox_called_<category>_api_count beside the import profile's count: the APIs a sandbox API reading (kind sandbox_api_calls) recorded called, by the category an API catalogue answer of the run (kind api_catalogue) gave each name (DynamicBehavior.api_capabilities), so a sandbox-only crypto call asks the encryption section. A zero count is not shown and asks nothing. The encryption section is also shown crypto_finding_entries: every answered entry of a crypto-finding kind (crypto_constants), whichever server or pack step wrote it, so a published constant set found in the file asks the section; a run with none is shown what it always was.
• A decompile figure draws code. A code-listing figure draws a JSON answer's code field, read at the declared values.code path (inside the declared rows) or among its strings at any depth that read as code (the one, or of several the one under a code-ish key, else the longest), with its own line breaks. Code is read by its shape: pseudo-C (a brace, a call, a statement ending at a line's end or before a brace) or two disassembly lines each led by an address, so prose holding numbers is no code; a field under a code-ish key (disassembly, listing, asm, code) also reads as code with three or more lines of mnemonic-and-operand shape and an operand mark (two operands joined by a comma, a memory reference). A JSON answer whose code no one string carries is drawn whole, as it always was; a JSON object holding no code (a search's hits, an error record) is not drawn, and a plain text answer is drawn as it always was. An answer cut for storage is read to the cut, an escape the cut split left out and the cut's mark kept out of the listing, and the figure says the answer was cut. The caption names the call's symbol, else its address argument, declared or named for an address (name_or_address).
• The report stage derives its budget as the judge does. A section's and the narrative round's output budget (core.container.composer_output_budget, report_stage_budget, llm.context_window.report_output_budget): the operator's reporting.composer_section_max_tokens for a section (plus the reporter's cap as reasoning room where thinking is left on), else the reporter's llm.judge_max_tokens, else the one derivation every role's cap follows (derived_reply: the smaller of a quarter of the window and the model's declared maximum output, a quarter of the window for a runtime we run, the documented 8,192 for a hosted API that declares nothing), so the prompt keeps the rest of the window. Never more than the model's maximum — its declared maximum output, or its window when it declares none — reasoning room included. A section's evidence gets what a learned window leaves after the budget, never below zero (a fallback window sizes nothing); each call is held to what the window leaves after its own prompt when the budget would not fit beside it (context_window.call_output_bound); facts that do not fit record a degradation and the section is still asked. The narrative round takes the same budget and its wait is sized like a section's (NarrativeAgent.round_timeout, narrative:round in Appendix B). Every list a section's model writes is kept whole. The derivation is logged per section and printed in Appendix B beside the section's wait ("Output budget of composer:section"). A fixed budget dropped a section of a live report when the model's answer outgrew it, and a budget sized at the declared maximum alone gave a model whose maximum output reaches its window the whole window, leaving the prompt no room. No section schema and no report prompt sets an upper size: the prose fields, the executive summary, the key findings and the recommendations keep only their lower bounds. An answer the cap cuts is told so — composer.cut_at_output_cap, naming the cap, the answer's size (characters, items begun, and — when a text field holds fewer values than items were begun — how many of them, at least, repeat a value in each text field) and its first 160 characters, and asking for an object that closes well inside it, each item once, short phrases, one line — and asked once through the existing loop. The question replaces the cut answer rather than following it, so the retry is the first prompt and one short turn; it is sent only when that leaves the section's output budget free in the window, and otherwise the degradation reason says it was not asked. Only this question is sized so; every other question keeps the answer and is sent as before. How far each cut answer got (characters, items begun, how many of them distinct) is logged and, when the retry is cut too, carried into the degradation reason. Every list contract asks for each item once on one line, and an answer with rows alike in the fields that tell items apart is asked once (composer.repeated_items) to confirm whether they are repeats, with how many rows are alike and which; it is never told to remove a row, and what comes back is kept as written, repeats and all, with the finding recorded. The fields: a host identifier's kind and value, a configuration key and value, a command's id and name, a flag, a channel's name and endpoints, and a whole flow step — its order included, so a loop that numbers each repeat anew is not caught. The one retry asks every finding of the first answer together, in one question. A finding only the retry's answer raises was never put to the model: it is recorded with "Not asked: it first appeared in the answer to the section's one retry …" (composer.ONLY_IN_THE_RETRY), and its marks say not asked. The host-identifier contract asks for the kind by what the entry shows the value is: a registry key or value only under a registry hive, from one of its top keys (Software\, System\) or where the entry records a registry access, String where it does not show.
• When no summary was written, the report says why and writes none. The fallback that filled the summary, the capability paragraphs and a recommendation from a template is gone: its sentences read as the report model's. The reason is recorded once among the degradation reasons (the report model wrote no summary: …), and §1 prints it and lists the verdict's facts with the voice of each. tests/unit/test_no_silent_overrides.py pins the one module each model-written field may be written from.
• The severity score is gone. It was the rating read through a fixed table and printed as a number out of ten nobody stated; SeverityAssessment ignores it on a stored report. A stored conclusion's sophistication rating is printed beside the verdict and its text, which restated the summary, is not; stored capability paragraphs print under the technical analysis's lead-in.
• pe_info reports each export's ordinal and address, the export directory's name and the version resource's naming strings; the identity carries the architecture, whether the image is a library, those names and the header's timestamp, printed as a header value that can be forged. A report stored before the identity carried them reads the same measurement from its pe_header section. One binary read twice — the triage pack's pe_info and the analyst's own, capa run by both — is projected as one section table, one import table, one export list and one set of rule rows.
• The sandbox's voice is used only over what a sandbox recorded. A run whose sandbox tools answered with empty lists — a mock with no fixture for the sample — has no observation, and the report says so in the run's own voice ("No sandbox observation: the sandbox tools returned nothing for this sample, and nothing in this run shows it was executed"), with the reason the run recorded; §6 is then tagged Measured, and no "no persistence observed" line is printed. The execution-flow check reads the same thing: the sandbox entries an observed step may cite are those whose answer recorded something (evidence_bundles.sandbox_entry_ids), and a network answer (the flow table, the capture) only when the network block holds a sandbox row the sandbox attributed to the sample's process tree: without one it holds the guest's traffic, and one run marked a C2 step observed on an unattributed capture. A sandbox_report_section answer is classified by the section it filled: the network, DNS, HTTP, flow, host and capture sections are network answers. Process, file and registry answers keep their meaning. Any one attributed flow admits every network answer; a check that the step's own address has an attributed row is not made. So a step citing a mock's empty answer or an unattributed capture is asked about and, if kept, printed with the report.flow_voice note; a run with no observation prints that note beside every step marked observed. The narrative and composer prompts say an empty sandbox answer is not an execution. What the model writes anyway is printed as written.
• A technique's source is everyone who named it. The ATT&CK table's Source column is the rules that asserted it (capa (rule match)), the analysts that claimed it and the capability matrix's own layers — the judge's verdict among them, which the corroboration does not count; the agents a judge relationship credits are not sources. CapabilityCell.confidence is None when no producer put a number on the technique (a judge attack-pattern or relationship with no confidence, a rule-only technique), and the row then reads "rule match" or "not given" rather than a confidence of zero; a stored cell carrying 0.0 with no producer reads the same way. confidence_source names the producer of the number and is appended in step with it, so a relationship with no number never names the judge as the producer of an analyst's. An unresolved stix.credit_without_claim about a technique prints beside its row, as the attck.* findings do. A finding is matched to a row by what it is about: every technique check sets the violation's subject to the technique id, and the row takes the findings whose subject is its id. A stored row without one matches only the TECHNIQUE <id> its message opens with. An attck.unknown_id message names the closest real techniques, and matched on its words it printed "unresolved" on their valid rows. An id the catalogue rejects is not published and says why: "no entry for this id in any domain", or, for an id data/attck_retired_ids.json carries, what happened to it (attck_loader.retired_reason: the release that retired it, the bundle's own revoked or deprecated mark, the id that revoked it). The generator records every attack-pattern the bundle carries as revoked or deprecated, with that status, beside the ids a release diff saw go.
• qa/fp_linter.py runs last and reports; it changes nothing. Its findings land in run_summary.fp_warnings, including C6 (a section or TTP row with nothing citable behind it) and C7 (a technique id the validation loop could not get resolved).

The API renders the report as Markdown, HTML and PDF, and exposes the STIX 2.1 bundle, a MITRE view, the extracted indicators, the detection signatures that fired and a timeline. Post-hoc enrichment fills VirusTotal, AbuseIPDB, WHOIS and GeoIP reputation into the indicator set after the verdict has shipped.

Every rendering is made on request from the stored report, and nothing is kept beside it: there is one source of truth and no second copy to go stale. The report node renders its own markdown too — the CLI writes that one to a file — but it renders it from the same object, after the last field the renderer reads has been written, so the two agree at the moment the run ends. They are not promised to agree forever, and should not be: the enrichment job rewrites the stored report afterwards, the served rendering follows it because it is made on request, and the file the CLI wrote stays what the run itself produced. That ordering is the fix for a served report that printed 24 claimed, 24 published over four published techniques, carried no section naming the twenty it did not publish, and gave 311.7 s as a 396.3 s run's elapsed time: the run summary's last four fields — the validation block, the corroboration's published marks, the stage rollup and the elapsed time — were written after both the render and the snapshot the worker stores, so the column the console reads was right and the report the API serves was a snapshot taken a minute earlier. A report stored before that ordering keeps the figures it was stored with; nothing is backfilled, and its run-summary column — which is what the console draws — was always the final one.

/reports/{id}/iocs is a feed another system acts on, so by default it returns what the publish rule would publish — the same rule the STIX bundle is built with, asked of the same values, so a name only the sample's own byte image knows is not offered to something that would block on it. include=all returns everything and include=unpublished only the withheld rows. Every row carries its source and a published flag; IOCEntry declared neither, so FastAPI dropped the source the service had always attached and the distinction never reached a consumer. A value a judge indicator names is a row whose source is judge, with the one publish rule's answer — the answer the export acted on — and may be of a kind the network block has no rows of (email, path, registry, mutex, command, or a hash of another file).

Every row in the network block — a domain, an address and a URL alike — records where it came from: sandbox for something the sample resolved, reached or requested, analyst for something an agent put in an artefact, strings for a run of bytes in the file that has the shape of one. A row that records nothing is read as strings, because that is the weakest claim and reading "unrecorded" two ways is how one reading publishes what the other ranks as noise. The last is the weakest claim there is, so a strings domain is printed in the report — in its own Source column in the Markdown table and as a badge on the console's domain card — and left out of the STIX indicator set and out of the reputation lookups until a second source knows the same name. One predicate decides that, and both paths that mint a domain indicator ask it: the network block's own, and the string rows that reach the bundle through static.interesting_strings. A Tor address is corroborated by its own syntax, because .onion never resolves and no sandbox can confirm one; the indicator it mints carries the reason it was admitted.

Addresses go through the same predicate (ip_corroboration_reason), and until this they were the one network kind with no gate at all: every run of digits the string sweep read as an address was published, charged to a reputation provider and — once the export's cap began ordering by how strong an origin was — ranked as though a sandbox had watched it, because an address carried no origin to read. One live bundle published 6.0.0.0, a version number out of the strings table. address_is_publishable answers the question no source can answer for:

100.64.0.0/10 is named rather than reached through is_private, which answers False for it.

URLs record their source the same way and go through the same predicate, asked of the URL's host (url_corroboration_reason), plus one question no source can answer for: whether the host could exist at all (host_is_public). One bundle published http://localho, http://schq, https://q, http://3271 and https://fs01n5.sends as url:value indicators.

The host question is syntax, and deliberately the weakest question in the chain. A valid Tor address passes it first and on its own checksum, for the reason the domains have that carve-out: .onion never resolves, so nothing can ever be its second source, and a name merely ending in .onion is not a host either. An address literal passes unless it is loopback, unspecified or link-local. A name passes when it is not a reserved name or suffix, every label is a label, and its last label is a suffix rather than a word — two or more letters, or a punycode label. It also refuses the suffixes that name a private network's own machines — .internal, .alt and .home.arpa, which are reserved for it, and .lan, .home, .corp and .intranet, which are not reserved by anybody, have never been delegated and are used for it anyway. Publishing one is a low-value indicator in a shared bundle and a small disclosure of how the analysis network is named.

One list answers that, host_is_private_use, and the enrichment's lookup gate reads the same one. The two kept their own lists and answered differently, which stopped being a tidiness problem the moment the projection stopped dropping observed rows: a sandbox that resolved x.alt or localhost.localdomain was held out of the bundle and posted to a public reputation provider in the same run, which is the disclosure the lookup gate exists to prevent. The one name the two still answer differently is a Tor address, and deliberately: the export carries it on its own checksum, and no provider can resolve a hidden service.

That is an export decision, and it is made where an indicator is minted. Made at the projection instead, it erased the observation: a sandbox-observed fileserver.corp.internal never reached report.network.domains at all, so an analyst reading a lateral-movement case could not see which internal host the sample resolved, while the URL carrying the same host survived and was refused at the export with a row beside it. Nothing a sandbox, an analyst or the judge observed is dropped at the projection now: the row keeps its place in the network block with the source that saw it, and the export records stix.unpublishable_endpoint — a name that does not resolve outside the analysed network. A name only the string sweep produced is unchanged, held back by _is_emittable_domain at the projection and silent, because a run of bytes ending in .local is not an observation of anything. The last label's rule is not membership in a list of TLDs somebody wrote down: the list this replaced omitted gov, edu, mobi, every punycode TLD and most of two continents' ccTLDs, so a sandbox-observed request to a university host was dropped from the export with nothing said about it. Four of the five above fail this question; fs01n5.sends passes it and is held back by the corroboration rule instead, which is the true reason and the one recorded.

One function writes a STIX pattern for anything this platform mints — stix_renderer.indicator_pattern — and one answers whether this run may publish it: indicator_publish_reason. Every minting path asks it: the network block's own rows and the string rows that reach the bundle through static.interesting_strings. It was three rules on four paths, and the fourth — a StringIOC of kind ip, which the deterministic IOC extractor produces on every sample — asked none of them, so 6.0.0.0 was refused by the network block and exported by the string scan two sections later, typed malicious-activity.

The rule answers for every kind the sweep produces, not only the three network ones: url, domain, ip, email, path, registry, mutex, command, secret, crypto_wallet and other — the set STRING_IOC_KINDS names, which mirrors StringIOC.kind. The other kinds used to fall past the predicate into the cap's file-name band and be exported with nothing asked, so a run that concluded a signed PuTTY is Benign published ten SSH algorithm identifiers as malicious-activity e-mail indicators, and a PE run published a third party's address lifted out of embedded library source. Two halves, in this order:

• Could it be the thing it claims to be. A host that could exist (host_is_public); a mailbox whose syntax is an address and whose domain part passes that same host rule (email_is_publishable); a path that names a file rather than a directory or a root (path_names_a_file). secret and crypto_wallet have no STIX object and so no pattern; they stay in the consolidated IOC table.
• Does anything but the sample's own byte image know it. A domain asks the network block's own answer; every other kind asks the run's corroborating record — what a sandbox watched (the process tree, the registry modifications, the file operations, the notable APIs), what a persistence mechanism names, and what an analyst established in an artefact or a finding section. The report's own tool sections are deliberately not in it: they are the string sweep arriving under another heading, and a haystack holding them would answer yes to everything.

Validity removes what cannot be the thing; corroboration decides the rest. For a string-derived value the second question is the one that carries the weight, and it is meant to. The validity questions are deliberately shallow — could anything answer for this host, is this syntax a mailbox, does this name a file — because a string sweep produces values nothing can tell apart from the real thing by looking. [email protected] is a fragment of Python written entirely in lower case, and there is no honest rule that separates it from a mailbox at a two-label name: the last-label test is a shape rather than a list of TLDs for the reason given above, and a list of language keywords or method names would be a guess dressed as a check, wrong for every language nobody wrote down and wrong the day one of them names a real host. So it is not written. Such a value is published only when a second source records it, and a reader who finds one in the report's own string table and not in the bundle is looking at the rule working.

What a minted indicator claims is one function, minted_indicator_type, for every kind. The sample's own hash indicator is the verdict's word exactly (indicator_type_for); everything else is anomalous-activity unless the row itself was flagged suspicious and the run's verdict is Malware, in which case it is malicious-activity. benign is the sample's own word and is not lent to anything else — a host a benign sample talked to is not thereby a benign host. So a corroborated string-derived artefact is anomalous-activity under Malware, under Suspicious and under Benign alike. Nothing is malicious-activity by default; a URL used to be, whatever the run concluded.

An address a person owns never leaves the report. A string-derived e-mail row that nothing corroborates is in the report's own indicator-strings table and in the consolidated IOC table, and in nothing else: not the STIX bundle, not /reports/{id}/iocs (which serves the hashes and the network block), not an enrichment lookup (which reads the network block's domains and addresses), and not an event — a string sweep's row is declined silently, because a report carrying forty unresolved findings nobody can act on buries the ones somebody can.

tests/unit/reporting/test_one_network_publish_rule.py walks the tree for a literal that builds any of those patterns and fails if a second place starts doing it.

The judge does not mint patterns, it writes them, and its own indicator objects are asked the host question and not the corroboration one. The judge's assertion is the source, so the corroboration half would answer trivially, and letting "the judge said so" count as a second source is a claim this code should not make on the judge's behalf. The host question is the half that does not depend on who wrote the row down, so all three kinds are asked it: host_is_public for a name and for a URL's host, address_is_publishable with the judge as an observing source for an address — which is why a private address the judge cites out of the sandbox's evidence stays and loopback never does. Asking it of URLs alone exported [domain-name:value = 'localhost'] and [ipv4-addr:value = '127.0.0.1'] from a judge bundle while every other path in the tree refused the same two values. A pattern is not one comparison, so every value in it is asked — [a] OR [b], an AND of two object paths, an IN list — and an indicator with one unpublishable endpoint in it is declined whole, and a value reached through a reference is one of them: network-traffic:dst_ref.value and domain-name:resolves_to_refs[*].value carry an endpoint and are asked whichever of the two questions fits what is written there. The object type is read whatever case it is written in. A comparison whose right-hand side is not an endpoint at all — MATCHES, LIKE, ISSUBSET — is declined too, with the reason that is true of it: it names every endpoint that fits it rather than one, so this export could not ask whether it may carry the endpoint; a comparison the reader cannot read at all is declined as one whose endpoint the pipeline could not read, rather than guessed at. A shape over a kind the publish rule answers for that is not an endpoint — a command line, a registry key, a mutex, a digest — is declined for the same reason under stix.indicator_not_published: the rule answers for a value, and LIKE '%whoami%' is not the value whoami. The IOC table and /iocs read a value only from an = comparison, so a LIKE indicator lists no row there.

A pattern is kept whatever its operator, and one the grammar refuses is asked about. The judge's integrity pass drops an indicator only when its pattern is empty. It used to keep only patterns containing =, and a reference judge that wrote its command-and-control hosts as [url:value LIKE '%host%'] had twelve of thirteen indicators dropped as empty_pattern, with their relationships, before any rule saw them. Whether a pattern is one the official validator accepts is schemas.stix_pattern.pattern_refusal: the STIX 2.1 pattern grammar read over the one reader's quoted values — observation expressions, AND/OR/ FOLLOWEDBY, the three qualifiers, every comparison operator, IN lists, EXISTS, the typed literals — and the official validator (stix2-patterns, pinned in the runtime dependencies). Where the validator can be imported, which is every install from the lock, its verdict is the whole answer, acceptance and refusal — [file:name == 'x'] and [NOT EXISTS file:name] are the grammar's own. The grammar reader answers only where the package cannot be imported, and agrees with the validator on acceptance for every pattern the tests hold it to except a digest of the wrong length written as a hex literal (h'…'). A pattern the grammar refuses — cut short, [file:name], [file:name =], a value in double quotes, text after the expression closed — is asked once (stix.pattern_refused, in the grammar's words, when no more specific pattern question named it) and, kept, declined as stix.unpublishable_pattern; it is never exported invalid. A trailing backslash that escapes a value's closing quote is asked, not dropped.

The publish rule answers for every value a pattern names over a kind it covers, whatever the operator: =, each member of an IN list, and the operand of !=, <, >, <= and >= (stix_renderer.rule_values). An IN list or a != used to reach the export with nothing asked, so a value refused as = was published inside one. The IOC table and /iocs still list = values alone.

A LIKE or MATCHES over an endpoint or a kind the rule covers whose fixed text — the text between a LIKE's wildcards, or a MATCHES expression that is only its text (matches_fixed_text) — is one run the evidence holds as a value of its own, or one another of the judge's indicators writes with =, is asked once (stix.shape_names_a_value) whether the judge means that value: "write domain-name:value = 'host', or keep the LIKE and it is not exported". The suggestion names a form the one publish rule answers for: a host a url shape was written around is suggested as domain-name:value (an address as its family), because url:value = 'host' is not a URL and the export declines it as one before the rule is asked; a whole URL stays url:value. A MATCHES is grounded by its text where it is only that, and otherwise neither grounds nor refuses; a URL with no scheme is declined as not a URL. What the judge keeps is declined with the record, as before. The grounding check reads a LIKE value for the text between its wildcards (like_fixed_text): each run of it must appear in the evidence, and an absence names that text, never the wildcards; fixed text shorter than four characters grounds nothing, because it is found in any evidence. A quoted value that writes a backslash the grammar cannot read — STIX escapes only the quote and the backslash, so 'Software\Microsoft' with one backslash is refused whole by the official validator — is asked stix.unescaped_backslash and, kept, declined as stix.unpublishable_pattern; the reader still reads it as the backslash it means, for the other questions.

One reader answers what a pattern says, for the export and for the grounding check both: schemas.stix_pattern.read_comparisons, which returns the object path, the operator and the literal of every quoted value in it. Two readers had already drifted — one decided a quoted key structurally, the other from the property name — and neither read an escaped quote, so [file:name = 'it\'s.exe'] was read as the value it\ and the judge was told its own row appears nowhere in the evidence. A quote that opens where the object path is still being written is a key (file:hashes.'MD5', file:extensions['pe']); a qualifier's own literal (START '…' STOP '…') belongs to the qualifier and is not credited to the comparison before it. A syntactically routable address the judge invented passes this question by design; whether any evidence holds it up is stix.ungrounded_indicator's question, and that check is asked of every indicator the judge writes.

The same validity questions reach the judge's other kinds. An email-addr pattern is asked whether it is a mailbox at all and whether its domain part could exist; a file:name pattern is asked whether it names a file rather than a directory or a root — both declined as stix.unpublishable_artefact when they are not. A directory:path comparison is asked two questions of its own, and told which one it failed. The first is validity — could this be a place on a machine: it has a root (a POSIX slash, a drive with either separator, a share, an environment variable, a home tilde, a registry hive) and at least one named step under it, and every step is written the way a name is, not empty, not whitespace, not a format specifier a sample was compiled with, with at least one of them carrying two characters running. /tmp is a directory; / and C:\ are roots with nothing under them, and /%s/%s and / / are what a strings table produces by the dozen. The second is grounding: the literal is asked the corpus question every other literal is asked, as a whole value and under the spellings that mean the same location (reporting.dedupe's own path normalisation), because a path is written with whichever separator its writer's platform uses. A directory used to be refused with the file-name sentence, which told the judge its own directory row has no file extension … so nothing says it is a real path, and the judge spent its one retry on an untruth. A file:hashes comparison is asked whether the literal is a digest of the algorithm it is written under, by length and alphabet (HASH_HEX_LENGTHS), and declined as stix.malformed_hash when it is not: one run exported sixteen of the thirty-two characters of an MD5, a value a consumer matching on MD5 can never match. The grounding check asks the same question first and then matches a digest as a whole token, never as the prefix of a longer run of hexadecimal, because a truncated digest is not "present in the evidence" however the substring search answers. An algorithm the table does not name is left alone.

Before any of that, the object type. A pattern compares a property of a STIX Cyber-observable (schemas.stix_pattern.CYBER_OBSERVABLE_TYPES) or of a custom x- type; one live export carried [ipv-addr:value = '82.157.13[.]47'], a type no consumer holds objects of, and because the endpoint table above lists only the paths it knows, the address was never asked the host question either — the same misspelling around 127.0.0.1 would have exported a loopback. The judge is asked stix.unknown_observable_type, with the type the value is named when the value or the spelling says (82.157.13[.]47 is an ipv4-addr) and the list of types when neither does; nothing rewrites the pattern. An indicator that keeps the type is declined as stix.unpublishable_pattern. A type is read as written — STIX types are lower case, so IPv4-Addr is not one — and the path after it must be one the type defines (SCO_PROPERTIES, SCO_EXTENSIONS): [file:extensions['pe'].pe_imphash = …] names an extension a file does not have, is asked stix.unknown_object_path and, kept, is declined the same way. Its indicator_types is asked about under stix.indicator_type_vocabulary when a value is outside STIX's vocabulary — the same run typed the address ip-addr and a file name file, the kind of value where the vocabulary says what the value indicates — and, the vocabulary being open, what the judge keeps is published as written.

What the corpus is. The grounding checks search what the run saw, not what its ledger kept. reporting.evidence_budget_bytes blanks an entry's output once an agent's answers pass it — after the model has read them — so a corpus built from stored entries once told a judge that a C2 a tool really returned appears nowhere, and the indicator was dropped. The container keeps every tool answer as the model received it (after the output shortener, before the budget) in memory, for the length of the job, never in the graph state and never persisted, bounded by reporting.evidence_corpus_bytes. The judge's grounding corpus and the export's second-source test both read it; the stored entries are the fallback for a run whose corpus is gone.

And what an absence may say. Past the ceiling, with no corpus at all, or over stored entries of which any was blanked, the evidence searched is not the run's whole record — and the platform does not assert an absence over evidence it knows is partial. The finding is then advisory: the judge is told once, in a sentence naming how many answers were not kept and from which tools, and nothing drops its object for it. drop_ungrounded_indicators reads the flag, and a source guard fails any other consumer that decides a removal from an ungrounded row without asking.

And what it held. Beside the loss, run_summary.truncation carries evidence_corpus_answers, evidence_corpus_bytes_held and evidence_corpus_bytes_ceiling, read off the corpus while the container still has one. The three are absent on a run that recorded none of them — a summary stored before they existed, a run resumed without its corpus — because zero would say the corpus held nothing. The run summary's Bounds Hit section, the report's limitations section and the console's "what the run spent" print them only where they tell a reader something: a corpus that went partial, or one past half its ceiling. Otherwise the record carries them and both surfaces stay quiet.

Two rows that mean one path are one row. reporting.dedupe.canonical_path normalises the separators, collapses runs of them, drops a trailing one and folds the case of a Windows path — Windows filesystems are case-insensitive, a POSIX one is not — and pattern_fingerprint uses it for file:name, directory:path and windows-registry-key:key. The first row is kept with the union of the sources, as every merge in this project works. One recorded bundle carried the same directory twice, once with the trailing slash and once without.

Two STIX indicators are one when each comparison they make is the same comparison. pattern_fingerprint reads the pattern with the one pattern reader (stix_pattern.canonical_pattern): the syntax around the values is folded and its whitespace closed up, and each value is folded by the kind of its own object path — a digest or a host name folds its case, a path follows the path rule, a URL or any other property keeps its case, and defanging is undone. A space at a value's edge is dropped only for a digest, an address, a host, a mailbox or a URL; a mutex or a file name keeps it. A LIKE value folds only its case, for a case-blind kind or a Windows path, and is never refanged. A MATCHES value, a value the reader cannot read and a pattern in another language are kept as written, so a doubt leaves two rows rather than one.

Whether an endpoint that could exist is published stays corroboration_reason's decision. A URL, a name or an address the host question refuses is recorded as stix.unpublishable_endpoint when a sandbox, an analyst or the judge is the one that recorded it — the report's own network block and the judge's own bundle both left unchanged. One question, one code, and the sentence beside it names the kind: the same decision used to be filed under stix.unpublishable_url and stix.unpublishable_domain, with the second of them covering addresses too. A run stored before that keeps the row it wrote, and the console reads all three as the export's own decision. A row held back only for want of a second source is the rule working and is not a finding, and neither is a string sweep's own cut-off: a report carries up to forty of them, and forty unresolved findings nobody can act on bury the ones somebody can.

Every model-written value on this path — a URL echoed into a decline, the judge's own verdict word, the category it invented, the type of an object the bundle cannot hold — goes through pipeline.events.safe_finding_value. A validation row, a degradation reason and an export decline are report text. With the operator's configured values registered (the worker registers them per job), a row keeps the evidence's words and loses every operator credential: each configured value by value (a short one as a whole word, one under four characters only as the word after Bearer, Basic or token), a URL's userinfo and each credential-named query value. Registration reads a configured URL's password of any length, a token in its username slot and its api_key, apikey, access_token, token and key values. With nothing registered, or a scope whose values could not be read, a row is held to the whole event scrub; outside the worker (the test suite, the command line, the MaljanApp facade before it registers) rows therefore keep the event scrub's masking. The scrub never masks a technique or tactic name of the vendored ATT&CK table: after Bearer, Basic or token it keeps the next word of such a name as written ("Access Token Manipulation"), each alternative of a slash-joined one ("Token Impersonation" and "Token Theft" of "Token Impersonation/Theft") and a technique or tactic id of the table ("Make and Impersonate Token (T1134.003)"), and it reads a one-token name standing as a whole run ("SyncAppvPublishingServer") as a name, not a key, unless a credential label stands right before it (password=), as for a family name. Anything else after those words is masked as before. A configured URL's username without a password is registered only when it has a credential's shape by the scrub's own rules, so a user name such as administrator stays a word in events and rows; rows still lose every URL's userinfo, and a credential-named key in a URL's query or fragment. The bound never leaves the head of a value the scrub masks, and the event that carries a row is scrubbed by the publisher like every other.

No count bounds the indicators the export carries: it carries every value the one publish rule publishes, which is every yes row of the IOC table, and no band ranking drops any of them. A total cap of fifteen (MAX_TOTAL_INDICATORS) and a cap of ten file names used to drop the lowest-ranked indicators, so the table and /iocs said yes for values the bundle did not carry, and a slice of fifty string rows stopped the string path early. The integrity pass still runs over the assembled bundle, deduplicating an indicator written twice (a corroborated string row and the network row that corroborated it; the queue order makes the observation the one that survives). The two constants are now the report linter's counts: its C4 warning states how many file names and how many indicators a bundle carries when it passes them, and drops nothing. The run summary's "STIX indicators over the cap" row reads 0 for a run exported this way.