AI Defence / Findings & evidence
Give the decision a clear evidence trail.
The Linux implementation produces structured findings with explanations, business impact and recommendations. These fields help a reviewer connect a technical observation to a practical decision. A unified AI Defence investigation console has not been verified.
What a finding contains
A useful finding identifies the condition and its technical explanation, attaches risk and business impact, recommends an action and includes rollback-description information where relevant. These report fields exist in the inspected Linux source. They are produced by code and should not automatically be described as AI-generated.
The reviewer needs to examine the source context, collection permissions and relevant timeframe. An observation may be incomplete, stale or affected by authorised maintenance. A finding should not be promoted to proof of compromise merely because it carries a severity label.
From observation to an investigation
An operator can compare a configuration or process observation with maintenance records and the host’s expected role. Supporting evidence should explain what was actually examined and which conclusions remain uncertain. That is the basis of the synthetic workflow on the product-tour page.
The inspected AI Defence tree does not establish a deployed incident-search UI, analyst assignments, notes, multi-device case management or downloadable investigation timeline. Those screens are not presented as working product capabilities.
Reporting and exports
The source supports structured reports and messages. A receiving service and any customer export workflow need integration-specific verification. No native SIEM connector, scheduled email report or fixed PDF/CSV export is claimed from these structures alone.
Before using reports in operational decisions, agree which fields leave the host, how sensitive content is handled, who can access the records and how long they are retained. An export format does not by itself establish secure delivery or access control.
Evidence integrity and closure
The central development packages include evidence and audit-related components. Later review identifies incomplete signature verification, observer matching and durability controls. The website therefore avoids claims of immutable records or a proven independent closure guarantee.
The intended discipline remains useful: distinguish a recommendation, a change attempt, a local check and a supported final conclusion. If required evidence is unavailable, the reviewer must be able to see that gap. The tour demonstrates this principle using synthetic records.
The proposed HQ investigation view
The intended administrator view joins the object or device, previous and current state, reason for changed trust, isolation or block decision, remediation result and unresolved verification. It should explain the decision rather than present a stream of opaque AI alerts.
Evidence may include fingerprints, relevant identity, policy/scanner/rule versions, timestamps and bounded telemetry. MSP reporting needs customer-specific scope and tenant isolation. These are architectural requirements for the shared view, not claims that an integrated production console exists.
Questions answered
Talk directly to Altari
Bring the environment.
Start with the right questions.
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.