Beacon awake & unattended

Service desk mockup — one ticket, screen by screen

Wireframes of what the architecture blueprint would look like on screen, walking a single password-reset-turned-lockout ticket through intake, planning, the human approval gate, execution, and the audit log — plus the Platform Ops health dashboard watching it all.

These are wireframes, not screenshots. No such product runs anywhere — this box holds no ServiceNow tenant and no real agents executing against infrastructure. Every field, name, and number below is illustrative, built to show the shape of the screens a real implementation would need, not a recording of a real one. See "What this is and isn't" on the architecture page for the full reasoning.

1. Ticket lands in ServiceNow

An end user calls in: their AD account is locked out after too many bad password attempts from a stale saved credential on a phone. ServiceNow opens an Incident and assigns it to the orchestrator's queue, same as it would to any human tier-1 tech.

ServiceNow · INC0043891
INC0043891
New
Beacon Orchestrator
Account locked out — jrodriguez, repeated bad password from mobile device
Identity & Access
J. Rodriguez, Sales
P3 — Moderate

2. Orchestrator drafts a plan

The orchestrator classifies the ticket, identifies the Identity & AD domain agent as the handler, and drafts a plan with a risk tier attached. This is the record a human would see if the tier required approval — here it doesn't, but the plan and its tier are logged either way.

Orchestrator · plan for INC0043891
Proposed action: unlock account & force password reset
Tier 1 — auto-execute
TargetIdentity & AD domain agent · jrodriguez object, corp.local
ReasoningBad-password lockout counter tripped 6x in 4 min from one device; no other risk signals on the account (no concurrent geo-anomaly, no privileged group membership)
RollbackRe-lock the account manually if unlock was in error — single-target, fully reversible
VerifyConfirm AD lockoutTime attribute cleared and a successful logon event follows within 30 min

3. Human approval & arbitration gate

Tier 1 auto-executes without blocking on a human — so to show the gate itself, here's a different, higher-tier ticket: a firewall rule change two domain agents disagree on. This is arbitration, not simple approval: both competing plans are shown side by side, not just one agent's confident answer.

Approval gate · CHG0002217 · arbitration
Two conflicting plans for the same change
Tier 3 — two-person approval required
Add temporary allow rule, expires in 24h
+ allow tcp/8443 10.4.2.0/24 → vendor-api (exp 24h)
Route through existing proxy instead, no new rule
no firewall change — proxy ACL update only
Approve plan A Approve plan B Reject both & escalate

4. Execution & the append-only audit log

Back to the original ticket: the Identity agent executes the approved-by-default Tier 1 plan, verifies the outcome, and closes the ticket. Every step is a separate, timestamped, append-only log entry — not a single "done" status.

Audit log · INC0043891
09:14:02Plan logged · Tier 1 · auto-execute path
09:14:03Identity agent checked out scoped credential (vault lease, 5 min TTL)
09:14:05lockoutTime cleared on jrodriguez; temp password issued via SMS to registered number
09:14:05Credential lease revoked
09:31:40Verification: successful logon event observed · PASS
09:31:41INC0043891 closed · resolution code: auto-resolved, Tier 1

5. Platform Ops health dashboard

What the tenth agent watches, at a glance — the framework's own health, not a target system's. This is the view a human would check on a slow morning, not something that needs staring at continuously.

Platform Ops · framework health
10/10
agents heartbeating
99.97%
30-day uptime
3
endpoints missing patches · staged, awaiting approval
1
config drift detected · core-sw-02, unreconciled
0
circuit breaker trips, 7d
412
Tier 0–1 actions auto-executed, 7d