Available now
Working today and available to inspect or evaluate on this site.
The direction
Most businesses can deliver more than their storefront can express.
Businesses are losing high-intent demand because their digital storefronts expose products, not capability. Specify is building the infrastructure that lets a customer describe an outcome, and lets a business answer with what it can genuinely, responsibly deliver.
Customers should be able to describe the outcome they need. Businesses should be able to expose what they can responsibly deliver. Specify connects the two without hiding constraints, inventing authority or reducing capability to a fixed catalogue.
Three labels are used throughout this page: Available now, Next hypothesis, Long-term direction.
The thesis
Commerce is becoming a conversation again
Industrial commerce scaled by standardising products. The internet digitised the catalogue. Now programmable production and AI make it possible to scale something different: the process of determining what should be made for each customer.
The commercial problem
The demand that never becomes a transaction is the demand nobody measures.
Businesses are losing high-intent demand because their digital storefronts expose products, not capability.
- Customers reach a dead end whenever the catalogue holds no exact match, even when the business could have helped.
- High-intent custom enquiries stay trapped in email, telephone calls and spreadsheets, where nothing about them is structured or measurable.
- Businesses sell a fraction of what they can actually produce, because only the published fraction is visible.
- Customer intent that does not convert leaves no record at all, so the same demand can be missed indefinitely.
- Specialist merchants lose to larger platforms on completeness and convenience rather than on capability.
- Several merchants together could often fulfil a request, but their capabilities are fragmented and cannot be combined.
None of these are marketing problems. In each case the storefront has made a commercial decision, that this request cannot be served, which the business itself never made and would often disagree with.
A catalogue is a list of answers prepared in advance. Demand does not arrive in that shape.
The problem
What the catalogue cannot express
These product directions respond to a connected set of problems created by catalogue-based commerce: dead-end discovery, manual custom sales, uncaptured intent, hidden capability, weak machine readability and fragmented fulfilment.
How to read this page
Three labels, used consistently, so nothing here has to be guessed.
This page describes a system and a direction. Each forward-looking section carries one of these labels, and the boundary at the end restates exactly what exists today.
Next hypothesis
Designed, and being validated with the first implementations. Not yet delivered.
Long-term direction
Where the infrastructure is intended to go. Not a commitment and not a timeline.
Specify has no verified customer results. Nothing on this page is a measured outcome.
The same customer, the same factory
A different route to the same question: can we do this?
Nothing about the production floor changes between these two columns. What changes is whether the request ever reaches the people who could answer it, and in what condition it arrives.
Today
Customer browses the catalogue
No exact match exists
Contacts sales, or leaves
Leaves silently, and no record of the request survives
Requirements clarified by hand, over days
Feasibility checked across departments
A quotation may or may not be produced
- The work is real, skilled and repeated for every enquiry.
- Nothing about it accumulates: the next identical request starts from zero.
With Specify
Customer describes the outcome they need
Missing information is collected by asking
The request becomes a Structured Opportunity
Capability and constraints are evaluated
A responsible outcome is returned
The decision and any unmet demand are recorded
- The specialists still decide. They decide sooner, with the evidence assembled.
- Every outcome, including the rejections, becomes commercial memory.
The second column is not automation of the first. It is the same commercial judgement, reached with the information it always needed.
What the system creates
Five commercial objects, each with a job the business can name.
- 01 Customer intent
- 02 Structured Opportunity
- 03 Capability Map
- 04 Constraint Record
- 05 Commercial outcome + Decision Record
- 06 Opportunity Ledger
Each object exists because it changes what the business can do commercially:
- Structured Opportunity: makes a vague enquiry sellable, by turning it into facts, unknowns and acceptable alternatives.
- Capability Map: lets the business sell everything it can deliver, not only what has been published.
- Constraint Record: lets the storefront say yes safely, by stating what may be offered, under which conditions and with whose approval.
- Decision Record: makes every answer explainable and attributable, so the business can stand behind it.
- Opportunity Ledger: converts lost demand into product and market intelligence.
The resulting outcome may be:
- An existing product
- A valid configuration
- A modified product
- A made-to-order or custom specification
- A responsible alternative
- Expert review
- A solution involving connected capabilities
- A clear rejection
What makes this different
Specify is not AI for ecommerce, and it is not a rules engine. It is the combination.
AI provides the conversational and interpretive layer. Structured capability, constraints, authority and human approval provide the commercial truth.
A language model alone cannot know what your factory can produce, which combinations your engineers have ruled out, or who is allowed to commit to a delivery date. Asked anyway, it will produce a confident answer, and a plausible answer presented as an offer is worse commercially than no answer at all.
A rules engine alone cannot read an email. Real demand arrives as prose, with the decisive constraint buried in a sentence about a building that opens in August. Something has to interpret it before any rule can be applied to it.
Both halves became practical at the same time. Production became more programmable and modular, and models became good enough to turn informal intent into structured requirements, ask the relevant question, and compare a request against products, capability, constraints, price logic, lead times and fulfilment options.
This does not mean producing anything a customer imagines. It means creating a scalable way to determine what can be produced, configured, modified, sourced or responsibly declined. Mass production standardised the product; this standardises the process of specifying different outcomes.
Where this applies
Any business whose customers ask for things the catalogue cannot express.
Specify is not defined by an industry. It is defined by three commercial conditions, which either hold in a business or do not:
Demand arrives as requirements, not SKUs
- Customers describe an outcome, a space or an application.
- The decisive detail is often a constraint, not a product name.
- No published page can represent every valid answer.
Capability exceeds the catalogue
- Materials, methods, modifications and suppliers exist beyond what is listed.
- Product families have ranges and rules that were never published.
- The business routinely delivers things its website cannot describe.
Authority is distributed
- Sales, technical, operations and production own different decisions.
- Price, feasibility and delivery cannot be inferred from plausibility.
- Someone must be accountable for the answer that goes out.
A manufacturer asked for an 18 metre run of lockers with integrated benches, in two delivery phases, is a concrete illustration of all three. So are custom interiors, industrial configuration, personalised goods, made-to-order furniture and specification-led B2B supply.
Next hypothesis / The merchant operating system
Specify stays useful long after the first request has been evaluated.
-
Merchant agents maintain the Capability Map
Capability changes constantly: a new material, a new machine, a supplier that stopped. Keeping the map current by hand is the reason capability data usually rots. An agent that proposes updates for approval is the reason it might not.
-
Product and production information updated conversationally
Describe a change in ordinary language, review the proposed edits, approve them. No spreadsheet import and no field-by-field admin screen.
-
Storefront content improved continuously
Descriptions, specifications and imagery are proposed against what customers actually asked, rather than rewritten on a schedule.
-
Customer journeys audited automatically
Where specification journeys are abandoned, and at which question, becomes visible instead of invisible.
-
Missing product information detected
The questions customers keep having to ask are exactly the information the storefront failed to publish.
-
Experiments suggested and prepared
The system proposes what to change, sets up the comparison and reports what happened, rather than leaving the business to invent hypotheses unaided.
-
Practice benchmarked against the ecosystem
How this storefront compares to well-run specification journeys, using anonymised patterns rather than exposed competitor data.
Next hypothesis / The Automated Improvement Audit
A second product line: inspect the whole storefront, not one enquiry.
The Enquiry Audit answers a narrow question: what happened to this one difficult request? A far broader question sits behind it. Most storefronts lose demand long before the catalogue runs out of answers, and for reasons nobody has inspected.
The complimentary Enquiry Audit available today is one narrow part of this. It inspects a single customer request. The wider audit inspects the storefront that request had to survive.
What the wider audit inspects
- Product information: what is missing, ambiguous or contradicted elsewhere
- Questions customers ask that the site never answers
- Accessibility, and who is being quietly excluded
- Checkout, and the path from interest to a request
- Trust signals, and whether the claims made are supportable
- Imagery and product representation
- Readiness of the journey from intent to order
What it will not do
- Predict revenue, conversion or return on investment
- Change a live storefront without approval
- Replace a designer, developer or merchandiser
- Compare you against figures that cannot be verified
Both audits share one principle: inspect the evidence, name what is missing, and never present a generated observation as a measured fact.
Expert implementation
An audit identifies the gap. Consulting helps close it.
Some improvements can be prepared by software. Others require commercial judgement, capability modelling, content, design, implementation or coordination across teams. Specify consulting helps turn the finding into a practical next step.
Available now, delivered by people
Next hypothesis / The self-improving loop
The system gets better at commerce every time it is used.
Every evaluated request can improve the next specification journey without exposing confidential merchant information.
Customers express requirements
In their own words, including the parts no product page asked about.
Specify structures and evaluates
Facts, unknowns, alternatives and the applicable constraints are separated and made explicit.
The merchant responds
A person decides, with the evidence assembled rather than scattered across inboxes.
The outcome is recorded
The decision, the constraint that governed it, the reasoning, and any trade-off the customer accepted.
Patterns become visible
Repeated records reveal missing capability, missing information and unserved product opportunities.
The next journey improves
Questions, matching, content and approval thresholds are refined, so the next customer meets a better process.
Nothing in this loop requires a merchant's proprietary data to leave their own model. The value compounds from patterns, not from exposure.
The strategy underneath
How Specify decides what better means
The loop above learns what a customer wanted. A second loop, running underneath it, decides what a good commercial experience is supposed to do in the first place, and rewrites that position when the evidence disagrees. It is the part of the strategy that determines whether Specify is still worth using in ten years.
Strategy, not delivered capability
Long-term direction / The data advantage
A dataset about what people would buy if it could be responsibly offered.
Catalogue analytics record what was bought from what was published. That is a record of the answers a business already had. Specify records what was wanted, what prevented it, and what would have been acceptable instead.
That record contains things ordinary ecommerce platforms structurally cannot see: failed specifications, near matches, the trade-offs customers were willing to make, requirement-specific price sensitivity, repeatedly requested sizes and materials that do not exist, which questions improve completion, and where capability is simply absent.
Level one: merchant intelligence
What this business is failing to serve, in its own product families and its own customers' words. Actionable immediately, and owned entirely by the merchant.
Level two: category intelligence
Which unmet requirements recur across a market rather than in one business. This is where a product gap stops looking like an anomaly and starts looking like a decision.
Level three: ecosystem intelligence
Where new capabilities, suppliers, products or entire companies would need to exist for the demand to be served at all.
Merchant confidentiality is structural rather than a policy promise: the levels above are built from aggregated and anonymised patterns, and one merchant's records never become another merchant's insight.
Long-term direction / The capability network
Specialists should not have to become generalists to compete with one.
Larger platforms rarely win on capability. They win on completeness and convenience: one place, one basket, one delivery. A specialist manufacturer with better products loses the order because it could only supply part of what the customer needed.
One governed representation, today
- A Capability Map describes what a single business can responsibly deliver.
- Its owners approve it, and it governs what that storefront may offer.
- This is the unit currently being built and validated.
Connected maps, over time
- Maps that describe capability in the same structure can be read together.
- Merchants, suppliers and producers become nodes rather than silos.
- The result is a capability graph rather than a set of separate catalogues.
What the graph makes possible
- Requests no single business could fill become fulfillable by several.
- Sourcing and production requests carry their constraints with them.
- Specialists keep their specialism and still answer the whole request.
The unit it is built from, one honest Capability Map, is the thing being built today. What a connected graph would then make possible is a single place for a customer to ask.
Long-term direction / The aggregate platform
One place to ask is not the same thing as one company to buy from.
Completeness and convenience are properties of where a customer arrives, not of the company standing behind it. If a requirement could be described once and answered by whichever specialists can genuinely deliver it, the advantage of one place, one basket and one delivery would stop belonging to whoever holds the widest catalogue.
The long-term version of that is a place a customer could come to directly, describe an outcome rather than search for a product, and have the request answered by the network rather than by a single storefront. A request arriving there would be evaluated against:
- Products already published across the network
- Capability merchants can deliver but have never published
- Supplier and production capability reachable through connected Capability Maps
- Demand already recorded as unserved, so a requirement that keeps recurring is recognised as a pattern rather than treated as a first
What comes back would be the outcomes one Capability Map can already produce, without the ceiling of a single business: a standard product, a valid configuration, a made-to-order specification, or several merchants each supplying the part they are best at. A solution involving connected capabilities is already listed on this page among the possible outcomes. It is simply the one a single storefront can rarely reach alone.
Specify would not be the seller. A matched request would be routed to the merchants, suppliers and producers able to deliver it, and the commercial relationship would stay with them: they price the work, commit to it, fulfil it and keep the customer. Where an outcome is agreed, the order could be completed at that point rather than restarting as an enquiry somewhere else, which changes where a transaction happens and not who is accountable for it.
None of that would be a marketplace with a longer list of products on it, and none of it would make Specify the generalist this page argues against. Specify holds no catalogue, no stock and no production of its own. A marketplace aggregates what has already been listed; this would aggregate what a network can create, configure, source and fulfil, which is always the larger set.
Aggregating demand here means making it visible, not pooling it. The Opportunity Ledger read at network scale would show which requirements keep arriving and keep going unserved, across businesses that each see only their own share. It is not a mechanism for grouping customers together until a production run becomes worthwhile.
A front door is only worth walking through if what stands behind it is real, governed and accountable to someone. So the work runs in the other direction: one honest Capability Map first, then maps that can be read together, and only then a place worth arriving at.
Long-term direction / Why it compounds
Each of these gets better because of the others. That is the whole mechanism.
More customer requests
Intent intelligence sharpens: better questions, better interpretation, fewer unnecessary clarifications.
More merchants
Fulfilment broadens, and requests that previously ended in a rejection find a route.
More capability data
Matching improves, because there is more structured ground truth to match against.
More recorded decisions
Constraint logic and approval thresholds improve, informed by outcomes rather than assumptions.
More suppliers and producers
Previously impossible requests become feasible, because the missing capability now exists in the graph.
More implementations
Commercial knowledge becomes reusable: what worked in one specification journey informs the next.
None of this compounds from scale alone. It compounds because every participant contributes structure the others can act on.
Long-term direction / The interface shift
When customers stop browsing pages and start asking assistants, a catalogue is not an answer.
Commerce is moving from browsing and filtering toward describing a need to an assistant and expecting it to be handled. A product feed cannot serve that. It can list what exists; it cannot say what is possible.
To answer for a business, an AI system needs authoritative access to:
- Whether the thing can actually be produced
- Which options and combinations are supported
- Which constraints apply, and to what
- Who must approve it before it is offered
- What it may cost, under approved price logic
- When it could realistically be delivered
- Whether it can be ordered at all
Without an authoritative source for these, an assistant will either refuse or invent. The second is considerably worse, because an invented commitment still arrives at a real business with a real customer expecting it.
This interface shift is part of a longer commercial cycle: from conversation, to catalogue, and now toward mass specification.
This is the strongest reason the underlying structure matters more than any single interface. Capability, constraints and authority are what an AI-mediated purchase actually needs, and almost nobody holds them in machine-readable form.
Sequence
Expose one business's capability. Then connect many.
Evaluate demand for one business
- Guided customer requirements
- Structured Opportunities
- Capability Maps and Constraint Records
- Human review and Decision Records
- Opportunity Ledger capture
- A working end-to-end example
Run the business on it
- Dynamic product and configuration matching
- Merchant agents for capability and storefront management
- The Automated Improvement Audit
- Pricing and lead-time logic where the business approves it
- Automated improvement and experimentation
- Richer intent intelligence
Connect the commercial chain
- Supplier and production capability networks, with structured sourcing requests
- Cross-merchant and cross-platform fulfilment
- A customer entry point that routes demand to merchants
- Commerce APIs for AI assistants
- Shared knowledge and anonymised ecosystem intelligence
- A venture ecosystem for demand-driven companies
- Customer demand
- Merchant capability
- Supplier and production capability
- Commercial agreement
- Production
- Fulfilment
Long-term direction / The venture ecosystem
If I am building a company around configurable or demand-driven products, I should build it on Specify.
That sentence is the destination. It is not true yet, and nothing below is an available programme. It is what the infrastructure would have to make possible to have been worth building.
Venture calls
Open invitations to build in categories where unmet demand has already been observed.
Platform credits
Infrastructure access for new companies before they have the revenue to pay for it.
Capability modelling
Help turning what a new business can make into a structure that commerce can act on.
Implementation support
The engineering work of getting a specification journey live, done alongside the founders.
Commercial playbooks
What has repeatedly worked in specification-led selling, written down rather than rediscovered.
Knowledge sharing
Practical learning from implementations, specialists and experiments across the ecosystem.
Founder and investor introductions
Connections into a network already oriented around demand-driven products.
Category opportunity discovery
Unmet-demand intelligence pointed at the question of which company should exist next.
A commerce platform sells software to companies that already exist. Infrastructure makes companies possible that a catalogue could never have supported.
Everything above is the direction. This is the present.
Available now
- Catalogue Blind Spot and Premature No analysis
- Structured Opportunity generation
- Missing-information and next-question logic
- Draft Capability Map and Constraint Record structures
- Human review and Decision Record workflow
- Opportunity Ledger structure
- The complimentary Enquiry Audit, running on this site
- Request Readiness Sprint and Pilot Decision Brief
Next hypothesis and Long-term direction
- Automated pricing, rendering or production instructions
- Merchant agents and autonomous storefront management
- The Automated Improvement Audit as a product
- Supplier and production marketplaces
- Cross-platform fulfilment
- A customer-facing entry point or network checkout
- AI commerce APIs and agentic purchasing
- Ecosystem benchmarks and shared intelligence
- Venture creation, financing or investor-network services
Specify has no verified customer results and makes no claim about revenue, conversion, time or return on investment. Every proposal and product demonstration states what is implemented, what is illustrative and what still requires validation.
Start with evidence
Start with one request the catalogue could not answer.
The vision begins with a practical question inside a real business: when the catalogue reaches its limit, can the business still reach an informed, responsible outcome?
Everything else on this page is what becomes possible once that question has a reliable answer.