The knowledge base
Everything the team knows about the product lives in one place, organised in six levels: from the ground rules everyone agrees on to what people see on screen. Each level answers a different question, and each one builds on the levels below it.
Six levels, two supports
The lower levels change rarely and hold everything up. The higher levels sit closer to the people using the product and change more often. Two support folders run alongside them: what the team has learned, and what is still to do.
Closer to the people using it
05Screenswhat people see 04Domainthe information and its rules 03Featureswhat people can do 02Modulesthe map of the product 01ADRsthe big decisions 00Bootstrapthe ground rulesShared foundation
What do we all agree on before we start?
The shared starting point: the words the team uses, with one name for each concept; the look and feel; the technologies the product is built with; and the apps that make up the product, such as a patient app, an admin console or an API.
“We say patient, never client.”
Why is it built this way?
The important choices that shape the whole product, each with the options that were weighed and the reason for the one chosen. Decisions are never erased: when one is replaced, the old one stays as history, so anyone can see how the product got here.
“Every list loads page by page, never all at once.”
What are the big areas of the product?
The product divided into large areas, such as billing or appointments. Each area has one home page that gathers everything that belongs to it — its features, its information and its screens — so anyone can find their way around.
“Appointments: booking, rescheduling and reminders.”
What can each person do, and how do we know it works?
Each thing a person can achieve with the product, told from their side, step by step — INSPIRE's version of a user story. Every feature comes with the checks that decide when it is done, written in plain language.
“A receptionist books an appointment. Two appointments for the same doctor never overlap.”
What does the product remember, and what may it do?
The precise contract behind the features: the information the product keeps, such as patients, appointments or invoices; the rules that must always hold; and the operations it can perform. It is exact enough for a machine to check, and independent of any technology.
“An appointment always ends after it starts.”
What is on each screen, and what happens when I press this?
Every view of the product: who arrives there and why, what it shows, what each button does and where it leads. Screens are assembled from shared layouts and building blocks, so the whole product looks and behaves the same way.
“Appointment detail shows the date, doctor and patient. Cancel asks for a reason.”
Support
Two folders that are not part of the product's specification, but keep the team and the agents working well around it.
How have we adapted the agents to the way we work?
Short, one-line instructions that change how the agents behave in this project. They are about the way of working, not about the product, and they are shared back so the next version of INSPIRE improves for every team.
“Always ask before adding a new module.”
What do we already know is pending?
The known, pending work, kept right next to the specification instead of in a separate tool. A known problem stays visible as tracked, instead of being rediscovered and reported as new every time someone reviews the product.
“Reminder emails are not translated yet.”
In motion
Nothing in the graph stands alone. Watch what happens when the team adds a single use case: new nodes appear on several levels, link to decisions already made, and leave their pending work in the tracker, one link away.