Capture the intended experience
Define functions, visitor groups, language and accessibility requirements, operating conditions and project constraints.
Develop the requirements ↗PROCUREMENT & RFP TEAMS
Specify the result.
Ask for the evidence.
Mad helps procurement teams translate an owner’s requirements into a clear technology brief, evaluation criteria and acceptance tests. The specification should explain what the experience must do, what the operator will need and what a proposal must demonstrate.
WORKING WITH MAD
A useful specification makes comparisons possible.
Compare the complete offer
Evaluate hardware, software rights, documentation, maintenance, refresh assumptions and the work required to add later functions.
Read the lifecycle questions ↗Define acceptance
Ask how each requirement will be tested, who will witness it and what evidence becomes part of the handover.
Commissioning and handover ↗PROJECTS AND REFERENCES
Start with a clear requirement.
A defined multilingual requirement
At the Albert Robles Center, the requirement is a complete center-wide change between English and Spanish, including all interpretive text.
See the requirement in use ↗Current architecture reference
WorldModel.global is the current authority for WorldModel: ten architectural layers and eleven cross-cutting policies.
Explore WorldModel at Mad ↗TECHNICAL DETAILMake the technical requirements assessable.
Open the engineering detailClose this sectionLook for the red circuit symbol for engineering detail.
| Decision | What to define |
|---|---|
| Compute and interfaces | Document the architecture, hardware dependencies, supported interfaces and access needed for maintenance. |
| Language and accessibility | State the required content variants, delivery routes and tests with the intended audience. A generic compliance label does not specify the experience. |
| AI and personalization | Define permitted data, retention, authority, source control, fallback behavior, local or external services and audit evidence. |
| Lifecycle and rights | Separate component sourcing from software licenses, access to configuration, support obligations and planned replacement assumptions. |
| Delivery maturity | Distinguish functions already implemented, working demonstrations, work to be developed and optional roadmap items. |
For AI-related requirements, use the current architecture at WorldModel.global. Mad’s role as advisor, reviewer or bidder is established for the particular procurement, with any relevant conflict and evaluation arrangements agreed with the client.
EXISTING INSTALLATIONS
A staged path to new capability.
Separate retained peripherals, the QuickSilver® retrofit, and proposed AV++® options in the procurement scope. The retrofit replaces legacy playback and control first. Each subsequent capability needs specified content, interfaces, capacity, engineering and acceptance criteria.
CAPABILITY AND EVIDENCE
A clear scope for your project.
Specify the required outcomes alongside the hardware, software, interfaces and services to be delivered. Identify development tasks and acceptance criteria explicitly, with evidence appropriate to each function, so that published architecture is not mistaken for an installed capability.
LET’S BUILD WHAT COMES NEXT
What does your next decision need?
Tell us the project stage, the people involved and the question you are trying to resolve. We can agree a useful next step.
Start a conversation