Same Instructions → Same Results → No Confusion
Deterministic writing means writing instructions so that every person who follows them will get exactly the same result. There is no guessing. No hidden meanings. No missing details.
- One instruction must mean one thing only.
- One meaning must produce one action.
- Any difference in results means the writing is wrong.
Think of it like a machine: same input, same output, every time. Words are tools to show exactly what to do, not to explain or justify.
Instruction:
"Process the request"
Problems:
- What is “request”?
- How should it be processed?
- What result is expected?
Because these are not clear, different readers will do different things. This is not deterministic.
Treat writing like a function:
Output = Function(Instruction, Input, Environment)
It must work the same for everyone:
All readers → Output same
To achieve this:
- Input must be fully defined
- Steps must be fully explained
- Environment (like software versions) must be clear
If something is left out, readers will interpret it differently, creating mistakes.
- Ambiguity – Words or phrases can mean more than one thing.
- Missing Rules – Some steps or limits are not explained.
- Hidden Knowledge – You assume the reader knows something you didn’t write.
- Undefined Input – Data is not fully described.
Instruction:
"Scale the system when needed"
- What does “needed” mean?
- How should it be scaled?
- What is the limit?
Without these, readers will act differently. Not deterministic.
Rules for each step:
- One task at a time – no combined operations
- Fully explained – everything the reader needs is written
- Clear start and end – when to start and finish
Wrong:
Optimize performance
Right:
If response time > 200ms → Add one server replica
Now the reader knows exactly what to do.
Instruction:
"Clean the dataset"
Check:
- What does “clean” mean? Remove empty values? Deduplicate?
- What is the format?
- How to handle errors?
If two people do different things, the writing is not deterministic.
Words must always mean one thing. No swapping synonyms. No hidden meanings.
Example:
Authenticated = token is valid AND token is not expired
This definition must stay the same throughout the document.
Terms:
- “user”
- “client”
- “account”
If you use them interchangeably, pick one and stick to it.
All “if” statements must be measurable and testable. Avoid vague terms like “high” or “fast.”
Wrong:
If system load is high
Right:
If CPU usage > 80% for 5 minutes
Instruction:
"If traffic is heavy"
Define exactly:
- Metric (requests/sec)
- Threshold value
- Time window
Otherwise, readers will guess.
Every step must list everything it depends on. Missing dependencies create mistakes.
Wrong:
Run migration
Right:
Run migration on database users, version 3.2, with backup enabled
Instruction:
"Deploy application"
Check if the instruction includes:
- Environment
- Version
- Configuration
- Rollback plan
If any are missing → non-deterministic.
Steps must be in clear order when it matters.
Wrong:
Validate and store data
Right:
Validate(data) → Store(data)
Instruction:
"Encrypt and send data"
Clarify order:
- Encrypt first
- Then send
Otherwise, readers may do it differently.
All system states must be explicit. Don’t assume hidden states.
Example:
Pending → (payment success) → Confirmed
Pending → (payment fail) → Failed
Instruction:
"Order is processed"
Check if all states are clear:
- Initial state
- Trigger
- Outcome
- Failure state
If not → non-deterministic.
Define exactly what happens when things go wrong.
Wrong:
Handle errors appropriately
Right:
If timeout → Retry 3 times with 2-second delay
If still failing → Log error and abort
Instruction:
"If request fails, retry"
Define:
- What counts as failure
- Number of retries
- Delay
- Fallback if still failing
Always define what the instruction takes in and what it produces.
Example:
Input: {amount: float, currency: string, user_id: int}
Output: {status: success or fail, code: int}
Instruction:
Process transaction(amount)
Check:
- Currency?
- User ID?
- Payment method?
All must be defined.
No Hidden Defaults
Do not rely on assumed default values. Define everything.
Wrong:
Use default timeout
Right:
Timeout = 30 seconds
Statement:
"Use default configuration"
Ensure default is defined. Otherwise, different readers may apply different defaults.
If steps run at the same time, define order and synchronization. Otherwise, results may differ.
Wrong:
Run tasks simultaneously
Right:
Run Task A and Task B in parallel
Wait until both finish → Continue
Instruction:
"Execute jobs at the same time"
Define:
- How to synchronize
- How to handle failure
Check deterministic writing with:
- Reader Convergence Test – multiple readers produce the same result
- Path Uniqueness Test – one input → one path
- Completeness Test – all inputs covered
- Boundary Test – start and end states defined
Take any vague instruction. Rewrite it clearly. Then check:
- Can two people do it differently? If yes → not deterministic
- Are all inputs and conditions defined?
- Are outputs measurable?
- Under-specification – missing constraints → multiple outcomes
- Over-generalization – vague terms → guessing required
- Hidden dependencies – missing prerequisites → inconsistent execution
Wrong:
Send required fields
Right:
POST /payment
Body: {amount: float > 0, currency: ISO_4217, user_id: int}
If amount <= 0 → Reject(code=400)
Wrong:
Deploy latest version
Right:
Deploy image=service:v1.4.2 to production environment using config=hash_xyz
Deterministic writing is complete when:
- Only one meaning exists for each instruction
- Every input produces one predictable result
- Readers cannot guess or assume anything
At this point:
- Text = Clear instruction
- Reading = Execution
- Result = Identical every time