In an example Kimon Onuma shared during the 2018 Constructrr conversation, valuable hospital requirements were distributed through paper, PDF files, and even DVDs. The owner had knowledge. The format made that knowledge difficult to reuse, connect, and challenge.
Kimon's proposal was to make reusable requirements accessible through the web, APIs, and open standards while protecting project-specific information. That distinction connected his examples of reusable requirements and protected project data.
A shared requirement can invite a better response
Kimon Onuma described work with the Department of Veterans Affairs and the Department of Defense Military Health System. Their standards contained information about rooms, equipment, and performance needs, but outside teams often had to receive and re-enter that information through closed formats.
When selected requirements became easier to connect to, consultants and vendors could respond more directly. They could also question an assumption that had stayed in the standard simply because few people could inspect it in a useful form.
Open did not mean exposing every project detail
When the conversation turned to contractors and owner data, Kimon Onuma set a clear limit: “You don't have to give everything away.” He distinguished shared requirements from sensitive information about an actual facility or project.
Kimon's point was that the owner could decide what to expose. A healthcare standard might invite input about a better room requirement while a specific secure hospital layout remained protected.
The handoff should preserve more than a final package
Later, Kimon Onuma described the information lost when designers and builders walk away and an owner has to extract useful data from the completed building. He explored tracking promises, contributors, and later performance more deliberately.
Kimon described the blockchain work as exploratory in 2018, not as a finished lifecycle system. The owner concern was more immediate: could a declared performance goal, and the people who shaped it, still be understood after handover?
Walk one requirement from source to operation
Select one owner requirement that is repeatedly copied or reinterpreted. Follow it from the owner's source through design response, construction input, and operational handoff. Mark where someone must re-enter it, where a qualified person cannot comment easily, and where the reason behind it disappears.
That walkthrough gives the owner a bounded place to improve access. The goal is not unrestricted openness across every project record. It is a requirement that the right people can use, question, and carry forward without rebuilding its meaning at every handoff.
