Introducing Norma

The next question

Canoa started with a simple observation: product data is infrastructure for design.

Designers do not specify abstract objects. They specify real products: chairs, tables, lights, textiles, appliances, plumbing fixtures, hardware, finishes. Every one of those products has dimensions, options, finishes, lead times, symbols, images, cutsheets, prices, certifications, substitutions, and constraints. A design tool that understands products should be more useful than one that treats them as rectangles with labels.

Canoa was built around that belief: a design tool with product data inside it. The ambition was right. The implementation assumption was wrong.

The tool depended on having the product universe pre-ingested into the app.

That sounds reasonable until you spend enough time with the market. Product data in the built environment is not one catalog waiting to be imported. It is a moving field of manufacturer pages, dealer quotes, PDFs, CAD blocks, finish cards, discontinued SKUs, custom options, regional lead times, private pricing, substitutions, and project-specific decisions. The useful data is always arriving late, in the wrong format, from the wrong source, with context attached.

Trying to pre-ingest all of it is not just hard. It misses the point.

The most valuable data in a studio is not the generic product catalog. It is the studio’s own history with that catalog.

What did we actually specify? Which vendor came through? Which finish did the client approve? Which SKU caused trouble? Which chair keeps showing up in hospitality projects? Which product looked good but had a 16-week lead time? Which dealer quote had the right pricing? Which substitutions did we accept, and which ones did we reject?

Architecture Studio came from a different angle.

Architecture Studio was a test of how to structure a Claude implementation for the built environment. Not just prompts, but an orchestrator, agents, skills, rules, tools, source expectations, and review patterns. It proved that AI becomes more useful when the model is surrounded by domain structure.

But it also exposed a limit.

Architecture Studio had orchestration. Canoa had product data. Neither had real memory or agency.

That knowledge exists. It is just scattered across emails, PDFs, schedules, quotes, source links, comments, and memory.

Norma is our answer to that problem.

A practice that remembers

Norma is a product and materials specialist for architecture and design studios.

Put Norma on a project and give it the living document: the FF&E schedule, the spec book, the product list, the procurement tracker, whatever your studio already uses to hold decisions as the work develops. Norma works from that project record, follows the gaps, checks the sources, cites what it finds, and files the approved knowledge into the studio’s private library.

The first use is practical. A schedule gets checked for stale pricing, missing dimensions, broken source links, and unresolved substitutions. A spec book gets filled with source-backed product facts. A vendor PDF becomes useful because it is connected to the actual project record, not because someone forwarded another attachment into another system.

The long-term use is more important.

Every pass builds memory.

Not a generic memory in the abstract sense. A concrete product memory: the products your studio has touched, the vendors you have worked with, the finishes you have approved, the prices you have seen, the lead times that changed, the corrections you made, the preferences you confirmed, and the decisions that should not need to be rediscovered on the next project.

This is the shift:

Tool	Primary question	What accumulates
Canoa	Can a design tool understand real products?	Product-data lessons, schedule logic, and the limits of pre-ingestion
Architecture Studio	Can Claude be structured for professional workflows?	Orchestration, agents, skills, rules, and tools
Norma	Can a studio remember and act on its own work?	Private project history, preferences, sources, decisions, and agency

Norma is not just another interface around an LLM. The interface is the least interesting part. The schedule is enough. The spec book is enough. Claude, email, PDFs, and spreadsheets are just surfaces around the same project record.

The product is the memory layer.

Why memory matters more than automation

Most AI product pitches in AEC still lead with automation: save time, reduce manual work, generate a report faster, fill a spreadsheet faster, draft an email faster.

Those are real benefits, but they are not enough.

If an AI system only automates a task, the value ends when the task ends. You saved thirty minutes. Useful, but perishable.

If the system also captures what happened, the task becomes an asset.

A quote does not just become a row. It becomes a cited record of a product, vendor, price condition, lead time, and date. A correction does not just fix today’s schedule. It teaches the system how your studio wants that product represented. A substitution does not just solve a procurement issue. It becomes part of the studio’s history of acceptable alternatives.

That is the difference between a tool and a practice memory.

Studios already have this memory, but it is trapped in people and fragments:

