Independent teaching notes. Not affiliated with xAI or Grok.

Fictional case study

Ridge Route Field

One-line job: help a technician with today's visit, and leave the write tool disconnected because the only login offered was an admin account.

Fictional practice: Ridge Route Field is not a real client, and studying it is not a placement. Say "I studied this fictional engagement." Portfolio policy.

What happened

Andre Pell leads a made-up field team. Technicians wanted today's visit address and a draft of the note they would later type. Andre also wanted the tool to close the job in the system. The only login anyone offered was his admin account. That login can do far more than close one note. The write tool was not connected. The demo did not use his password. The pilot stopped at a written refusal until a technician account exists. Visit label RR-17 is only a name in the story.

In scope and refused

The refusal and the missing account are in scope. A write on the admin login was refused, and nothing shipped. Andre asks the van app to close a job In scope The read, described in writing The refusal, in writing The account that would be required A check that close-job is absent Refused Connecting a write Andre's admin login A personal admin demo Claiming a live pilot
The refusal and the missing account are in scope. A write on the admin login was refused, and nothing shipped.

End to end

  1. Ride along on paper: write what a technician does today. They read the visit on a screen, drive, and type a note that closes the job. The buyer is Andre. The person who does the work is the technician.
  2. Split his ask. The metric he could check without a write: "The technician can read today's visit address for visits on the pilot list." The extra ask, closing the job, is a write. It is not in scope while the only login is admin.
  3. Say the no in writing. If the only offer is an admin account, do not connect a write tool. Do not borrow a personal admin login for the demo. A bearer is the shared secret that route requires. An admin bearer in a field app is the wrong secret.
  4. Describe the account that would be required later, without creating it yourself inside his admin session. A technician role that can write only its own visit note, created for the pilot, is the condition. Until that account exists, the close-job tool stays off the list.
  5. A scripted model that calls close_job is handled as an unknown tool. It is recorded. It is not run. There is no second path that calls the real system "just for the demo."
  6. The security review lists the constraint next to the control. Constraint: admin is the only login. Control: no write tool, no demo against that login, stop noted in the handover. A prompt that says "do not close jobs" is not the control. The missing tool is the control.
  7. Test the tool list in the build you would actually hand someone. close_job is absent. A scripted call to it returns unknown tool and does not change a job. A test that only checks the tone of the draft is not this test.
  8. Do not ship. The handover is the stop note: what was asked, what was refused, which account would unblock a later write, and who has to create that account. It is not a runbook for a system that is live, because this one is not live.

The buyer

Andre Pell, field operations lead. He offered his own admin login because it was the fastest way to show a closed job. The technicians were the people who would have carried the app. Discovery names them even though the pilot did not ship a writer.

The metric he named

Show today's address. Close the job from the van.

Andre Pell, field operations lead. Fictional. The close was refused. No jobs were closed.

"Show today's address" can be checked on a read, once a technician account exists. "Close the job from the van" cannot be checked safely on an admin login, so it is not the pilot metric. It is the refused write. Do not report a count of jobs closed.

In scope and out

The wrong call that was refused

"Use my admin login for the pilot. We will lock it down later." Refused. Later is not a control. Week 5 states the rule this case is built on: if the only offer is admin, do not connect a write tool. The demo must use an account created for the pilot. That account was never created here, so there was no demo against their system.

The security and data constraint

An admin account can change jobs the technician should not touch. Putting that secret in a van app copies the secret onto devices you do not control. The constraint is their identity setup. The control is absence: no write tool in the build, no bearer from the admin account, no personal login in the demo notes.

How it was tested

The check is on the tool list and on a scripted call, offline. close_job is not registered. A model step that names it gets unknown_tool and does not run a function. There is no test against their admin API. A green local check is not evidence the job system was integrated.

Why it was not shipped

Shipping a writer on the only login they offered would have made the admin password the pilot. That is the failure this case exists to avoid. The production decision is a deliberate stop. The note a student keeps is the refusal, the missing account, and the name of the person who would have to create it. It is not an incident about a live outage, because nothing was turned on.

Sample draft

The note you would hand over. It is not a message that a job closed.

You asked to close the job from the van. The only login offered was an admin account. This build has no close-job tool. I will not demo on that login. A technician account that can write only its own note would be required before any write. That account was not created.

Refused reply

The sentence you do not send.

Job closed. I used the admin login.

That reply is refused. A scripted call to close_job is recorded as an unknown tool and does not change a job.

What to say in an interview

I studied a fictional field team. I would say the buyer wanted a write, the only login was admin, and the write stayed off. I would say what account would have been required, and that I would not demo on a personal admin password. I would not say I closed jobs for them, and I would not say I was placed on the team.

Read week 5 for the pilot account, the bearer, and the rule about admin, week 4 for a constraint tied to a control, and week 2 for not widening a tool's authority. Practice questions are on the interview page.

Why a write tool needs server-side checks, or stays off: the write gateway.