We are preparing for a redesign of the e-Manifest system because of the proposed Paper Manifest Sunset Rule. The current system has been in production since 2018, and it has been successful in many ways. But the basic posture of the system still reflects the world it was built for: a hybrid process where some information comes in electronically, and some of the operational record is still tied to paper.
The Paper Manifest Sunset Rule changes that. Once the sunset date arrives, the electronic manifest is no longer just the legal equivalent of paper. It becomes the manifest. The electronic record is the record.
That sounds like a small wording change, but from a system-design perspective it is not small at all.
When the electronic record becomes the actual tracking instrument, the system has to be designed around the full lifecycle of that record. How does it start? Who can add information at each point? What signatures are required? What happens when the transporter changes? What does the receiving facility see? What does a generator need to understand after the shipment has left the site? What does the system do when there is no connectivity or when a contingency paper process is needed?
Those are not just screen-design questions. They are workflow questions, legal-record questions, and operational questions.
Our normal approach to this kind of redesign would be familiar to most software teams working in regulatory systems. We would start by talking to the people who know the rules. We would interview them, ask them to explain the process, and then turn those discussions into the first design artifacts. Depending on the project, that might mean requirements documents, workflow diagrams, wireframes, mockups, or a first pass at user stories.
That approach works. We have used it many times.
For this effort, I wanted to try a different starting point.
Earlier this year, a friend of mine visited from California and walked me through how he has been using AI-assisted authoring in his own work. He was not using it as a shortcut to produce finished documents. The useful part was the way he organized the source material first, then used the model to reason across that material.
That sent me down a path that eventually led to Andrej Karpathy’s LLM wiki pattern. The basic idea is simple: you curate a folder of source material, usually with the original documents preserved, and then build a markdown knowledge base on top of it. Obsidian calls this kind of folder a vault, which is a good name for it. It is just files, but if the files are curated well, the vault becomes a useful working model of the subject.
I liked that because it matched the way regulatory software actually has to be understood. The truth is not in one meeting or one requirements document. It is spread across Federal Register notices, CFR text, old design decisions, production behavior, user pain points, operational exceptions, and the opinions of people who have lived with the system for years.
So before the first major design workshop, I built a knowledge vault for the e-Manifest redesign.
I started with the Paper Manifest Sunset Rule and the prior e-Manifest rules that led up to it. I added material describing how the current system works. I added notes from the existing application, including workflow behavior, status changes, and current limitations. I also included prior improvement ideas from the team so the vault was not only describing the regulatory requirement, but also the practical system we are trying to improve.
At that point, the vault could answer questions about both sides of the problem: what the new rule appears to require, and how the existing system behaves today. That combination is critical because either side by itself gives an incomplete picture.
If the model only understands the rule, it can produce clean regulatory summaries that may not survive contact with the actual system. If it only understands the current system, it may reinforce old design assumptions that the new rule is supposed to change. The useful work happens when both are in the same body of knowledge.
The first thing I asked for was not a document. I asked for a state machine.
That turned out to be one of the more clarifying steps in the process. The proposed rule has a lot of provisions, and e-Manifest already has a mature workflow. Reading those pieces linearly makes it hard to see the shape of the redesigned record. But when the manifest is represented as a state machine, the questions become much clearer.
What status does a manifest start in? What has to be true before it moves to the next state? Which party can make that transition? Which data elements are required at that point? Which signatures are required? Which exceptions can interrupt the normal path? Which states are terminal, and which are only temporary?
That helped me see the redesign as a lifecycle instead of a pile of requirements.
At that point, I demonstrated the vault and the state-machine approach to the client. That changed the process in a useful way. They saw the value in having this kind of working model before the meeting, and they asked me to produce more visuals to help drive the discussion.
I think that part deserves credit. It is one thing for me to build a research vault and use it to understand the rule. It is another thing for the client to recognize that the vault could become a practical workshop tool. That was critical, and it was innovative.
From there, I asked AI to use the vault to look at the same lifecycle from different perspectives.
The generator cares about creating the manifest, making sure the right waste and shipment information is captured, signing at the right time, and knowing what happened after the shipment left the site.
The transporter cares about being able to receive the manifest, sign it, move the shipment, manage handoffs, and deal with situations where the driver may not be a fully registered e-Manifest user.
The receiving facility, or TSDF, cares about final receipt, discrepancy handling, corrections, final signatures, and the official electronic record.
Those are three different experiences sitting on top of the same record. If we design only from the regulation, we can miss the operational shape of those experiences. If we design only from one user type, we can make the workflow easier for one party and harder for everyone else.
The vault helped connect the role-specific views back to the state machine. That gave me a set of artifacts I could actually use in conversation: diagrams of the manifest lifecycle, mockups of what the record might look like at different stages, and notes showing which data elements and actions mattered at each point. With those artifacts in hand, the meeting becomes a different kind of conversation.
Instead of walking into the room with a blank page and asking experts to explain the system from scratch, we can walk in with a working model and ask them to correct it.
That is a very different conversation. Experts are often better at reacting to something concrete than they are at inventing the whole structure in an interview. A diagram gives them something to challenge. A mockup gives them something to point at. A state transition gives them something to say yes or no to. The disagreement becomes useful because it shows us exactly where our model is wrong.
In preparation for next week’s five-day working session, the client had already seen the vault, the state machine, and the early visuals. They had that context before the meeting, and they used it to set the agenda.
The plan is to start with the state machine, then walk through the lifecycle from the major perspectives: generator, TSDF, transporter, and the other parties that touch the manifest record. We will look at the proposed workflow, look at the mockups, and capture comments from the people who know the program and the current system.
Then, each night, we will feed that feedback back into the vault and regenerate the artifacts.
That is the part I am most interested in testing. The vault is not just a research archive. It becomes a working requirements environment. The source material stays there. The assumptions stay there. The comments from each day get added. The next version of the state machine, workflows, and mockups can then be generated against the updated body of knowledge.
By the end of the week, my hope is that we have more than meeting notes.
I would like to come out of the process with a stronger state model, clearer role-specific workflows, more grounded mockups, and a set of requirements that already reflect several rounds of expert review. From there, we should be able to generate an initial set of user stories and turn those into development-ready artifacts.
I do not think this replaces expert interviews. In fact, the whole approach depends on expert review. The difference is that the experts are not being asked to carry the entire discovery process on their backs. We do more work before the meeting, bring a concrete model into the room, and then use the meeting to improve that model.
That feels like a better use of everyone’s time.
It also fits the kind of systems we build. Regulatory applications are not greenfield consumer products. They have history. They have legal requirements. They have production behavior that cannot be ignored. They have exceptions that matter because someone has already lived through them. A curated knowledge vault gives us a way to keep that context together and use it while the design is still forming.
We will see how well it works after the workshop.
If it works, I think this may become a standard part of how we approach major redesigns: curate the rule, capture the current system, include the known pain points, generate a working model, bring that model to the experts, and refine it quickly while the conversation is still fresh.
That is a practical use of AI in system design. Not replacing the people who understand the program, and not pretending the first generated answer is correct. The value is in using the technology to organize the material, expose the workflow, and make the first conversation much more concrete.
For e-Manifest, that may be exactly what we need. The system is moving from paper-supported electronic processing to an electronic record that stands on its own. The design process needs to make the same shift. We should not start with paper-era assumptions and slowly patch our way forward. We should start with the electronic record, understand its lifecycle, and design the system around that.
That is the experiment. I will report back after the five-day session and see whether the approach holds up in the room.