The senior designer remembers which vendor failed on the last hotel.
The project manager remembers which product had lead-time issues.
The intern has the latest quote buried in an email thread.
The spreadsheet has a product name but no source.
The PDF has the dimensions but no relationship to the schedule.
The approved finish is in a client deck, not the spec.

The industry calls this experience. Software usually treats it as unstructured noise.

Norma treats it as the asset.

Mess as signal

This connects directly to the thesis we have been sharpening at ALPA: the built environment runs on data nobody indexed.

The wrong conclusion is that someone needs to impose one universal schema on the industry. That sounds clean, but it misunderstands why the data is valuable.

The built environment is not one deterministic system. It is a field of overlapping practices: architects, interior designers, dealers, manufacturers, reps, contractors, clients, consultants, jurisdictions, procurement teams, and owners. Each has its own vocabulary, formats, incentives, shortcuts, and exceptions.

That mess is not a defect to erase. It is evidence of how the industry actually works.

The point is not to flatten every schedule, quote, and product page into one master model. The point is to build enough contextual structure for useful work to happen, while preserving the source, ambiguity, and local meaning of the data.

Norma’s job is not to declare that every studio should specify the same way.

Norma’s job is to learn how your studio specifies.

That means a record can be structured enough to use and still honest about where it came from:

This dimension came from a manufacturer PDF.
This lead time came from a dealer quote on June 2.
This finish was inferred and needs review.
This price is private to the studio.
This product was rejected on a healthcare project but approved for hospitality.
This vendor is acceptable for one team but not another.

The structure is contextual because the work is contextual.

Studio memory and shared product facts

Norma separates two kinds of knowledge.

The first is studio memory. This is private. It includes your specs, quotes, pricing, corrections, preferences, project history, vendor relationships, approved substitutions, rejected options, and the way your team tends to make decisions.

That data belongs to the studio. It should not be pooled across firms. Dealer-net pricing should not leak. Project history should not become someone else’s training set. A firm’s preferences are part of its practice, not generic product metadata.

The second is shared product facts. These are public or manufacturer-supplied facts: product names, dimensions, materials, public SKUs, finish families, certifications, symbols, and source URLs. These can compound across the system when handled carefully. If one product page has already been parsed and normalized, the next studio should not pay the same extraction cost again.

The boundary matters.

Norma can make public product facts cheaper and more reliable over time without turning private studio knowledge into a shared pool. The shared layer improves the baseline. The private layer preserves the moat.

That distinction is the business.

Generic product data is useful. Studio-specific memory is defensible.

What Canoa taught us

Canoa taught us that product data matters, and that static product databases are not enough.

Furniture and materials are deceptively messy. A chair sounds simple until the system needs the right dimensions, finish options, COM requirements, certifications, lead time, pricing context, manufacturer URL, dealer quote, CAD symbol, image, and substitution logic.

The public web has pieces of this. Manufacturer websites have pieces. Dealer quotes have pieces. Studio schedules have pieces. No single source has the whole answer.

Canoa’s original bet was that if enough product data lived inside the tool, designers could work faster and with more intelligence. That was true in the moments where the data existed. But the dependency was too brittle. A design tool cannot wait until the entire product universe is clean, normalized, and pre-loaded.

The data has to be captured as the work happens.

A product is not just a product. It is a history of use.

The same sofa means different things depending on whether a studio saw it in a quote, approved it for a lobby, rejected it for lead time, requested a red textile, substituted it during procurement, or used it successfully across five projects.

Canoa taught us the importance of product intelligence.

Norma changes where that intelligence comes from.

Instead of asking the app to know every product in advance, Norma lets the studio’s own work build the library over time.

What Architecture Studio taught us

Architecture Studio taught us how to structure AI work.

Before building a more agentic product, we needed to understand what a useful Claude implementation actually required. The answer could not be guessed from a generic chatbot. It had to come from real architectural tasks: zoning analysis, site research, workplace programming, product research, EPD parsing, specification writing, schedule cleanup.

Skills were the right primitive for that stage. They made the work explicit. Each skill encoded a task, an input pattern, source expectations, output rules, and failure modes. Agents then started composing those skills into workflows.

That taught us three things.

First, architects will use AI when it speaks the language of their work. They do not need to be convinced that automation is interesting. They need to trust that the output is sourced, specific, and reviewable.

