This section is the requirements library for DomiDo — the AI-assisted modular outdoor cladding and construction marketplace operated by Avvyland Limited. Each page in this section is a comprehensive catalogue written for someone who needs to know not just what a rule is but why it exists and how it interacts with the rest of the platform. Read this first if you are joining the project, evaluating a feature, or trying to understand why a given behaviour is the way it is. The pages are organised so that the high-level "what does the software do" answer lives in the software overview, the rules that govern each domain live in their own catalogues, and the verification path — acceptance criteria and traceability — closes the loop back to product evidence.
DomiDo turns a sketch, a photograph, or a 3D model into a buildable kit of universal interlocking blocks plus fasteners and instructions. The platform is rolling out in phases. Phase A is the public catalogue, design studio, and non-binding interest captured for future kits. Phase A.5 adds pre-orders with card verification — zero-amount Stripe SetupIntent authorisations that store the payment method without charging it until a manufacturing slot opens. Phase B activates manufacturing and shipping of kits across the United Kingdom and the European Union with captured payment, fulfilment, returns, and designer payout release. Phase C is the expansion phase that opens further marketplace mechanics once Phase B is stable.
The master-level documents describe what the software must do, how well it must do it, and how its parts fit together. The software overview is the umbrella specification that frames every other requirement and ties them to the platform's phased rollout. The functional requirements enumerate every behaviour the system must perform, grouped by domain (authentication, catalogue, design, checkout, fulfilment, marketplace). The non-functional requirements cover performance, availability, scalability, observability, and the other quality attributes. The interface requirements define the REST API shapes, webhook contracts, file-format support, and third-party integration points. The data requirements describe the entity model, retention rules, classification levels, residency, and the lifecycle of each record.
The domain catalogues lift the rules and constraints that the wider product, legal, and operations teams must follow. The user roles and permissions page documents who can do what across customer, designer, support, operator, admin, and finance roles. The business rules page records the policy logic the platform encodes: pricing, returns, tax handling, marketplace payouts, and risk controls. The acceptance criteria page lists the conditions every feature must satisfy before it ships, and the traceability page is the map that links each requirement back to the product evidence it serves and forward to the test that verifies it.
The operational pages describe the controls that keep the platform safe and the engineering practices that keep it running. The security page covers identity, authentication, authorisation, encryption, secret management, vulnerability handling, and incident response. The audit and logging page defines what events are captured, how long they are retained, and how they are reviewed. The engineering requirements page sets the coding standards, repository layout, build and release pipelines, environments, and tooling.
Two specialised documents close out the section. The web app mock requirements page captures the rules for the public-facing mock app used for early user testing and stakeholder demos, and records the overrides where mock copy conflicts with product decisions. The payment architecture analysis page is the deep dive into payment flows: Stripe integration, Strong Customer Authentication, refunds, marketplace splits, tax handling, and the full set of state-machine diagrams.