What happens when the knowledge needed for a good decision exists, but the owner cannot see it in a form they can verify?
In my March 13, 2018 conversation with Dan Robles, the phrase "decentralized knowledge inventory" pointed to an operating problem larger than the proposed platform. Dan's proposed technology was blockchain, and his proposed mechanism was QuantChain. The more durable issue was this: owners, operators, designers, and reviewers make decisions every day using records that may preserve documents without preserving what those documents mean, who checked them, or how much reliance they deserve.
That same problem shows up in several places at once. A resume can flatten a person's capability into titles and keywords that do not translate across industries. A project handoff can preserve a model but lose the reasoning behind a design change. A building archive can hold years of files while still leaving an operator unsure what was actually installed, maintained, or verified. A permit trail can show that an approval happened without showing what evidence justified the approval.
If an owner wants more certainty, the first question is not "Should this be on a blockchain?" The first question is more basic: what must this record help someone know, and what decision should that evidence support?
That framing still matters even if the technology proposal changes. The 2018 episode discussed blockchain, tokenization, smart contracts, and proposed future releases in that historical moment. The practical owner lesson is narrower and more durable. A useful knowledge inventory should make capability, review, history, and limits easier to see before the next decision is made.
Curiosumé began as a translation problem before it became a blockchain story
Dan did not begin the idea with a token. He began with repeated situations where capability was difficult to compare fairly.
He described early work connected to the NAFTA mutual-recognition problem: how do you compare engineers from two countries who may test equally on an academic measure but come out of different curricula, different experience tracks, and different peer-review structures? That was not a software problem first. It was an underwriting, qualification, and risk problem. In Dan's account, the actuarial comparison failed when the records could not represent those differences.
He then described Boeing's knowledge-management problem. There were experienced engineers nearing retirement, younger engineers trying to find a path, and a hollowed-out middle. In that setting, the document set did not automatically transfer judgment. A file can exist. A standard can exist. A lesson learned can exist. None of that guarantees that the next person understands when to apply the rule, when an exception matters, or why someone made a decision under pressure.
He also described the friction of moving between aerospace and construction. On the surface, the systems sound transferable: plumbing, electrical, environmental controls, structural components, doors, and windows exist in both domains. But the vocabularies, regulatory structures, and work boundaries were different enough that a keyword search could miss the capability entirely. Dan's point was not just that search tools were weak. It was that many qualification systems are built on labels that assume one industry's ontology is universal.
That part of the conversation matters for owners because procurement and selection often inherit the same problem. A team can ask for a familiar title and still fail to identify the person or team most capable of doing the work. The reverse is also true: a person can look fully qualified on paper while the record tells you very little about whether their experience actually transfers to the current problem.
In other words, Curiosumé began as a translation system for capability before it became a blockchain use case. That sequence matters. It means the real issue was not how to store data. It was how to preserve evidence of knowledge in a way that could survive different industries, different reviewers, and different decision contexts.
A familiar label is not the same as verified capability
During the interview, I described what it felt like to graduate in architectural engineering when the discipline was less familiar to many recruiters. At the time, only a few schools offered the major. I often had to explain that it was kind of like civil engineering and kind of like mechanical engineering, but not exactly either one.
That example was personal, but the problem is broader than one degree title. Owners and hiring teams routinely rely on shorthand. They use job titles, professional labels, market categories, and standard scopes because those are efficient search terms. The problem is that shorthand can hide the very distinctions that matter most.
Two people can both be "engineers" and have completely different authority, review structures, field exposure, and pattern recognition. Two firms can both say they "do facilities" while one has deep operating knowledge in occupied retrofits and the other has mostly delivered greenfield work. Two maintenance records can both show a task was completed while only one tells you whether the task addressed the right root cause.
Dan put this in stark terms: knowledge exists between our ears, and the moment we reduce it to a two-dimensional summary we lose part of the meaning. That does not make records useless. It means records need help. They need context that explains what the claim is, how it was formed, what work supports it, and who has looked at it with enough competence to make the record more reliable.
For an owner, the diagnostic question is direct: are we evaluating the capability the work actually requires, or are we only evaluating the labels our current process already knows how to sort?
That question becomes more important when the work crosses boundaries. A renovation that touches operations, insurance, code review, existing conditions, long-term maintenance, and tenant continuity may require a combination of judgment that does not fit one obvious title. If the record cannot make adjacent capability visible, the owner may either overpay for unnecessary certainty or miss the right fit because the visible label was incomplete.
Knowledge can disappear even when the documents remain
One of the most useful parts of this episode is that it separates possession of documents from possession of usable knowledge.
Construction teams often assume that if the file exists, the information has been preserved. But a file and a usable record are not the same thing. A drawing can remain while the current field condition changes. A submittal can remain while the exception discussed in review comments disappears from memory. A maintenance record can remain while the person who knew why an issue kept recurring has left the organization.
That is why closeout can feel complete and still fail the next operator. The archive may contain many files and still not answer the next practical question. What was changed? Who accepted the change? What was observed in the field? Which condition is current? Which document is superseded? What was the basis for relying on this information?
Dan's earlier knowledge-transfer examples point to the same pattern. Older engineers had knowledge younger engineers needed, but the handoff was not solved by storing more information in the abstract. The real problem was how to preserve experience in a form someone else could interpret and use.
A knowledge inventory cannot capture everything that exists in a person's judgment. It can, however, make selected evidence easier to find, compare, and trust. To do that, the team has to decide what belongs in the record:
- the capability, condition, or completed action being asserted;
- the source of evidence supporting that assertion;
- the person, instrument, or authority that reviewed it;
- the boundary of what that review actually covered;
- the date or sequence that makes the record meaningful;
- and the decision for which the record is relevant.
Without those links, additional information can increase storage without increasing clarity. The result is a larger archive that still forces each new participant to reconstruct the story from scratch.
A claim becomes more useful when its validation is visible
The part of the conversation that interested me most was Dan's distinction between a claim and the validation of that claim.
His QuantChain proposal described a system in which an individual could make a knowledge claim and another person could validate it. A token marked the event. The proposed incentive structure belonged to the 2018 concept. It should not be read here as proof that tokenization itself would produce a trustworthy professional record. The stronger lesson is simpler: a useful record should not collapse a claim, the supporting evidence, and the review of that evidence into one opaque credential.
That matters because "verified" can mean several different things.
Did someone verify that the person participated in a project? Did they verify that the person led the work? Did they review a calculation? Did they observe installed performance? Did they assess only one narrow capability inside a larger scope? Did they merely know the person socially and feel comfortable endorsing them?
Those are all different kinds of validation, and they do not justify the same level of owner confidence.
Dan connected this to a norm already familiar in engineering: another engineer checks the work. The reason that matters is not because review eliminates all failure. His point was that checking work is itself a valuable professional act. It makes the review visible. It creates accountability for what was examined. It preserves evidence that a second set of eyes with relevant competence looked at something that mattered.
For owners, that creates a practical distinction among at least four separate things:
- a claim someone makes about their own capability or contribution;
- evidence that they performed or observed relevant work;
- a review by someone with a stated basis for evaluating that evidence;
- a decision that relies on the record within known limits.
When those four things get compressed into one badge, score, or line item, the record can look much more certain than it really is.
That is also why a long list of "validated" items is not enough on its own. Owners still need to know the quality of the validation network. Who is allowed to validate? What is their basis? What happens when two validators disagree? How is a weak or careless validation corrected? Can the record distinguish between independent review and mutual reinforcement among a closed circle?
A knowledge inventory becomes more useful when it separates these layers instead of hiding them.
The technology has to fit the coordination problem
One of the strongest parts of Dan's explanation was his no-fit boundary. If the situation does not need the characteristics of a blockchain, then another technology may be simpler and cheaper.
That sentence deserves more weight than it usually receives in blockchain conversations.
Dan described the conditions that made blockchain compelling to him in 2018. Many parties may need to share a database. Many parties may need to write to it. Some of those parties may not know one another. The workflow may depend on sequence, with one action opening the possibility of the next. Responsibilities may need to stay distinct. Access and authority may need to be controlled. A real-world observation, instrument reading, or professional approval may need to trigger the next step.
Translated out of blockchain language, those are workflow questions:
- Are multiple independent parties contributing to the same record?
- Do they need to write to that record at different times without one party owning all trust?
- Does sequence matter, so that later actions should depend on earlier verified actions?
- Does the record need durable traceability when something is corrected or superseded?
- Do different participants need different rights to create, review, approve, or challenge information?
- Does the process depend on a real-world observation rather than a purely digital event?
If the answer to those questions is mostly no, an owner may not need a blockchain at all. If one accountable organization can govern the information fairly, if ordinary permissions can control access, and if standard change history is enough for the risk, then a simpler system may be the right system.
That is not a disappointment. It is a discipline. Technology should be selected after the record problem is defined, not before.
If a program starts with a platform and then searches for a problem to justify it, the decision sequence is reversed. Dan's explanation points the other way: define the participants, the evidence, the decisions, the rules, the exception path, and the trust requirements first. Then compare the available systems.
The test is not whether the technology sounds advanced. The test is whether it reduces friction without erasing accountability.
A digital record does not remove the need for professional judgment
We used the permitting process to make the idea concrete because it shows where digital workflows reach a limit.
A smart contract or automated rule cannot decide, by itself, that a field condition meets code, that a thermometer was calibrated correctly, that a structural observation was competent, or that a stamped document reflects the right scope of responsibility. At some point, the process still depends on a person, instrument, or authorized body whose judgment carries consequence.
Dan described that role as an adjudication point, like a referee stopping play to confirm the rules have been met before the game can continue. He also tied those checkpoints to transfer of risk. A permit approval, inspection sign-off, professional stamp, or certificate of occupancy can mark a moment when one party is allowed to rely on the work of another.
That lens is useful well beyond permitting. Owners can map many decisions the same way. Where does risk transfer from designer to constructor? From constructor to owner? From capital project team to facility operations? From internal maintenance staff to outside service provider? At which points should the record show more than "approved"?
The key question is not whether the workflow can record the event. Most systems can record an event. The harder question is whether the record preserves why the event deserved reliance.
If an approval appears in the log but the basis for the approval is inaccessible, then the next user inherits the appearance of certainty without the supporting logic. It can encourage reliance on something that looks official but has lost its reasoning.
A digital workflow is useful when it helps the team identify where judgment enters, what evidence should exist at that point, who has authority to supply or review it, and what happens if the evidence is disputed or incomplete. Automation should make those boundaries clearer, not blur them.
Capability-based records could change who becomes visible
The conversation also explored a different possibility: what if a capability-focused record could help owners and teams look past familiar networks and demographic shortcuts?
Dan described a statistical approach for matching people or teams to the probability of performing particular work. In his example, the owner would not just search for a standard title. The owner could describe the problem and evaluate candidates according to relevant capability probability rather than irrelevant personal information.
I connected that idea to a reality many people in the industry already recognize. People work with who they know, like, and trust. Familiarity can also become a substitute for examining capability carefully. It can make unfamiliar professionals less visible even when they have adjacent experience that fits the work.
As a woman and a minority in the industry, I raised the question directly in the interview because familiarity and unconscious bias are not abstract issues. They change who gets considered, who gets explained away, and who gets the chance to prove capability on the basis of the work.
That said, this part of the 2018 conversation should be handled carefully. It expressed an aspiration, not a validated anti-bias result. A capability system can still reproduce bias through its definitions, its validation network, its entry rules, its missing history, and its economic incentives. Removing names or demographic traits from one dataset does not automatically produce fairness. Someone still chooses which capabilities count, which histories receive credit, and whose validation carries weight.
So the owner-side question goes beyond "Can the system hide irrelevant attributes?" The more demanding questions are:
- Who gets to enter the inventory in the first place?
- Whose prior work is legible enough to be counted?
- Who is allowed to validate others?
- Can adjacent or emerging experience be recognized, or only experience that already fits old categories?
- What remedy exists if a record is inaccurate, incomplete, or unfairly interpreted?
A useful capability record should widen the evidence an owner can consider. It should not replace judgment with a score and call that fairness.
Building records should make conscientious ownership visible
Dan then shifted the idea from people records to asset records, and that is where the owner relevance becomes especially concrete.
He described two buildings: one with strong maintenance records, funded reserves, and no insurance claims in his example, and another with poor stewardship but a better visible location. His argument was that the market may not reward conscientious ownership if the evidence of that care is hard to see, hard to compare, or easy to manipulate. In that situation, disciplined ownership can become economically invisible.
He used Carfax as an analogy. The point of the analogy was not that the built environment works exactly like automobile resale. It was that a few comparable, trusted records can make a market more efficient because buyers no longer have to infer everything from surface appearance alone.
That is the part owners can use now, even without adopting Dan's proposed platform. What information would make responsible care visible to the next decision-maker? Which records would help an operator, insurer, buyer, project team, or lender distinguish between disciplined stewardship and superficial presentation?
Dan named several categories from the episode's 2018 perspective: BIM information, maintenance records, transfers of ownership, lease information, and related asset history. The more enduring lesson is that useful asset memory requires more than storage. It requires custody, context, and status.
The owner needs to know not only that a record exists, but whether it is current, what it refers to, who created it, who reviewed it, what it superseded, and what someone should reasonably infer from it.
That is why missing plans are such a practical example. Dan talked about teams having to open walls and perform exploratory work because they could not find reliable original records. The consequence can include uncertainty, avoidable disturbance, and the possibility of damaging something the team did not know was there.
A building archive can look complete and still fail that test if the plan set is obsolete, the maintenance log does not identify the asset clearly, or a field change never made it into the record. A useful history has to help the next person answer: what is the current condition, how do we know, and what confidence should we place in that answer?
Better risk conversations begin with better evidence
The later part of the episode moved into insurance, maintenance, and incentives. Dan described insurance as a statistical enterprise that depends on accurate categorization of risk. He argued that more precise asset and maintenance information could improve pricing, classification, and potentially enable new insurance-like products.
Treat those proposals as historical design ideas, not current insurance guidance or measured market outcomes. They do not demonstrate that QuantChain reduced premiums, improved valuation, or changed maintenance costs.
What does remain useful is the evidence question underneath the proposal.
Insurers, owners, engineers, operators, and buyers often look at the same asset through different risk lenses. One cares about replacement cost and pool classification. Another cares about maintainability and capital planning. Another cares about the probability of failure during occupancy. Another cares about whether a planned renovation is walking into an unknown condition.
If the record cannot distinguish between observed condition and assumption, planned maintenance and completed maintenance, professional review and unreviewed entry, then those parties are effectively pricing and managing different versions of reality.
Dan gave a specific example with galvanized piping. In his telling, some insurers treated the label itself as enough to trigger concern, even though the actual underlying risk could vary. The example shows how a coarse category can make pricing and decision-making less precise than the available evidence would allow.
He also discussed a speculative concept in which validated maintenance needs might become insurable events, helping owners smooth cash flow instead of swinging between periods with little work and periods of urgent failure. Again, that was a proposal, not a documented current product. But it reveals a stronger question for owners: does the current record reward maintenance discipline, or does it mainly reward short-term deferral until a failure becomes impossible to ignore?
If no later decision-maker can see or trust the maintenance record, the person doing the right work may receive little practical benefit for preserving it. Evidence changes incentives only when someone can use it later.
Start with one owner decision, then work backward
Dan's no-fit boundary gives owners permission to start smaller and more practically than "reinvent the system."
Begin with one recurring decision the current record does not support well. It might be selecting a specialist for a narrow scope, evaluating whether an existing condition can be relied on, transferring a facility from project delivery into operations, validating a maintenance need before capital planning, or deciding whether a renovation risk has been reduced enough to proceed.
Once that decision is named, the record design becomes more disciplined.
1. What must the decision-maker be able to verify?
Identify the fact, capability, condition, or completed action that could change the decision. Be specific. "Good records" is not specific enough. A decision about an occupied renovation may require confidence about current system location, recent field observation, authority of the source, and date of verification. A total archive of unrelated documents may add very little.
2. What evidence can support that point, and what can it not prove?
A drawing may show design intent without proving installed condition. A closeout form may show completion without proving performance. A professional credential may show eligibility without proving fit for this exact scope. The record becomes stronger when it preserves both evidence and the boundary of what that evidence can establish.
3. Who is allowed to make the claim, and who is allowed to validate it?
Separate assertion from review when the risk justifies it. A peer validator, municipal reviewer, licensed professional, owner representative, sensor, and field technician each provide different forms of assurance. The record should show which kind of assurance is present rather than collapsing them into one generic "verified" state.
4. Where does judgment enter the process?
Map the permit, inspection, stamp, acceptance, turnover, or exception-review points where the workflow depends on human or instrumented adjudication. Those are the places where the record most needs clarity, because they often coincide with transfer of risk.
5. What happens when the record is incomplete, disputed, or wrong?
Immutable history is not the same as accurate current state. The system needs a correction path, a dispute path, and a way to show when an earlier record has been superseded without pretending it never existed. Owners should know who can make that correction and what evidence is required to do so.
6. Who needs this information later?
Name the downstream user: operator, buyer, insurer, project executive, regulator, owner representative, or service team. If no later user is clearly identified, the record is more likely to become a compliance deliverable than an operating asset.
7. What is the simplest system that can preserve the required trust?
Only after the earlier questions are defined should the team compare a standard document-control process, common data environment, credential workflow, conventional database, or shared ledger. If one accountable organization can manage the record fairly and credibly, a simpler architecture may be sufficient. If shared control, traceability, sequential dependence, and low-trust participation are essential, a more distributed model may deserve consideration.
Starting with architecture would skip the proof the owner actually needs.
What a knowledge inventory should prove
The episode points to one owner-facing standard: a knowledge inventory should help someone make a better decision by making evidence, responsibility, history, and limits easier to see.
It should not ask the next user to rely on labels alone.
It should not confuse a claim with a validated record.
It should not hide where human judgment entered the workflow.
It should not make conscientious ownership invisible.
And it should not force a more complex technology onto a problem a simpler record could already solve.
Dan's 2018 proposal was ambitious. It included blockchain, QuantChain, adjudication points, token incentives, and broader hopes about the future of engineering knowledge, asset history, and market behavior. Those details belong to that moment. The enduring operating lesson is that better decisions require better records, and better records require more than storage.
A useful inventory proves what is being asserted, who reviewed it, what evidence supports it, where its limits are, and why someone downstream should trust it enough to act.
That is the standard worth designing for first. The technology should follow it, not replace it.
