Define the decision before asking for code

Replace a vague request with a testable contract

“Make a script that finds urgent tickets” leaves almost every important decision unresolved. What is urgent? Which fields are trusted? Does urgency mean a label or a write to the live system? What happens if a timestamp is unknown? Can the script overwrite yesterday's output? An assistant can fill those gaps fluently, but invented rules are not requirements.

Our lab contract is intentionally small. Each ticket has exactly four fields: ticket_id, severity, age_hours and target_hours. IDs use T followed by three decimal digits. Severity is one of low, medium or high. Age is a finite integer or floating-point number between 0 and 168 inclusive. Target is finite, greater than zero and at most 168. Booleans and numeric-looking strings are not accepted as measurements.

A valid ticket becomes an URGENT_CANDIDATE when severity is high or age is at or above target. Otherwise it becomes a ROUTINE_CANDIDATE. Retain both reasons if both conditions apply. Invalid tickets are reported as REJECTED, not quietly classified as routine. Duplicate valid ticket identities make the whole batch ambiguous and must stop analysis before publication.

These are lab rules, not universal helpdesk policy. The 168-hour range is an approved exercise bound; a real organization may need a different range and calendar. The classification name deliberately includes “candidate” so a downstream reader does not confuse a local rule with an authorized ticket-priority change.

Write the expected matrix yourself

Use this matrix before examining an implementation:

ID	Severity	Age	Target	Expected result	Reason
T001	low	1	4	ROUTINE_CANDIDATE	Neither urgent condition
T002	low	4	4	URGENT_CANDIDATE	At the target boundary
T003	high	0	4	URGENT_CANDIDATE	High severity independently
T004	low	unknown	4	REJECTED	Age is not numeric evidence
T005	medium	1	0	REJECTED	Target must be positive

The baseline has five input records: two urgent candidates, one routine candidate and two rejected records. Those three populations reconcile to five. A report showing three routine tickets because it treats invalid values as zero has changed the meaning of the result even if it still produces five output rows.

Add three more mental cases. High severity with age exactly at target retains two reasons. A low-severity ticket just below target remains routine. An empty batch has zero counts, not a 100% quality conclusion. These cases separate rule semantics from output formatting and help you avoid testing only the most obvious example.

A constrained prompt, with authority limits

If you use an assistant, provide a prompt like this and adapt it only after an approved specification change:

Implement a Python standard-library, offline classifier for fictional tickets.
The exact schema is ticket_id, severity, age_hours, target_hours.
IDs are T plus three digits. Severity is low, medium or high.
Age: finite int/float in [0,168], excluding bool and text.
Target: finite int/float in (0,168], excluding bool and text.
Urgent candidate means severity high OR age >= target.
Retain both reasons when both apply. Invalid rows remain rejected evidence.
Duplicate valid IDs stop the batch; do not select a latest record without evidence.
No network, secrets, accounts, ticket writes, subprocesses or package downloads.
Do not overwrite an existing output or the input file.
Return code and explain assumptions; do not invent operational SLA rules.
I will supply independent expected results and review the implementation.

Do not paste real helpdesk exports into an unapproved tool. Even a ticket subject or hostname can reveal sensitive context. Use a synthetic schema and small fixture for development; any later real-data handling needs the organization's approved service, data policy and access scope. The same care applies to logs and error traces you ask an assistant to debug.

Exercise: identify unsupported decisions

Review a hypothetical response that adds automatic priority updates, translates unknown to zero, installs an external package and chooses the last duplicate ID. Which parts violate the contract, and which require new approval rather than a minor refactor?

Worked reasoning

All four depart from the specified offline interface. Priority updates introduce external action and authority. Unknown-to-zero invents a measurement. A dependency adds installation and supply-chain requirements absent from the standard-library design. Selecting a duplicate winner invents a revision policy. Reject or redesign those additions explicitly; do not retain them just because the response calls them best practices.

Reasoning model

Treat generated code as an untrusted draft whose behavior must be established. A useful prompt supplies input contract, invariants, forbidden side effects and acceptance tests, but the model’s explanation is not execution evidence. Review dependencies, network calls, file paths and destructive operations before running. Tests must include boundaries and failure paths that challenge the implementation, not only examples it was shown.

Official reference for further study