Audit trail system
Artyc
A shipping profile, which seems like a simple setting, is actually a signed record. Change the limits, state a reason, countersign. The band moves, the footer names whoever signed, and the old values stay readable.
A shipping profile, which seems like a simple setting, is actually a signed record. Change the limits, state a reason, countersign. The band moves, the footer names whoever signed, and the old values stay readable.
The short version
A partner asked to integrate our intelligence layer into their shipper for cell and gene therapy distribution. That made us responsible for the FDA's rules on electronic records. We didn't have the systems in place to be compliant. So we built them.
My role was to write the brief that turned the regulation into requirements, sketch the surface specs, and take positions on how far to push each one. The easy version of compliance makes everything difficult for the user, and people naturally route around difficult systems. "Technically compliant" isn't good enough if it produces a log full of noise and a team that's learned to ignore it.
Two engineers built what shipped. Storage architecture belonged to one of them, so where the audit log physically lives was his call rather than mine. Our quality lead set the bar and pushed back, rightfully, with the conservative reading every time. That's the job, and I'd rather work with someone who overshoots than someone who undershoots and hopes no one looks closely. Most of what shipped is a negotiated position between the three of us.
Everything lands in the same table. The filter is how you decide what an inspector sees.
The problem
Our partner had seventy qualification documents covering the hardware. Nothing covered the records, and buyers in cell and gene therapy treat a compliant data layer as a condition of purchase.
21 CFR Part 11 is the American code for electronic records and signatures in regulated industries. It has three main concerns: the records themselves, an audit trail over them, and electronic signatures.
Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information.
21 CFR §11.10(e)
Read plainly: nobody deletes an entry, including whoever runs the servers. The timestamp comes from the machine. Old values survive edits. Records are kept for years and must be exportable. The awkward requirement is tamper evidence, which has nowhere obvious to live in an interface.
What we had before: user IDs and timestamps, inconsistently applied. Field-level before and after values, sometimes. No unified log, no reason for change, no tamper evidence. Records you could still edit through admin paths if you knew where to look. No signatures, no retention policy. To read any of it, you opened the database.
Old values sit beside new ones. Nothing is struck out. The rule says a change must not obscure what it replaced. A line through a number obscures it.
The approach
Backend first, no interface. Every regulated action had to write an immutable event before anyone could look at one. Design the screen first and you're designing against data that doesn't exist yet.
We started from a bare requirements pass our quality lead had put together. The brief and PRD built on top of it. The data model was standing in a week. The rest was three of us finding edge cases, rereading the regulation, and checking we were still inside it.
The build went in phases. Events first, then search and CSV export so a compliance officer could answer a question without finding an engineer. Then tamper evidence and reason for change. Then signatures and retention. Signatures got pulled from P1 to P0 once it was clear that journey release depended on them.
How often to demand a reason
Our quality lead wanted a reason field on every regulated change. That's what a compliance function is paid to want. My objection was about what happens in the product when you do that. A reason field on every save fills up with the word "updated" and the occasional full stop. People learn the prompt and stop reading it inside a week. A compliant log full of nothing is worse than an empty column. An empty column at least doesn't look like evidence.
What shipped splits it by what the signature actually means. Approved, Reviewed, and Released leave the note optional. Rejected, Offboarded, and Other require words. The logic in the requirements document was simple. The meaning dropdown alone is insufficient evidence for a reject or an offboard.
How much signing is too much
Same argument, second round. The opening position was identity and password on every signature. Approve eleven calibrations in a row and you type eleven passwords. Nobody does that with any care after the third one.
Then I read §11.200(a)(1)(i), which had already thought about this.
When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.
21 CFR §11.200(a)(1)(i)
The design makes the session itself a visible object. Sign fully once and a chip appears at the top of the portal indicating a signed session with the time remaining. For the next 30 minutes a signature asks only for your password, with your identity displayed from the first signing rather than retyped. When the window runs out, the next signature starts the full ceremony again. The chip is how you know which state you're in before you start approving eleven calibrations.
A guarantee nobody could see
Every event stores a hash of the one before it. Alter a record and you break the next link. Good property, but completely invisible. The job was making it checkable in about two seconds by somebody who doesn't know what a hash is.
Where a log actually gets read
An audit trail is a destination, and most people never go there. What they actually ask is who touched this and when, and they ask it standing in front of the thing they're about to change again.
So the log leaks on purpose. For example, a shipping profile carries a line underneath showing when it was last signed and by whom, right where the next person will make the next change. A regulator reads the full table. Everyone else reads the footer on a card.
Every profile shows the date and name of whoever last signed it. That's where the next person will make the next change, so that's where the answer has to be.
What landed
The platform was accepted with the compliance pieces in place. A 50-shipper pilot with the partner and one of their distributors is scheduled for September 2026.
Not every customer needs 21 CFR Part 11 compliance, so it's provisioned per company.
Feature permissions are read-only to customers to prevent anyone from disabling compliance once it's enabled, which the regulation doesn't allow. Artyc's own staff get logged separately in a vendor access log the customer can read. Browse is the surface everything hangs off. The event drawer opens from a row and runs the same order every time: summary, actor, reason, the change diff, signature, hash chain. Export answers the inspection request. Filter-respecting, CSV and PDF, with verification hashes in the footer so the file can still be checked after it leaves us.
Whatever is filtered on screen is what leaves. The preview is live, the scope is set before you generate, and generating it writes an event, so the export ends up inside the record it exports.
What I’d do differently
Close the gap between deciding and building. With a feature this consequential it's easy to fall into a paralysis of perfection. The brief was written within days of the conversation with the partner. The design and build didn't start for another week or two because we were trying to perfect the scope instead of discovering its edges by moving.
Visible and disabled. A compliance officer can confirm 21 CFR Part 11 is on without filing a ticket, and nobody in the account can turn it off.
What’s still open
Two things sit just behind what's running. The signed session banner is designed and waiting to be wired into the signing dialog. And Annex 11, Europe's version of 21 CFR Part 11, deferred in the PRD because "no customer asks to date," though less deferred in practice than that phrase suggests. It was in my head the whole build. Where the two regulations disagree on reason for change, Annex 11 demands one and 21 CFR Part 11 only expects it. I designed to the stricter reading. The door is open on purpose.
The open question is bigger than any of these. Where the line for software validation falls between us and the partner was raised on day one and hasn't been settled. It decides how much of their qualification burden becomes ours.
Note: To respect confidentiality and regulatory compliance, interface images are built against the product's own design system and populated with fixture data. No customer records, colleague names, or partner names appear anywhere in this case.
Audit trail system
Artyc
A shipping profile, which seems like a simple setting, is actually a signed record. Change the limits, state a reason, countersign. The band moves, the footer names whoever signed, and the old values stay readable.
A shipping profile, which seems like a simple setting, is actually a signed record. Change the limits, state a reason, countersign. The band moves, the footer names whoever signed, and the old values stay readable.
The short version
A partner asked to integrate our intelligence layer into their shipper for cell and gene therapy distribution. That made us responsible for the FDA's rules on electronic records. We didn't have the systems in place to be compliant. So we built them.
My role was to write the brief that turned the regulation into requirements, sketch the surface specs, and take positions on how far to push each one. The easy version of compliance makes everything difficult for the user, and people naturally route around difficult systems. "Technically compliant" isn't good enough if it produces a log full of noise and a team that's learned to ignore it.
Two engineers built what shipped. Storage architecture belonged to one of them, so where the audit log physically lives was his call rather than mine. Our quality lead set the bar and pushed back, rightfully, with the conservative reading every time. That's the job, and I'd rather work with someone who overshoots than someone who undershoots and hopes no one looks closely. Most of what shipped is a negotiated position between the three of us.
Everything lands in the same table. The filter is how you decide what an inspector sees.
The problem
Our partner had seventy qualification documents covering the hardware. Nothing covered the records, and buyers in cell and gene therapy treat a compliant data layer as a condition of purchase.
21 CFR Part 11 is the American code for electronic records and signatures in regulated industries. It has three main concerns: the records themselves, an audit trail over them, and electronic signatures.
Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information.
21 CFR §11.10(e)
Read plainly: nobody deletes an entry, including whoever runs the servers. The timestamp comes from the machine. Old values survive edits. Records are kept for years and must be exportable. The awkward requirement is tamper evidence, which has nowhere obvious to live in an interface.
What we had before: user IDs and timestamps, inconsistently applied. Field-level before and after values, sometimes. No unified log, no reason for change, no tamper evidence. Records you could still edit through admin paths if you knew where to look. No signatures, no retention policy. To read any of it, you opened the database.
Old values sit beside new ones. Nothing is struck out. The rule says a change must not obscure what it replaced. A line through a number obscures it.
The approach
Backend first, no interface. Every regulated action had to write an immutable event before anyone could look at one. Design the screen first and you're designing against data that doesn't exist yet.
We started from a bare requirements pass our quality lead had put together. The brief and PRD built on top of it. The data model was standing in a week. The rest was three of us finding edge cases, rereading the regulation, and checking we were still inside it.
The build went in phases. Events first, then search and CSV export so a compliance officer could answer a question without finding an engineer. Then tamper evidence and reason for change. Then signatures and retention. Signatures got pulled from P1 to P0 once it was clear that journey release depended on them.
How often to demand a reason
Our quality lead wanted a reason field on every regulated change. That's what a compliance function is paid to want. My objection was about what happens in the product when you do that. A reason field on every save fills up with the word "updated" and the occasional full stop. People learn the prompt and stop reading it inside a week. A compliant log full of nothing is worse than an empty column. An empty column at least doesn't look like evidence.
What shipped splits it by what the signature actually means. Approved, Reviewed, and Released leave the note optional. Rejected, Offboarded, and Other require words. The logic in the requirements document was simple. The meaning dropdown alone is insufficient evidence for a reject or an offboard.
How much signing is too much
Same argument, second round. The opening position was identity and password on every signature. Approve eleven calibrations in a row and you type eleven passwords. Nobody does that with any care after the third one.
Then I read §11.200(a)(1)(i), which had already thought about this.
When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.
21 CFR §11.200(a)(1)(i)
The design makes the session itself a visible object. Sign fully once and a chip appears at the top of the portal indicating a signed session with the time remaining. For the next 30 minutes a signature asks only for your password, with your identity displayed from the first signing rather than retyped. When the window runs out, the next signature starts the full ceremony again. The chip is how you know which state you're in before you start approving eleven calibrations.
A guarantee nobody could see
Every event stores a hash of the one before it. Alter a record and you break the next link. Good property, but completely invisible. The job was making it checkable in about two seconds by somebody who doesn't know what a hash is.
Where a log actually gets read
An audit trail is a destination, and most people never go there. What they actually ask is who touched this and when, and they ask it standing in front of the thing they're about to change again.
So the log leaks on purpose. For example, a shipping profile carries a line underneath showing when it was last signed and by whom, right where the next person will make the next change. A regulator reads the full table. Everyone else reads the footer on a card.
Every profile shows the date and name of whoever last signed it. That's where the next person will make the next change, so that's where the answer has to be.
What landed
The platform was accepted with the compliance pieces in place. A 50-shipper pilot with the partner and one of their distributors is scheduled for September 2026.
Not every customer needs 21 CFR Part 11 compliance, so it's provisioned per company.
Feature permissions are read-only to customers to prevent anyone from disabling compliance once it's enabled, which the regulation doesn't allow. Artyc's own staff get logged separately in a vendor access log the customer can read. Browse is the surface everything hangs off. The event drawer opens from a row and runs the same order every time: summary, actor, reason, the change diff, signature, hash chain. Export answers the inspection request. Filter-respecting, CSV and PDF, with verification hashes in the footer so the file can still be checked after it leaves us.
Whatever is filtered on screen is what leaves. The preview is live, the scope is set before you generate, and generating it writes an event, so the export ends up inside the record it exports.
What I’d do differently
Close the gap between deciding and building. With a feature this consequential it's easy to fall into a paralysis of perfection. The brief was written within days of the conversation with the partner. The design and build didn't start for another week or two because we were trying to perfect the scope instead of discovering its edges by moving.
Visible and disabled. A compliance officer can confirm 21 CFR Part 11 is on without filing a ticket, and nobody in the account can turn it off.
What’s still open
Two things sit just behind what's running. The signed session banner is designed and waiting to be wired into the signing dialog. And Annex 11, Europe's version of 21 CFR Part 11, deferred in the PRD because "no customer asks to date," though less deferred in practice than that phrase suggests. It was in my head the whole build. Where the two regulations disagree on reason for change, Annex 11 demands one and 21 CFR Part 11 only expects it. I designed to the stricter reading. The door is open on purpose.
The open question is bigger than any of these. Where the line for software validation falls between us and the partner was raised on day one and hasn't been settled. It decides how much of their qualification burden becomes ours.
Note: To respect confidentiality and regulatory compliance, interface images are built against the product's own design system and populated with fixture data. No customer records, colleague names, or partner names appear anywhere in this case.