The records existed. Nobody could ask them anything.
Nurse Next Door had years of operating history across more than 400 locations inside its franchise-management system. Every lead, every status change, every document, agreement and territory, back to the beginning. The data was complete. It was also unreadable to anyone who did not write SQL.
So a question meant a report request, and a report request meant waiting. Most questions went unasked. Head office ran on side-of-the-desk reporting. The roadmap was clear. What was missing was the capacity to execute it without adding headcount.
The brief had a constraint we agreed with. The brain had to feed the systems the client already ran, not compete with them. Their dashboards stay the source of truth. Our job was to make the history underneath those dashboards answerable by anyone on the team, in plain language, with the source shown.
A full extract, a brain on top, and a pipeline the client owns
The first job was extraction. We pulled a full structured copy of the franchise-management system into the client's own database: leads, remarks, mail, campaign email, status changes, documents and calls, plus the franchisee-operations module with its agreements, territories, renewals and terminations. Every table in the system, not a sample, and every count reconciled against the source before we called it done.
The extraction toolkit is checkpointed. Each step records where it got to, so a restart resumes instead of starting over. The toolkit and a connector were merged into the client's own repository with a handoff document. The client owns the pipeline and can rerun it without us.
On top of the extract sits the knowledge brain, deployed in the client's own cloud region under the client's own brand. The extracted documents are indexed for retrieval with a citation on every answer. If the corpus does not hold the answer, the brain says so.
The part that changes the conversation is plain-language questions against the structured tables. Ask how many leads moved to a given status last year and the agent writes the SQL, runs it against the real status-change tables, and returns the number with the query it ran. The person asking does not need to know a table name. They can read the query if they want to check it.
Around the brain: a custom assistant agent for the client's team, 7 jobs on a schedule, and 10 KPIs tracked in the portal against the objectives the client set.
Ask in plain language, get the table's answer
A person at head office logs into the portal, types a question, and gets an answer with its source attached. If the answer is in a document, the citation points at the document. If the answer is in the data, the agent writes and runs a query and shows the query. If the answer is in neither, the brain says so and names who to ask.
Underneath, 9 source feeds keep the corpus current. Seven scheduled jobs re-read the corpus and review answers. Most of the system's activity is this automated work: 815 runs in the last 30 days. 107 of 832 runs have failed since launch. We count those because a silent failure is how a brain goes stale, and we would rather print the number than hide it.
The client's team was invited on 2026-07-21. 10 of 11 invitations were accepted. The first client login came 4 days 19 hours after the repository was created.
Who uses it, how much, and how fast it went live
The first answer was written on 2026-07-21. In the 30 days to 2026-08-20 the brain answered 239 questions, counted from the tenant's answer table. Because the brain is exactly 30 days old, the all-time count and the 30-day count are the same number.
10 accounts were provisioned on the client's domain. 5 of them were active in the last 30 days. That is the adoption number, read from the master user table, and it is the one we are working on. Half the team asking is a start. It is not the finish, and we do not print it as one.
The repository was created on 2026-07-17. The first client login was recorded 4 days 19 hours later. That window covers provisioning, the structured extract, the index build and the invitations.
What we did not measure: hours saved on head-office reporting. A baseline was recorded in the portal but no after figure has been read yet, so we print neither. The first number is due November 2026.
We also do not print the size of the corpus or the count of tables extracted. Both are in the delivery record. Neither has been cleared for a page with its own URL yet, so neither is here.