Architecture
Architecture Evolution
Explains why Cerberus evolved from infrastructure management into governed desktop operations.
Cerberus did not arrive at its current architecture in one step. The first need was controlled infrastructure operation: visible records, deliberate actions, and a system that avoids risky surprises. Later phases moved that idea from raw resource administration into governed desktop operations. The canonical end-to-end flow is in Architecture Overview.
That evolution matters because each major architectural choice answers a problem found in the previous stage.
Why it changed
The first question was whether the system was operating safely. Over time, the more important questions became:
- Why did this operation start?
- Who started it?
- Which resource was affected?
- Why did the system refuse unsafe work?
- What record remained after work ended?
Those questions moved the architecture away from connection-first thinking and toward decision-first control.
Architecture changes
| Stage | Problem found | Architecture outcome |
|---|---|---|
| Infrastructure foundation | One operator needed a system that could be run without surprise alarms. | Records, approvals, slower deliberate actions, and evidence discipline became core product behavior. |
| Portal authority | A visible button still needed server-side authority. | Access decisions moved to identity, role, workspace scope, assignment, and resource readiness checks. |
| Modern portal | Old and new screens risked behaving like two separate products. | Workspace, resource, assignment, and session flows moved into one portal line. |
| CerberusLite | Opening a connection was not enough. | The browser session became a governed work surface with input, clipboard, viewer, read-only, and closure rules. |
| Zero Trust handoff | A stolen handoff is not reusable. | Short-lived session permission, one-time handoff, target binding, and revocation became part of the launch model. |
| Evidence and closure | Closing access is as important as opening it. | Launch, connection, detach, disconnect, revocation, and emergency closure became reviewable events. |
| Connection agent and resource truth | A resource that looks ready in the portal still needs verified state. | Enrollment, last-seen signal, state summary, command result, quarantine, and revocation became inputs to resource readiness. |
What the current model protects
The current model keeps three responsibilities clear.
First, access is a server-side decision rather than a button on a screen. Identity, role, workspace scope, resource assignment, and readiness all shape the launch decision.
Second, the resource remains a governed workspace resource instead of becoming a directly reachable target. Work proceeds through the portal decision and browser session.
Third, closure remains part of the product event chain. User exit, browser disconnect, revocation, and emergency closure each carry different meaning and connect to evidence.
What this means in product terms
Daily product flow follows the sequence in Architecture Overview:
- The resource is enrolled and prepared.
- The user-resource relationship is evaluated.
- The session opens only after a positive decision.
- Browser work follows runtime policy.
- Closure and revocation leave a reviewable record.
This makes Cerberus broader than a connect button. The product puts the pre-session decision and post-session evidence in the same responsibility chain.
Result
The evolution can be summarized in one sentence: Cerberus moves dangerous decisions out of the interface and work surface, places them in the portal decision, lets the browser surface execute that decision, and keeps the outcome visible through evidence.
As long as this line holds, new protocols, connection agent capabilities, and observation improvements can attach to the same loop. Decision, work, and evidence remain separate; the product value comes from that separation.