AxiOwl Evidence Logs Explained
AxiOwl evidence logs are the product's operating memory for message routing. They record what AxiOwl accepted, what it rejected, what it tried to discover, which provider path it handed work to, and where the boundary sits between a local receipt and real provider proof.
That distinction matters. AxiOwl is not a generic chat transcript tool. It is a local coordinator that discovers provider sessions, records them in a registry, sends messages to selected targets, exposes MCP tools for replies, and keeps receipts and delivery evidence. The logs are how an operator can tell whether a send failed because the target was unknown, the sender identity was unresolved, a registry row was evidence-only, the delivery worker failed, or the provider accepted a handoff but still needs end-to-end reply proof.
Where AxiOwl Writes Evidence
The current Windows runtime stores AxiOwl state under the local application data directory:
%LOCALAPPDATA%\AxiOwl
On Linux-style environments, the same path logic uses XDG_STATE_HOME/axiowl when available, otherwise ~/.axiowl.
The main evidence stream is:
%LOCALAPPDATA%\AxiOwl\logs\events.jsonl
AxiOwl also writes a delivery-stage stream:
%LOCALAPPDATA%\AxiOwl\logs\delivery.jsonl
There are related logs for specific lifecycle areas, including:
%LOCALAPPDATA%\AxiOwl\logs\create-lifecycle.jsonl
%LOCALAPPDATA%\AxiOwl\logs\activation.jsonl
Installer diagnosis starts with the same state area: logs, registry, and runtime folders under %LOCALAPPDATA%\AxiOwl. For MSI-level failures, the installer docs also call for a Windows Installer verbose log created with msiexec /l*v.
The Format: JSONL, One Event Per Line
The core EvidenceLog implementation writes newline-delimited JSON. Each append creates the parent directory if needed, rotates an oversized log file, opens the log in append mode, and writes one JSON object followed by a newline.
Every event includes:
event_type
created_at
The timestamp is written in UTC ISO-8601 form. Additional fields are supplied by the code path that produced the event. Keys and values are JSON-escaped before writing, which keeps arbitrary provider names, paths, error strings, and message ids from breaking the record format.
This shape is intentionally simple. Operators can read the file directly, tail it during a test run, or parse it with any JSONL-friendly tool. It is not a hidden database table and it is not a marketing-only "activity feed." It is the local audit trail for routing behavior.
What The Main Evidence Log Captures
The main events.jsonl stream records the significant decisions in the AxiOwl message pipeline.
When a send request enters the pipeline, AxiOwl starts by assigning a message_id and a run_id. It validates the target, validates that the body is not empty, resolves the sender identity, performs targeted discovery repair when useful, and then resolves the target registry row.
The evidence stream includes events such as:
registry_target_miss
registry_target_requires_repair
registry_target_found_after_targeted_discovery
registry_target_still_requires_repair
registry_sender_requires_repair
registry_sender_found_after_targeted_discovery
registry_sender_still_unresolved_after_targeted_discovery
send_rejected
message_accepted_by_axiowl
delivery_handoff_started
delivery_handoff_failed
delivery_worker_request_validated
delivery_worker_delivery_result
mcp_inbound_send_receipt
Those names are useful because they describe real decision points. A target miss is different from a target found but marked not sendable. A resolved sender is different from a raw display name that only looks like a session id. A local AxiOwl receipt is different from provider delivery.
The discovery code also records when a row is only evidence and not a valid target. In the current implementation, local Codex rows discovered from insufficient evidence can be marked non-sendable with an error like:
local Codex row is evidence-only and not a valid delivery target
That is exactly the kind of fact an operator needs. AxiOwl can know that something exists while still refusing to pretend it is a safe route for delivery.
The Delivery Log Explains The Boundary
The delivery log uses delivery_stage records to show the progress of a request across the pipeline. A typical path can include stages like:
accepted
target_resolved
route_resolved
delivery_worker_handoff_started
provider_write_started
provider_write_succeeded
provider_write_failed
provider_handoff_started_unverified
The first stage is intentionally modest. A request entering AxiOwl means the local coordinator received it. It does not mean the provider app displayed the message, processed it, or replied.
The pipeline source records early stages such as request acceptance, target resolution, and route resolution. The delivery worker records worker-side stages such as validating the request, starting provider write, and reporting provider write success or failure. Each delivery-stage record can carry the run id, message id, provider, target, provider session id, node, stage, result, detail, and source.
That gives support work a timeline instead of a guess. If a user says "AxiOwl said it accepted the message," the delivery log can show whether that was only local acceptance or whether the provider edge reported something stronger.
What accepted_by_axiowl Actually Means
AxiOwl is explicit about this boundary in both the CLI and MCP tool descriptions.
When the CLI returns an AxiOwl handoff receipt with accepted_by_axiowl, it means the MCP or CLI request was accepted by AxiOwl. The CLI output states that provider delivery, provider wake-up, and provider reply are not implied unless the delivery path explicitly reports provider delivery status.
The MCP axiowl_send_message tool follows the same rule. Its description says success is an MCP-to-AxiOwl handoff receipt only; provider delivery and reply are not implied.
The main evidence log reinforces that boundary. When the pipeline records message_accepted_by_axiowl, it includes a delivery_receipt value of axiowl_only and a receipt boundary indicating that the record is after target resolution but before the delivery worker or provider proof.
In practical terms:
accepted_by_axiowl = AxiOwl accepted the request and selected a route.
provider accepted = the provider edge reported that it accepted or began the handoff.
MCP reply received = the provider received the message, had AxiOwl MCP available, and replied with usable sender identity.
That last point is the strongest operational proof. The user docs define a correct provider reply as proof that AxiOwl accepted the request, the provider received it, the provider had MCP available, the provider sent a reply through AxiOwl, and AxiOwl could identify the provider session that replied.
Evidence Logs And The Registry
AxiOwl's registry is durable local state, not a disposable cache. It maps names and aliases to provider sessions, including fields such as provider, provider session id, node id, sendable state, source, last-seen and verification metadata, and last error.
The evidence logs explain how registry decisions were made. For example, during send, AxiOwl can run targeted discovery once after a target miss. If that repair finds a valid row, the log records the target found after discovery. If it only finds evidence-only matches, the send fails loudly with a reason that says evidence existed but no sendable exact target row was discovered.
That behavior is a major design choice. AxiOwl would rather produce a clear failed receipt than silently convert stale or weak evidence into a sendable provider route.
Evidence Logs During Install And Provider Support
Evidence is not only for message sends. The installer and release checklist both depend on logs and proof gates.
The Windows MSI installs the AxiOwl runtime, registry directories, logs, and selected provider integration files. Provider checkboxes are supposed to behave as separate features. Unchecked providers should not be installed, patched, closed, restarted, or removed as collateral damage.
This is why installer diagnosis starts by collecting:
%LOCALAPPDATA%\AxiOwl\logs
%LOCALAPPDATA%\AxiOwl\registry
%LOCALAPPDATA%\AxiOwl\runtime
The release checklist then asks testers to confirm that logs are written, stale paths are not enrolled as sendable, missing providers remain unsupported instead of silently passing, and accepted_by_axiowl is not treated as delivery proof.
A provider is only supported when the full path works: discovery, install/config, send, provider receive, provider MCP reply, and correct sender identity. Evidence logs help show which part passed and which part still failed.
How To Use The Logs In A Real Failure
When a send or reply behaves unexpectedly, start by separating four events:
MSI install succeeded
accepted_by_axiowl
provider accepted
MCP reply received
Those are not interchangeable.
Then collect the AxiOwl logs, registry, and runtime folders. Look for the same message_id or run_id across events.jsonl and delivery.jsonl. The main evidence log should tell you whether the sender and target resolved, whether discovery repair ran, whether the message was rejected, and whether the delivery worker handoff started. The delivery log should tell you which stage was reached and whether the result was ok or error.
If the request failed before route resolution, inspect registry and discovery events. If route resolution passed but provider write failed, inspect the provider-specific evidence and error fields. If provider write succeeded but no reply returned, treat that as an end-to-end proof gap, not as a completed success.
This workflow is more precise than scanning console output alone. Console output is useful for the immediate operator. Evidence logs are useful for reconstructing the path after the fact.
Why This Design Matters
AxiOwl connects multiple AI provider surfaces, and those surfaces do not all expose the same stable APIs. Some integrations need MCP config. Some need bridge extensions. Some need provider-specific patches. Remote Linux support has its own boundary, with Codex CLI delivery supported there and desktop GUI provider edges intentionally out of scope.
In that environment, silent fallback would be dangerous. A stale provider row, an old workspace path, or a weak discovery signal could make an unsupported route look healthy. Evidence logs give AxiOwl a way to say what it knows, what it tried, and where it stopped.
The result is a more honest operating model: AxiOwl records local acceptance, delivery handoff, provider write status, and reply proof as separate facts. That makes the system easier to debug, safer to release, and clearer for operators who need to know whether a message really reached the other side.