Most people never see the U.S. Supreme Court’s actual formatting rules until they need them. They’re exacting: specific booklet dimensions, specific paper weight, specific typeface and point size, precise margin and spacing requirements, cover color coded by filing type. Get it wrong and the Clerk’s office can reject the filing outright, not because the argument is weak, but because the document itself doesn’t conform.

I formatted a pro se Writ of Certiorari to meet those rules and it was accepted on first submission, no rejection, no resubmission cycle. It’s a matter of public record: Docket 18-1480.

Why he asked me

Jason asked me to format his writ specifically because of my technical discipline and my experience working across multiple software packages, not because I’m a litigator. I worked to his timeline and incorporated his changes as he made them, right up against SCOTUS’s formatting requirements. That’s the actual shape of the work: someone else drives the legal strategy and content, on their schedule, and I make sure the technical execution holds up under a spec with zero tolerance for error.

Why litigation document preparation is harder than it sounds

SCOTUS Rule 33 governs the physical form of a petition: booklet format, page limits, typeface, margins, binding. It reads like a spec sheet because that’s effectively what it is. Most attorneys hand this off to a specialized print/filing service precisely because getting it right by hand, without that infrastructure, is unforgiving: one dimension or spacing detail out of tolerance and the document doesn’t get accepted, regardless of what’s in it.

That’s a document-formatting problem with zero tolerance for error, which happens to be exactly the kind of problem two decades of enterprise systems work trains you to treat seriously. A spec is a spec whether it’s a network configuration or a court filing: you read it precisely, you build to it precisely, and you verify before you ship.

The actual takeaway

This isn’t a claim that I know more law than a litigator. It’s evidence of something narrower and, for a working relationship with a legal team, more useful: I can take an exacting, unforgiving technical specification, whether it’s a court’s formatting rule or a compliance requirement, and execute it correctly the first time, because that’s the discipline enterprise infrastructure work demands every day.

That’s the pairing my work is built around: real engineering discipline, applied inside real legal process, not adjacent to it. The same discipline shows up in how I handle sensitive documents more generally, not just formatting rules.