WATCHTOWER
ONLINE
A COMIC-BOOK LENS ON JAMES' ENGINEERINGISSUE 001
Before an AI can help, the help desk has to work.
A fictional enterprise gives the system a world. The engineering underneath is real: identity, directory trust, a service desk, and one controlled ticket followed from request to closure.
J-Bot and Twilight are storytelling figures here. They did not build or operate this live lab. James designed and built the environment; the case below separates observed behavior from work still in progress.
Independent fictional lab setting. No DC affiliation or endorsement. Original cover artwork.
The first ticket is a systems test.
Can a domain user open a support request, receive a technician response, and accept the outcome—before an AI operator is allowed anywhere near the workflow?
A human-operated baseline.
The lab joins a Windows identity authority, a domain workstation, and a separate service-management application. GLPI uses a directory read path over LDAPS; it remains the ticket system of record. That division makes the trust boundary visible before any AI integration is attempted.
AI comes after the workflow.
A successful login is not a resolved support request. The pilot followed one synthetic ticket through submission, technician action, solution, and requester acceptance. That gives future AI work a human-operated process to measure against—not permission to act in it yet.
What the record supports.
The October 7 lab record, committed as a65ffe4, documents the pilot through requester views and read-only server checks. This page summarizes that record; private screenshots are withheld until a public-safe exhibit is prepared. One synthetic workflow is not production-readiness evidence.
- 01
The organization has an identity source
JL-DC01 provides Active Directory and DNS. JL-WS01 was joined to the domain and its secure channel was checked.
Recorded in lab build notes - 02
A support tool recognizes that identity
GLPI on JL-ITSM01 queried the directory over LDAPS. A synthetic user was imported and authenticated in the October 6 pilot.
Pilot observation - 03
A requester can make and see a ticket
On October 7, the synthetic user submitted GLPI ticket #1 from the workstation, then opened its requester detail view. The requester list showed it as New.
Requester read-back captured - 04
A technician takes the work forward
The pilot record shows assignment to a technician, a requester-visible follow-up, and a synthetic test solution. GLPI moved the ticket to Resolved.
Assignment and resolution recorded - 05
The requester closes the loop
The requester accepted the solution. The requester view showed approval, and a read-only database check confirmed ticket #1 was Closed.
Acceptance and closure captured
The first ticket went all the way through.
Clark submitted ticket #1. A technician took it, replied, and posted a solution. Clark accepted it, and GLPI marked it Closed. The request was fictional; the path through the lab was real. That is one complete human-run workflow, not a production support claim.
Repeat the route with another role. Then test notification delivery, failed steps, and recovery before an AI operator joins the workflow.