Second, the built environment is too broad for one monolithic app. A due diligence workflow, an FF&E workflow, and a sustainability workflow have different sources, rules, and review patterns. The architecture has to be modular.

Third, orchestration is not the same as agency. Routing a task to the right skill is useful. Running a workflow with rules and tools is useful. But a system without durable memory still starts too much work from zero.

Architecture Studio made the workers visible.

Norma gives those workers memory and agency.

What Norma does

Norma starts with the project record.

Schedules and spec books do not begin as emails. They are living documents that carry decisions across the project: what is being considered, what was approved, what changed, what needs pricing, what needs a source, what is waiting on a vendor, what is ready for procurement.

Norma joins that record and works around it. Email can still be an input. So can a PDF, a vendor link, a quote, a catalog, a source page, or a conversation inside Claude. But the center is the project document, not the inbox. Norma is there to help maintain the work as it lives, not to make the team learn another intake workflow.

The library is the review surface. Products carry trust states: verified, needs review, stale, missing fields. Imports can produce receipts. The schedule or spec book stays in the tools the studio already uses — Excel, Google Sheets, a spec-writing workflow, a project folder — while Norma gives those tools a private corpus to consult: product memory, source history, review state, vendor context, URLs, parsed PDFs, and prior decisions.

From there, Norma does five things.

Parse. It reads the artifacts that define products: PDFs, quotes, vendor pages, spec sheets, catalogs, configurators, EPDs, schedules, and source links.

Clean. It normalizes messy schedules without pretending every studio uses the same columns. It maps the work into a structure that is useful for the task at hand.

Enrich. It fills missing fields with sourced facts: dimensions, materials, finishes, options, lead times, certifications, URLs, and notes.

Audit. It checks for drift. Prices change. Lead times move. Product pages disappear. Specs go stale. Norma can re-check sources on a cadence and surface what changed before client review.

Stage. It prepares schedule- and spec-ready material: rows, notes, export candidates, source refreshes, comparisons, and review holds. In a Claude workflow, the studio can use Norma’s corpus to make product decisions, fetch data and URLs, parse PDFs, build an XLS schedule, update a Google Sheet through Claude’s native integrations, or draft a spec-book section without treating Norma as the place where all project documents must live.

Remember. It files approved facts, corrections, preferences, and decisions into the studio library so future agents can reuse them.

The last verb is the point.

Parsing without memory is a convenience. Memory changes the economics of the practice.

What this means for a studio

The first month with Norma should feel simple.

You put one agent on one project. It reads the current schedule or spec book, identifies what is missing, traces products back to sources, proposes clean updates, and leaves uncertain fields for review. You approve, correct, or reject. Depending on the workflow, the next surface might be an XLS schedule, a Google Sheet update through Claude, a spec-book draft, or a note back to the project team. The library starts forming underneath.

A few projects later, the behavior changes.

You ask for “the red sofas we looked at last spring” and Norma can answer with products, vendors, finishes, and sources. You start a new hospitality project and the system knows which vendors your studio tends to trust. You audit a schedule and Norma flags products whose lead times have changed since the last client review. You add a new designer and they inherit the studio’s product memory instead of starting from a blank search bar.

This is not about replacing designers.

It is about giving the practice continuity.

Small studios feel this most acutely. They cannot afford a dedicated product librarian, full-time specs manager, procurement analyst, and data steward. So the work gets distributed across people who are already busy. The result is predictable: duplicated searches, stale schedules, orphaned quotes, repeated decisions, and knowledge loss whenever a project ends or a person leaves.

Norma is built for that gap.

It is staff, not software.

The research step

For ALPA, Norma is not a pivot away from Canoa or Architecture Studio. It is the logical next research step.

Canoa asked: what happens when design tools understand product data?

Architecture Studio asked: what happens when Claude is structured with orchestrators, agents, skills, rules, and tools?

Norma asks: what happens when every project interaction becomes part of a private, cited, askable studio memory that can act?

That is the question we care about now.

Because the durable value in AI for the built environment will not come from a prettier chat window. It will come from systems that understand the work, preserve the source, respect the mess, and let a practice compound its own knowledge over time.

Norma is our attempt to build that system.

You can follow the product at norma.llc.

Norma is built by ALPA - research, strategy, and technology for the built environment.