Evidence Plane

The evidence model keeps “who did what?” readable after the session ends. The goal is not to dump raw logs; it is to keep decision, work, and closure in one product trail.

In desktop operations, opening access is only half the story. The record shows why access opened, which resource was used, when work closed, and what happened during the session.

Events tied to evidence

• Launch decision and denied launch reason.
• Session connect and disconnect.
• Viewer attach or detach.
• Input and clipboard activity, including policy-denied attempts.
• Revoke, quarantine, and kill-switch decisions.
• Command result, heartbeat, and snapshot resource events.

Why this is separate

A session open is a moment. An operation is a chain: the user chooses a resource, the portal decides, the session runtime connects, capabilities are used, and the session closes.

Those pieces happen in different parts of the system, but the product presents them as one trail. That is the job of the evidence model.

What is visible?

You can review who worked, which resource was targeted, which decision opened access, how work ended, and what outcome remained.

High-value records

• Denied launch: explains why work did not open.
• Successful connect: shows that the working surface opened successfully.
• Activity: shows input or clipboard attempts.
• Detach: separates viewer or browser disconnect behavior.
• Disconnect: shows how the session closed.
• Revoke or kill-switch: shows access was intentionally withdrawn.

These records give operations, support, and security review the same language.

How evidence is read

An evidence record explains why a decision was made, which resource it was tied to, and what outcome followed.

For example, a denied launch record does not always mean the system is broken. If assignment is missing or the resource is not ready, refusing the session is the correct behavior. The evidence model therefore covers both successful work and access that stayed closed.

Support and review value

Support can read what the user saw, which resource state applied, and why the session closed in the same chain. Reviewers can see who worked on which resource, when the work happened, and how access ended.

Retention and integrity responsibility

CerberusD handles evidence as an append-oriented, auditable record discipline. Retention, integrity verification, export, and specialized reporting are defined by the deployment policy.

The records provide product evidence for control review. Their legal or certification meaning depends on the deployment, policy, and retention design.

For Cerberus, “the session opened” is not enough. The decision that opened it and the result that closed it matter just as much.