N.°04 — Canoa
Canoa
A vector browser-based canvas for designing with real product data.
02 What it was
A design canvas with real products inside it.
Canoa was a browser-based vector design tool for interior designers and architects. The premise was direct: designers should be able to plan with real products, not abstract rectangles. Furniture, fixtures, finishes, and product attributes lived inside the canvas so design and specification could happen closer together.
03 What it tried
i.
Vector canvas in the browser
Designers could lay out spaces, compose furniture plans, and work visually in a web-native canvas rather than a traditional desktop drafting environment.
ii.
Real product data
Products were represented with manufacturer information, dimensions, symbols, metadata, and specification context instead of generic blocks.
iii.
Design and procurement together
The ambition was to connect early design decisions to downstream specification and procurement work, reducing the gap between what was drawn and what could actually be bought.
04 Why it broke
The product universe cannot be pre-ingested.
Canoa depended on having enough available product data already loaded into the app. That assumption was wrong. Product data in the built environment is too fragmented, too contextual, and too constantly changing to solve only by pre-building a catalog.
i.
The market moves
Products are discontinued, reissued, renamed, reconfigured, and repriced. Lead times, finishes, and availability change faster than a static catalog can stay current.
ii.
The useful data is contextual
The important facts often arrive through project work: dealer quotes, client approvals, substitutions, private pricing, vendor notes, PDFs, and schedules.
iii.
The catalog was never enough
A generic product database is useful, but it is not the same as knowing what a studio actually specified, rejected, approved, paid, and reused.
05 What it taught us
01
Product data is infrastructure
A design tool becomes more useful when it understands real products. Canoa was right about that foundation.
02
Static ingestion is brittle
Trying to load the whole product universe in advance creates a constant coverage problem and misses the project-specific data that matters most.
03
Memory beats catalog
The strongest data is not only what manufacturers publish. It is the studio's own history with those products: sources, decisions, corrections, preferences, prices, and outcomes.
04
Norma follows from this
Norma keeps the product-data thesis but changes the mechanism. Instead of requiring the app to know every product first, the studio's living project records build memory over time.
06 Legacy
5 years
Research and product work around design, specification, and procurement
1
US patent covering product-data workflows in design tooling
0
AI agents, remote MCP connectors, or studio-learning claims
07 Next step
From product catalog to studio memory.
Canoa asked whether design tools could work with real product data. Norma asks what happens when the living project record becomes private, cited, askable studio memory.
i.
Canoa's premise
Design should happen with real products and real product constraints.
ii.
Canoa's limit
The app cannot depend on every useful product fact being pre-ingested before the project starts.
iii.
Norma's premise
The project itself is where the most valuable product data appears.
iv.
Norma's mechanism
Schedules, spec books, quotes, PDFs, sources, corrections, and approvals become private studio memory.
Canoa was the product-data lesson.
Norma is the memory layer that follows.
View Norma →