We spent months on factory floors before writing a line of code

Before we wrote a single line of production code, we spent the first quarter of 2026 inside industrial facilities in British Columbia and Ontario. Discovery interviews with operators, maintenance leads, reliability managers, and plant supervisors. We did not bring a prototype. We did not bring a pitch deck. We brought a recorder and a list of questions about how knowledge moves - or fails to move - inside their operations.

What we heard

The same sentence came up in four separate plants, spoken by four different people in four different roles: “When he retires, we are in trouble.” Sometimes it was “she.” The pronoun changed. The sentence did not. Every operation we visited had one to three named experts whose tacit judgment held the line together. And in every case, that judgment had never been captured in any formal system.

We heard about SOPs that were technically correct but practically insufficient. About new hires who followed procedures exactly and still made the wrong call, because the procedure did not account for the conditions they faced. About retired technicians who still fielded phone calls from former colleagues because nobody else knew why pump number four behaved differently in winter. About safety decisions that depended entirely on one person's presence on the floor.

What shaped the product

Three design principles came directly from those interviews. Not from market research. Not from competitor analysis. From sitting with operators and watching how knowledge actually moves on a plant floor.

Voice-first, because typing is not how experts think. Every operator we interviewed described their knowledge in spoken, conversational form. The moment we asked them to write it down, the nuance disappeared. The conditional reasoning vanished. The “but only when” clauses dropped out. We built Expert Studio around voice capture because that is how judgment is expressed - not in bullet points, but in stories with conditions attached.

Expert-attributed, because trust requires a name. Frontline workers on every floor we visited had the same response to the idea of an AI-generated answer: skepticism. Reasonable skepticism. But when we described the same answer with a name attached - “this is what Terry would do, and Terry approved this last month” - the response changed. The name carried weight that no algorithm can. Every answer Floor Assistant returns carries the expert's name and the date they validated it. That is not a feature. That is the product.

Expert-approved, because the expert must stay in control. We watched two attempts at knowledge capture fail at different facilities. Both failed for the same reason: the expert felt their knowledge was being extracted from them rather than shared by them. They lost ownership. They disengaged. We built an approval gate into every step of the Dedendum pipeline. Nothing reaches the floor until the expert has reviewed it, edited it if needed, and approved it with their name. The expert is not a data source. The expert is the authority.

What we built for

Dedendum is not a documentation tool. The floors we visited had documentation. What they did not have was a structured way to preserve the judgment that documentation cannot capture - and serve it back to the frontline, attributed and validated, when the expert is not on the floor.

We built for the 3 a.m. scenario: a junior operator facing a condition not covered by the SOP, with no supervisor answering the phone, needing the expert's judgment in thirty seconds on a phone screen they can read with one hand. That is the use case. Everything in the product traces back to it.

Months of listening before building. Interviews before a single component. We are not claiming that makes the product right. We are saying it makes the product grounded - in real operations, with real names, on real floors.