Turning real-world rules into software

My work in clinical research includes participant visits, scheduling, study documentation, data, and day-to-day coordination. The work is human, but it also depends on procedures that have to be followed and recorded consistently. A rule is not useful merely because it exists on a page. It has to arrive at the right moment, with enough context for someone to apply it correctly.

Software has a similar translation problem. A real-world process rarely begins as a neat sequence of conditions. It begins as conversation, exceptions, timing, missing information, and responsibilities shared across people. Turning that into software means deciding what the system can know, what it should ask, and where it must stop instead of pretending certainty.

I notice this in projects that interpret rules. A billiards companion needs to distinguish an open table from solids or stripes, recognize when the 8-ball is legal, and warn about scratches, but it should never take the shot away from the player. An automation planner can model quotas and stop conditions, but a plan is not proof that the live action happened. The boundary between guidance and control has to survive the implementation.

The most useful lesson from research is not that every process should become software. It is that procedures carry reasons, and those reasons can disappear when a workflow is compressed into buttons. I want to preserve the reason: why a field is required, why a state is uncertain, why confirmation matters, and why some action remains human. Clear software does not erase the real world. It shows where its own model ends.