This page collects every project-specific term, abbreviation, and concept used anywhere in the DomiDo documentation, so newcomers do not need a decoder ring to read any other page. The glossary itself is a true enumeration — an alphabetical list of terms with definitions and cross-links into the relevant deep pages. Use the section letters below to jump to a term, or read through end to end on a first pass to absorb the vocabulary of the project. Terms that have their own dedicated documentation are linked through to the canonical page. DomiDo is an AI-assisted modular outdoor construction platform developed by Avvyland Limited (United Kingdom); the company sells universal blocks and fasteners only, and every construction shown on the platform is a user-generated design.
Acceptance criteria. The pass/fail conditions a feature must meet for a customer or stakeholder to call it complete. The full set is maintained in the Acceptance criteria page.
Atlas Vector Search. MongoDB Atlas's vector index feature, used to find designs similar to one another by embedding similarity. Underpins the Phase C designer uniqueness protection.
Audit log. An append-only record of business events relevant to compliance, security, or fraud investigation. The catalogue of events that must be logged lives in Audit and logging requirements.
Avvyland. The interactive 3D environment that sits alongside DomiDo in the Avvyland Limited product family. Avvyland is a separate product, with its own wiki section under the avvyland/ namespace. DomiDo objects can be placed inside Avvyland; Avvyland objects can serve as prototypes for DomiDo manufacturing.
Avvyland Limited. The UK company that develops both DomiDo and Avvyland. All commercial activity flows through this entity.
Block. The atomic physical unit of the DomiDo product. Universal interlocking blocks (and matching fasteners) are manufactured at scale; every kit is composed from the same shared block library, plus a small set of finish parts.
Build companion. The mobile-friendly assembly assistant that walks a customer block-by-block through putting their kit together. Offline-capable once loaded, with rotating 3D previews and a "stuck on this block" troubleshooting path.
Business rule. A formal statement of policy that the system must enforce — for example: "a kit can only be cleared to build once interest exceeds the manufacturing threshold". Catalogued in Business rules.
Cleared to build. The state a kit enters when its manufacturing batch is queued. At this moment the customer's card is charged. Until then no money has moved, even though the card was verified at pre-order.
Commitment. A non-binding interest record placed by a customer during Phase A. Commitments aggregate to a demand signal that informs whether and when a kit reaches its manufacturing threshold.
Companion. Short for build companion.
Conformity. The body of regulations a product must satisfy to be sold in a given market. For DomiDo this includes UKCA in Great Britain, CE in the EU, and product-specific safety standards. See Product safety.
Designer. A user who publishes their own kit designs on the platform. Designers earn royalties when others pre-order their designs and can apply uniqueness protection to their work.
Designer marketplace. The Phase C feature set that lets designers publish, monetise, and protect their own designs. Underpinned by the Business model.
Domain model. The set of canonical entities the system reasons about (designs, kits, orders, customers, designers, blocks, etc.) and how they relate. See Domain and data architecture.
Embedding. A numerical vector representation of a design, used to compare designs for similarity. Drives uniqueness protection: designs that fall within a defined distance of an already-published design are blocked from publication for a defined time window.
Engineering requirements. The non-business-facing requirements a development team needs to know: test coverage, CI/CD posture, code quality gates, technology stack, and so on. See Engineering requirements.
Fastener. The small interlocking part that joins two blocks. Manufactured at scale alongside blocks.
Functional requirement. A statement of what the system must do (as opposed to how well). See Functional requirements.
GDPR. General Data Protection Regulation. The EU privacy regime that the DomiDo platform must comply with for any EU-based customer. See Data and privacy.
Information architecture. The structure of the app's content — what pages exist, how they are grouped, what users can do on each. See Information architecture.
Interest. Non-binding signal of intent placed by a customer in Phase A. See Commitment.
Interface requirements. The contracts the system exposes to external callers (REST endpoints, webhooks, SDKs). See Interface requirements.
Jobs-to-be-done (JTBD). A framing of customer needs in terms of the job they want done, rather than the demographic they fit into. Used in Personas and jobs.
KYC. Know Your Customer. The identity-verification process applied to designers receiving royalty payouts (and, where required, to other roles by AML or marketplace regulation).
Kit. The boxed set of blocks, fasteners, finish parts, and instructions that ships to a customer's door. A kit is a recipe — a specific list of blocks in a specific arrangement; the blocks themselves are universal.
Manufacturing threshold. The number of pre-orders required for a kit to enter the manufacturing queue. Below the threshold, the kit waits; at or above it, the batch is queued.
Mock. An interactive prototype of the customer-facing app. The current mock is the source of truth for visual design; see Web mock requirements.
Non-functional requirement. A statement of how well the system must perform (latency, availability, scalability, security posture). See Non-functional requirements.
Observability. The combined surface of metrics, logs, and traces that the operations team uses to understand and diagnose the running system. See Observability.
Patent. A government-issued exclusivity right. The DomiDo block geometry is the subject of a patent application; see Intellectual property.
Payment architecture. The full design of the platform's commerce flow — how cards are verified at pre-order, how funds are captured at "cleared to build", how designer payouts are processed. See Payment architecture.
Phase A / Phase A.5 / Phase B / Phase C. The platform's four delivery phases. Phase A is browse and non-binding interest. Phase A.5 is pre-orders with verified cards. Phase B is manufacturing and shipping. Phase C is the full designer marketplace.
Preorder. A Phase A.5 commitment with a verified payment card. The card is not charged at pre-order; it is charged when the manufacturing batch is cleared to build.
Project Concept Note (PCN). The original founding document that introduced DomiDo's market vision. Its substance is captured in the Overview section.
Requirements Traceability Matrix (RTM). A cross-reference between business needs, software requirements, design decisions, and test cases. See Traceability.
Royalty. The share of a kit's price paid to the designer who created its design. The percentage is set per design within bounds defined by the marketplace policy.
SetupIntent. A Stripe concept: a record of intent to charge a card later, used to authorise the card at pre-order without taking funds. The full design is in Payment architecture.
SKU. Stock Keeping Unit. A single distinct manufactured part (one block type, one fastener type, one finish part).
Software Requirements Specification (SRS). The umbrella requirements document that introduces the whole requirements set. See Software overview.
Threshold. See manufacturing threshold.
Third-party logistics partner (3PL). The external company that warehouses, picks, packs, and ships kits on behalf of DomiDo. See Manufacturing and fulfilment.
UKCA. The UK Conformity Assessed marking. Required for placing a product on the Great Britain market. See Product safety.
Uniqueness protection. A designer-facing feature in Phase C that prevents designs that are too similar to an already-published one (within a distance threshold) from being published in the same time window. Implemented via embedding similarity.
Use case. A specific way a user (customer, designer, ops admin) accomplishes a goal with the platform. See Use cases and user journeys.
User Role and Permission Matrix. The catalogue of which roles can do which actions. See User roles.
Voxelisation. The conversion of a 3D model into a regular grid of small cubes, used as the intermediate representation before fitting a model to DomiDo's block library.
Web mock. See Mock.