Code Play Optimize
Part IV / Instrument the System / Chapter 06
Poker 2.0Code, Play, Optimize
Turn intuition into a decision system that survives fatigue, ambiguity, degraded conditions, and the unwilling Tuesday.
Content is easy to count. Capability has to survive contact.
The process has to work when you do not.
A decision system is not a beautiful document, a completed course, or a strategy you can explain on a good day. It is a baseline that enters the field, collects evidence, and improves without confusing variance for truth.
The first question was about slides.
How many slides would the training need? How long would the course run? What documents would be produced, and what would completion look like on the schedule?
These are reasonable contracting questions. They are also the reason so much training looks complete while the operator remains unprepared.
I asked a different question.
What must the person be able to do when the system degrades, the communication link drops, the procedure no longer fits cleanly, and nobody senior is available to convert ambiguity into an instruction?
The room changed after that. It always does.
Content is easy to count. Capability is harder because capability has to survive contact.
A decision system has three phases.
Code
Convert intuition into variables before pressure arrives. Position. Range. Stack. Stakes. Trigger. Constraints. Exit conditions. Minimum acceptable performance. Decide what matters while the room is quiet enough to hear yourself think.
Play
Execute the code where fatigue, ego, timing, incomplete information, other people, and weather expose everything the plan failed to imagine. Play is disciplined contact between the document and reality.
Optimize
Turn the difference between expected and observed performance into a change. Keep what survived. Repair what failed. Remove what added no capability. Then run the new version.
Most people live in one phase.
Some code forever. Their systems become beautiful, internally consistent, and untouched by consequence.
Some only play. They improvise every session, call experience a method, and repeat the same expensive originality for years.
Some optimise compulsively. They change the system after every result and never permit a sample large enough to reveal whether the original code worked.
The edge is the loop.
This is how a scheme of work becomes capability, how a checklist becomes operational judgement, how a poker strategy becomes more than remembered hands, and how experience stops being a collection of stories.
Seven fields before contact.
What outcome must the system reliably produce?
What must be true before entry: rested, bankrolled, authorised, informed, resourced?
Which variables have genuine decision authority?
What starts, pauses, or escalates the procedure?
What explanations are credible, and what evidence narrows them?
What condition requires a fold, shutdown, handover, or review?
When will the process be examined, and what sample will exist?
The sheet should be short enough to use and precise enough to disagree with you.
A document that always confirms the operator is decorative.
Which important part of your life still depends on intuition that has never been converted into a repeatable process?
Designing for the operator who is not at their best.
In autonomous maritime work, it is tempting to make the machine the main character.
The machine is impressive. It carries sensors, software, communication links, navigation logic, and a long list of things that can be demonstrated under controlled conditions. But training cannot be designed for the demonstration. It has to be designed for the operator after the demonstration team has gone home.
That operator may be tired. The weather may have changed. The link may be intermittent. The procedure may be technically available and practically unusable. The person may be alone with a decision that was a footnote in the design meeting and is now the only thing that matters.
So the training product cannot be content coverage. It has to be a capability stack.
The standard operating path when the expected conditions still exist.
The alternate path when communication, equipment, information, or environment changes.
The evidence that makes stopping the correct operational action.
Who may decide, who must be informed, and when authority transfers.
The minimum usable support available at the point of need.
Enough realistic friction that ambiguity is encountered before consequence.
This is where my two working worlds became the same world.
At the poker table, you do not rise to the beauty of your theory. You fall to the quality of the decision process you have installed. In a technical operation, you do not rise to the page count of the manual. You fall to what the operator can retrieve, adapt, and execute when the manual is no longer the whole answer.
A checklist is not proof of capability. A completed course is not proof of transfer. A successful demonstration is not proof of resilience.
The system has to be tested where it is supposed to live.
Iterate. Dominate. Disrupt.
Iterate
Run the process often enough to identify instability. Find the load-bearing fundamentals, eliminate obvious leaks, and make the sequence reliable.
Dominate
Make the fundamentals automatic enough that attention can move from remembering the process to reading the field. Domination is stable command of your baseline.
Disrupt
Redesign only after understanding what the system is protecting. Violate the baseline intelligently, exploit a field shift, or build a better architecture.
People want to disrupt first because disruption photographs well. Redesign without mastery is vandalism with a keynote.
The unwilling Tuesday is the real test.
If the process requires your best self, it is not a system. It is a mood with documentation.
A system built for ideal conditions will be available precisely when it is least needed. The test is low energy, incomplete information, no applause, a dozen plausible distractions, and a decision that still has to be made cleanly.
Complexity as status
The system grows because the author wants it to look sophisticated. Every additional step is another place the real operator can leave it behind.
Optimisation before stability
A process changes after every disappointing outcome. Variance is mistaken for feedback, and the system never accumulates a trustworthy sample.
Completion as capability
The box is checked, the course is passed, the document is signed, or the hand is reviewed. None proves behaviour changed under pressure.
A system is not what you understand on a good day.
It is what still guides behaviour when motivation, certainty, and supervision are unavailable.
Build your Code Sheet.
Choose one recurring decision that matters: entering a project, hiring, publishing, taking a poker seat, making a financial commitment, or having a difficult conversation.
- State the mission in one sentence.
- Name the conditions required before entry.
- List the five inputs with genuine decision authority.
- Define the trigger to act and the trigger to pause.
- Describe the credible range of outcomes or explanations.
- Write the stop or handover condition.
- Set the review date and minimum sample.
Then run the sheet in the field three times before improving it.
Do not optimise from imagination. Let reality earn the revision.
The map and the deeper archive.
The concise system map: code the decision, play it under pressure, review the evidence, and rebuild only after reality has earned the change.
Open the wider decision-science archive behind Poker 2.0, including process, focus, failure, execution, and the operating models that support the manuscript.
Operational detail remains subordinate to security and accuracy.
Before publication, confirm that the training-contract and autonomous-maritime descriptions are factually accurate, non-sensitive, and cleared for public use. The chapter requires the operational principle, not proprietary system detail.
Every operating system eventually crashes.
The hand goes wrong. The programme fails transfer. The machine behaves differently from the demonstration. The strategy that worked for months suddenly starts returning errors.
That is not the moment to protect the story of the system.
It is the moment to open the black box.