Every complex industry runs on the same primitives.
I decompose them in public, one industry at a time, so you can learn any domain faster. Each guide maps the same ten primitives, then covers what doesn't transfer: the money, the power and the cost of being wrong.
Money coming in: how a US or Canadian seller turns an order into cash. Credit and terms, invoicing, the rails payers use, cash application, collections and deductions, what each step costs the seller, and who pays when it goes wrong.
Money going out: how US and Canadian businesses approve and pay their suppliers, why accounts payable is a control function first, what each rail costs the buyer and earns it, how supplier-impersonation fraud works, and who pays when it goes wrong.
Money going out through employees: corporate cards, expenses and reimbursements in the US and Canada, how a fintech card program is built, what each instrument costs and earns, and who pays when a card is misused or a receipt never arrives.
How a business gets a number or sender approved, provisioned and delivered across SMS, RCS, WhatsApp and voice in the US, Canada and beyond, who can say no along the way, and who pays when it fails.
Last reviewed October 2026
The primitives
The questions every guide answers, in the same order. Pick one to read it here.
01
Entity & identity
What is the unit of record, and how do we know it is the same one?
Every industry keeps records about one core thing, and has a rule for deciding that two records describe the same one. Get the rule wrong and every bill, report and audit downstream is quietly wrong too.
What it is
The entity is the noun the business can't function without: the account holder, the patient, the subscriber, the employee, the legal matter. Identity is the rule that decides the record in front of you today is the same one you saw last week, even after a name change, a merger, a new phone or a typo.
The hard part is almost never the entity. It's the identity rule, and who is allowed to override it.
Where you'll see it
Industry
The entity
How identity gets decided
Payments
Account holder, merchant, card
Identity checks on people and businesses; a token stands in for the raw card number
Telco
Phone number, sender, brand
The number is an address, not a person; ownership is proven with documents and registrations
Healthcare
Patient
Matching on name, birth date and identifiers; a duplicate record is a safety risk
Payroll
Employee
Tax ID plus employment record; one person can hold two jobs at the same company
Legal
Client, matter
Conflict checks decide whether a "new" client is really an old adversary
Questions to ask in week one
What is the one record everything else hangs off?
What makes two records the same one, and who decides when it's ambiguous?
Can one real-world thing end up with two records, or one record cover two things? What breaks when it does?
Which identifiers do we issue, and which are issued by someone else?
What happens to the record when the real-world thing goes away?
The trap
Software PMs think of an ID as a primary key you mint. In regulated industries the identifier that matters is often issued by someone else (a tax authority, a numbering plan, a card network). You don't control the identity, you mirror it, and your data model has to survive the day the issuer changes its mind.