The partners are right that the knowledge base is the real product and the assistant is only its interface. Where the conclusion goes wrong is the sequencing: knowledge first, AI second is an open-ended internal project with no deadline and no measurable output. Run them coupled instead — and let the system produce the backlog.
Two partner questionnaires — six substantive responses, two Hungarian and four Serbian / Croatian. That is a signal, not a statistic: it tells us what to look at, and the live ticket flow will decide the actual ranking.
Today the goal is: answer well. For the next phase it should be: answer what it can — and manufacture the list of what it can't.
“Digitise the company's technical knowledge” is correct and unbounded. No owner, no deadline, no visible progress — the shape of task that quietly stops. “Write these three articles this week, they cost you eleven escalations” is finite, and someone can be held to it.
The instrument is already in the codebase. The confidence engine emits LOW and SAFETY_RISK on every turn it can't support with evidence, and the audit chain records the retrieval that failed. Nobody collects it. Collecting it is most of item D.
Not a feature. A ranked list of what to write, ordered by how much each gap actually costs in escalations and site visits.
Run it on internal support first, not partners — the internal team tolerates a bad answer and their questions fill the ledger. Partners get it once the top of the list is written.
The partners named five things to digitise. Of those, one is structurally complete, two are half-built, and two are genuine gaps — plus the metadata contract, which is missing its more important half. Status below is read off the repository, not the spec.
Read together: the machine is largely finished and the fuel is missing. The larger half of the remaining work sits with PIERRE, not with engineering — which is good news, provided the list of what to write is generated rather than guessed.
Each one names what already exists underneath it, because most of these are smaller than they sound — the platform was built to take them.
The foundation most of the rest sit on. A firmware / hardware / app release entity with release notes and a predecessor chain, KnowledgeSource.appliesTo scoped to a product and version range, and version filtering inside retrieval, so an article written for 1.8 stops surfacing on 2.4. Session state grows a case-context slot (product, version, environment) that the assistant fills in up front rather than halfway through.
Two additions from the operational concept turn this from a filter into an answer generator. A feature → minimum-version matrix, so the assistant can say “that feature needs v20872, the device runs v17659” — which is one of the questions partners actually ask. And an update-risk classification per release: routine, or requires on-site presence, or requires PIERRE approval. An update that needs a physical power-cycle if it fails is a different object from a routine one, and nothing records that distinction today.
Session state and the retrieval scoring path already exist. First task is a question, not code: does B2B track firmware releases? If yes we sync them. If not, this is the one place a new master is justified — release history exists nowhere today.
One hard rule ships with it: the assistant never initiates an update and never changes a configuration. Not as prompt guidance — as an absent tool. It shows the required version and the risk; a permitted partner triggers the update themselves in the Portal.
Affected products and version range, symptom, how to recognise it, severity, workaround, what not to do, expected fix, fixed-in version, owner, last verified. The tool runs before retrieval on the diagnostic path, because a known issue outranks a wiki article — and it feeds the confidence engine as a structured high-trust signal, the way wiring rules do, not as another RAG chunk.
The part that makes this worth more than a database: when an issue is filed, the system already knows whose buildings run the affected firmware — the Portal has the device inventory and PushSubscription is in the schema. The installer learns about a bad release before standing in front of it, workaround attached. That turns the survey's loudest complaint into the one thing a support portal can never do.
Symptom → ordered checks → what to observe or measure → branch → resolution or escalation, plus an explicit stop-here condition. Structured rather than prose for two reasons: the model must not improvise the order of electrical checks, and a fixed procedure makes it deterministic which data gets collected — which is what makes the resulting ticket useful.
Authoring is the expensive part, so don't staff it. Generate draft procedures from resolved tickets and have a human edit and approve — exactly the pattern PendingTicketReview already implements, just producing a procedure instead of a Q&A pair. That is how you get thirty procedures in weeks instead of quarters.
A normalised question cluster with first and last seen, hit count, best confidence reached, escalation rate, affected product and version, status and owner. Fed automatically from every LOW and SAFETY_RISK turn, every empty retrieval, every escalation. Clustered by embedding similarity so “the same question forty different ways” is one row.
Paired with it, from the operational concept: a closure gate. A ticket cannot be closed until the actual cause is recorded — including when it wasn't ours, with its own taxonomy: internet outage, severed cable, lightning, physical damage, work by someone unqualified. That second list is a business metric in disguise. It shows what share of “PIERRE faults” were never PIERRE faults.
The cheapest item here and the most important. The data is already produced by the confidence engine and the audit chain — today we throw it away. Ranked by frequency × escalation cost it becomes PIERRE's weekly worklist, and when an article lands the ledger replays the stored real questions and shows the confidence delta. The golden set stops being hand-picked and starts growing out of live traffic.
The promote-to-KB queue exists but nothing forces a root cause into it, so the loop currently turns without carrying anything. The gate is what loads it. Note the distinction it needs: a partner marking their work done is not the same event as the case closing.
The half of the metadata contract that's missing today. On its own a review date is decoration, so it has to be enforced: overdue content is automatically downgraded — a firmware article unverified for six months drops to MEDIUM trust, one unverified for a year is quarantined.
TrustLevel and SourceStatus (active / deprecated / quarantined) already exist and are already honoured by retrieval. This is a scheduled job and four columns, not a subsystem. The effect is that the knowledge base cannot rot quietly, and the owner has a reason to touch it.
The survey's clearest structural request: a real L1 → L2 → developer path with committed response times, and a route for out-of-hours. Per tenant and severity: target tier, response target, after-hours path. The assistant's job is to classify severity, attach the diagnostic context it already collected, and tell the installer what happens next and by when.
The operational concept sharpens this into two encodable gates. A callback is not the first support step — it unlocks on stated conditions (no safe step left, checks done and the fault persists, Portal data self-contradictory, several units affected, suspected global fault, PIERRE-side access needed, partner standing on site). And Engineering Check becomes a real state with an entry gate — version, reproduction steps, checks already run, users affected, business impact — and, more valuable, a mandatory output: cause or current status, temporary workaround, option A or B, owner, next step, committed date, fixing version.
Worth saying plainly: this is an organisational commitment, not a software feature. The software's contribution is to make it visible and measurable — time to first human response, per tier, in the admin console. Half the frustration in the survey isn't the slow answer; it's not knowing whether an answer is coming at all.
The mandatory output is the part that closes the circuit: an Engineering Check that names a fixing version writes straight back into the known-issue registry. Two small rules ride along — the assistant never hands out a personal support phone number, and it asks whether the partner is on site, because that changes the queue position.
The strongest single idea in the operational concept, and it inverts ours. We had a “before you leave site” checklist. The better one runs before the partner sets off: what will I need at this site? — generated from the project, the device and the reported symptom. Laptop and drivers, USB-to-RS485 adapter, LAN cable, multimeter, wiring diagrams, the Modbus register map, firmware and config files, a spare unit, access credentials, the site contact, whatever PIERRE-side remote access is required.
Around it, the rest of field mode: an offline cache scoped to the products and procedures in this installer's projects rather than the whole knowledge base, voice input, and one-tap diagnostic collection that pulls live device status into the case.
Half of a repeat visit isn't caused by the fault surviving — it's caused by the adapter or the register map being at the office. Attacking that before departure is far cheaper than anything we can do afterwards, and every input it needs is already in the Portal and B2B.
The transcribe module and the PWA service worker are in place; voice also means the partner dictates the site report and gets a written record back rather than typing a ticket. The metric that matters is repeat site visits avoided — one question at ticket close. It is the number that justifies the subscription, because the partner can price it.
From the operational concept: the assistant should work out whether it is talking to a seasoned integrator or someone doing this for the first time. Compass already has four answer modes — quick, step-by-step, diagnostic, deep engineer — but the mode is chosen per question, never per partner. An experienced integrator wants “check register 40001”; a beginner needs the walkthrough, and giving each of them the other one wastes the same amount of time.
Derivable from what we already store: ticket history, which steps this partner completes unaided, how often escalation follows. It rides on the existing mode selector rather than adding a parallel path.
One boundary is not negotiable, and it should be written down before the feature is: competence adjusts depth and tone only — never the confidence thresholds, never the citation requirement. A senior partner gets a shorter answer, not a less-evidenced one.
In schema terms this is roughly seven new models and five new tools on top of the current 22 and 11, plus two admin surfaces — the gap ledger and the known-issue register. Nothing here requires re-architecting what exists.
A second internal document, written from the support side, described how the service should run day to day. Where our plan is strong on data model and safety logic it is quiet on process; where it is strong on the partner's actual working day, ours was thin. Eight of its elements are folded into the proposal above.
Generated from project, device and symptom. Attacks the repeat-visit cost before the drive rather than after it — the highest-leverage idea in either document.
Turns the version axis from a retrieval filter into something that answers a question partners ask constantly: why doesn't this work on my system?
Routine, needs on-site presence, needs PIERRE approval — plus the hard rule that the assistant never initiates an update or edits a configuration.
No close without a recorded cause. The external-cause list quietly measures what share of reported faults were never ours.
More concrete than our tier model, and the mandatory output — cause, workaround, owner, date, fixing version — is what writes back into the known-issue register.
Ten stated conditions under which a phone callback is warranted. Encodable as a tool guard rather than left to judgement.
Answer depth chosen per partner, not only per question. New — we had no equivalent.
Baud rate, parity, slave ID, register map, RTU vs TCP, ports, VLAN, DHCP vs static. In effect a specification for the first batch of diagnostic procedures, from expert knowledge — useful as a seed while the gap ledger fills.
The two documents don't compete. Read together they cover both halves of the same system — one says what the machine is made of, the other what a Tuesday looks like for the person using it.
Saying this out loud matters as much as the proposal: each of these is a plausible-sounding request that would cost real money and make the system worse.
Ordered so that everything content-dependent comes last, and the first deliverable arrives before PIERRE has written a single new page.
| PHASE | EFFORT | CONTENT | BLOCKED ON PIERRE? |
|---|---|---|---|
| Phase 0 | ~2 weeks | Version axis + feature matrix + update-risk flags · gap ledger · owner metadata | No — pure plumbing |
| Phase 1 | ~4–5 weeks | Known-issue registry · proactive alerts · escalation + Engineering Check · site kit | Partly |
| Phase 2 | ~4–6 weeks | Diagnostic procedures · draft-from-ticket generator · competence profile · field mode | Yes |
Running alongside from day one: live on internal support only. Their questions fill the ledger, and the ledger decides what Phase 2 is actually about.
None of these block starting. All three block finishing.
The knowledge base and the assistant don't come one after the other — the assistant is the only instrument that reliably says which knowledge is worth digitising, and without it the list of twenty-odd problems stays a guess.