Commits as Alibis
The first technical scene I wrote for this book was terrible.
It explained things. A character stood in front of a screen and told another character how a blockchain works, at length, accurately, and with roughly the dramatic weight of a user manual. I was proud of it for about a day. Then I read it cold and could feel my own attention sliding off the page, which is a horrible thing to catch yourself doing to your own book.
What fixed it is the only piece of craft advice I would offer anyone writing about software. A technical scene does not need explanation. It needs a constraint.
The build must pass before market open. The validator expects a signature by 09:00:31 GMT. The contract cannot be patched once the trigger fires. The reviewer has eleven minutes, a dying phone, and a reason to miss the line that matters.
None of those teach the reader anything about the stack, and none of them need to. The reader does not want to understand the system. The reader wants to know what can break, what rule binds these people, and which choice is going to stain them.
Once I understood that, the repository stopped being scenery and started being the best evidence locker I have ever had to work with.
Because a repo really is a record. Every file has a history, every line has ancestry, and somebody added it, somebody reviewed it, somebody approved the merge while drinking bad coffee and watching the build crawl through another test suite. Git remembers what changed, when, and who claimed it. Signed commits go further: a cryptographic signature says a particular key approved this particular snapshot. It sounds like certainty.
It is certainty about the key.
Keys get stolen. Laptops get opened under threat. Tokens sit too long in the wrong environment. A developer can write a perfectly clean commit for an entirely dirty reason and leave the machine nothing to object to. Systems verify structure. They have never been able to verify courage, and they never will, and that gap is where I found most of this story.
It is why the obvious danger in a software thriller is the wrong one. An external attacker is a plot. The approved change is a tragedy. It passes review because everyone is tired. It passes tests because the tests describe last year's fear. It ships because the deadline has teeth. Then it waits, behaving perfectly, handling normal cases, surviving staging, keeping the dashboard green long enough for everybody to trust the colour.
A merge is never only a merge. It is one person saying that another person's work may enter the shared body of the system. On a calm team that is process. Under pressure it becomes a confession, or a betrayal, and quite often the person merging cannot tell which one they are doing.
The scene I finally kept has no explanation in it at all. A woman types the commit message for a patch she has been forced to write, and what she types is "Add transaction optimization for network stability."
It is accurate. It will pass review. Her daughter's school pickup is in fifteen hours.