Buildings begin as ideas. The architect draws first, satisfying the customer's brief and the planning regulations of the moment. The drawings include a foundation type and a stability calculation, and on that basis the permit is granted. Only afterwards is the soil actually measured. If the measurement contradicts what was already permitted, the foundation is redesigned and the cost of the adjustment is passed downstream - usually to the owner. Construction firms are then handed the resulting documents and discover what they will need to procure. Manufacturers, hoping their products end up in the spec, spend continuously on awareness so that they will be remembered when the moment arrives. The whole industry runs on a sequence in which the answer is sketched before the question has been fully asked, and everyone downstream is asked to make the answer fit, or to absorb the cost of fitting it.
This is not how durable things would be designed to be made, if the sequence were drawn up from scratch today. It is how cars would be built if you decided on the silhouette before working out where the wheels go. It functions because the people inside it are skilled and patient enough to absorb its incoherence on behalf of everyone downstream. But it produces buildings that are more expensive than they need to be, slower to deliver than they should be, less aligned with their context than they could be, and almost wholly opaque about what they cost the planet to build.
The pressure on this arrangement is no longer theoretical. Roughly 1.1 billion people now live in slums or informal settlements, the bulk of them in Asia and Africa. In the fastest-growing cities, around 60 percent of urban dwellings are built outside formal procurement and approval channels altogether. The formal construction industry, in much of the world, is not actually the thing that builds most of what gets built. It is too expensive for the demand, too slow for the urbanisation curve, and too disconnected from local context to produce buildings that fit. The informal sector fills the gap. The result? Informal sprawl, at great cost to current and future generations in terms of safety, health, and sustainability. The question of how cities accommodate the next several billion urban residents is, any way you look at it, the largest construction question humanity has ever faced - and the formal industry, on its current trajectory, cannot answer it.
The pressure is not only demographic. Capital is already failing to land. Across every major housing market, the same pattern holds: trillions are allocated, approved, and ready to deploy, and the sector cannot absorb them. Of the European Union's €378 billion cohesion envelope for 2021 to 2027, only 11 percent had been spent by mid-2025; the European Commission attributes the gap to administrative capacity constraints and regulatory conditions Member States cannot process fast enough. In England and Wales, more than £9 billion of developer contributions sits unused in local authority accounts, billions earmarked specifically for affordable housing and schools. This is not a funding crisis. It is a conditions crisis. Regulation, meanwhile, is tightening - carbon disclosure and material-provenance rules are moving from voluntary to mandatory across Europe and increasingly elsewhere - and climate is narrowing what is buildable, with rising temperatures and shifting weather extremes changing the engineering envelope of structurally sensible buildings. The incentive structure that held the old arrangement together is dissolving. The question is no longer whether building will industrialise upstream of design, but who will build the layer in which it does so, and on what terms.
FutureCraft exists to build that layer. We are building it as a single continuous pipeline that takes the context of a place, resolves the structural and material complexity of a building it needs, and produces outputs that anyone - architect, manufacturer, fabricator, construction firm, permitting authority - can act on directly. We call it DAIdalus, the resolver stack: a Context Resolver that ingests live data from cities and the world's regulatory and climatic context; a Complexity Resolver that draws on a commons of attributed design patterns and the product data of participating manufacturers to produce the minimal viable building for a given need; a Perspicuity Resolver that translates the result into fabrication-ready, BIM-interoperable, carbon-verified outputs. The stack is not equally mature in every layer: some components are operational, some are entering pilot use, some depend on participating cities, manufacturers, and certification partners coming on board. The data the platform draws on is open. The commons of design patterns is open. The configurator that accesses the resolution is open. The output the platform produces is open. What we are building is a way of closing a loop that the construction industry has been failing to close for fifty years - the loop between the context where a building will stand and the design that decides what it will be. What follows is a brief account of how the stack works, why we think it has to work this way, and where the work goes next.
I. Context
A building is not, in the first instance, an aesthetic proposition. It is a response to a specific human need - thirty units of housing here, a primary school for six hundred children there, a clinic that serves a particular catchment - placed into a specific physical and regulatory context. That context is not generic. It has a soil profile. It has a climate envelope, with prevailing winds and seasonal extremes that determine thermal load. It has a code regime that establishes what is permitted, what is mandatory, and what requires special approval. It has access patterns, water and energy infrastructure, available materials, and skilled labour within reach. It has neighbours, mobility patterns, and acoustic conditions. The number of structurally and environmentally sensible answers to a given need-in-context is, when all the relevant variables are computed against each other, narrow. It has not looked narrow until recently because no individual or office has been able to hold all the variables in mind simultaneously. The field has therefore proceeded by approximation and by office default - skilled approximation, often, but approximation nonetheless. The narrowness was always there; the means to see it have only just arrived. What follows is a sketch of what becomes possible when the sequence is reordered: when context is read first, and design follows from it rather than against it.
Consider a small housing block on a parcel near a city centre. The subsoil is suitable for direct anchorage: the strata profile, bearing capacity, and water table together favour a solution that does not require excavation. The right foundation here is, by a wide margin, not a poured concrete slab. It is a system of helical screw-in piles. Screws preserve soil structure because nothing has to be excavated; they install in hours rather than days; they cost less; and the embodied carbon is a fraction of poured concrete's. The number and placement of screws follows from pre-validated structural calculation against the load path of the building above. The foundation type is determined by the soil, the cost envelope, the carbon constraint, and the local climate. The building attaches to the screws.
Now introduce a separate factor: mobility data shows a tram line two streets over generates ground-borne vibration in a frequency band that, untreated, would propagate through the structure into the upper-floor units. This is not a foundation question; the foundation is correct. It is a separate question of how to decouple the building from a known external vibration source. The answer is structural base isolation - elastic bearings installed at the interface between the screw foundation and the building structure that absorb and damp the vibration before it transmits upward. The bearing specification follows from the vibration frequency, the load profile, and the deflection tolerance. Building base isolation is a mature category with multiple manufacturers; the platform resolves which products fit the spec, in the geography of the project, with the certifications and verified performance data the configuration requires.
From there, decisions cascade. The floor system follows from the foundation and the typology. The envelope follows from the climate envelope and the code regime. The acoustic detail follows from the typology, the neighbours, and the residual vibration profile after base isolation has done its work. Active systems - heating, ventilation, hot water - follow from the envelope's thermal performance and the local energy infrastructure. Materials, certifications, lead times, and embodied carbon are resolved at each stage against the available supply in the project's market. An architect arriving at this site with a different starting idea - a poured floating slab, perhaps, because it is what the office defaults to - may still be right, but the burden of proof shifts. The alternative must now show why it performs better against the resolved constraints, rather than rest on office default, habit, or authorship. The architecture that matters - the spatial intelligence, the relationship to the street, the way light enters the units, the room rhythms, the materials at the human scale - sits comfortably and entirely above this layer of resolution. It is not threatened by it. It is freed by it.
Architecture as authorship comes after architecture as resolution. The constraints do the structural work, and the architect does the architectural work. Both are essential. They have been collapsed into the wrong order for a long time.
This is what we mean by context. It is not a setting. It is the set of conditions, made legible and computable, from which a coherent answer to a need can be derived. The first layer of the DAIdalus stack does this work: the Context Resolver. It runs on ETSI NGSI-LD, the European linked-data standard for smart-city information, and it speaks to a network of context brokers working in tandem with the urban data platforms of cities and regions of the world. A participating city validates its regulatory data space to increase accuracy and provenance, and sovereignly governs all context data, in its native format, as part of its overall city data strategy. Building codes, climate envelopes, carbon budgets, zoning constraints, demand signals, site information - all become queryable elements of a single linked-data context object that any subsequent step can act on. The network of cities engaged in this work - those that have signed or committed to the Declaration to End the Stone Age - numbers roughly five thousand municipalities across eighteen territories, a combined population of around 585 million, deliberately concentrated in the urbanising regions of Asia and Europe where the building question is most urgent.
II. Complexity
A building is also, of course, a system. Once context has done its work and the structural and material question has narrowed to a tractable space, what remains is the resolution of that space against the body of design knowledge humanity has accumulated. There are good ways to attach a screw foundation to a cross-laminated timber floor system, and there are mediocre ways. There are joint details that handle vibration and there are joint details that fail. There are envelope assemblies that meet a Northern European code regime cleanly, and there are envelope assemblies that meet it expensively. The space of good answers is not infinite. It is, however, large enough that no single architectural office can hold it in mind, and changing fast enough that no static reference work can keep up.
What it requires is a computable repository of attributed design patterns - thousands of solutions, each authored, each documented, each verifiable, each linked to the contexts in which it is fit. We call this commons the Digital Housing Commons, and like the city data spaces it is free and open: contributable by architects, schools, students, cities, and engineers, attributed to its authors, and improvable by anyone with the standing and skill to do so. The Digital Housing Commons begins with a seed collection of design patterns across eleven of the thirteen typologies of occupiable structure the platform plans to cover - medical and sports infrastructure are the two that remain - drawn from more than four hundred and fifty realised projects across multiple continents. The intent is to grow this, in collaboration with the field, until the commons holds, for most recurring needs-in-context, an answer already authored. The second layer of the DAIdalus stack draws on it: the Complexity Resolver. It takes the context object produced by the first layer, the relevant patterns from the Digital Housing Commons, and the product data of participating manufacturers, and runs them through COMPAS, the open-source computational framework that is the working language of advanced AEC research. The Resolver runs geometry, structural, fabrication, and rule-based analysis in a single parametric environment. It identifies conflicts, scores pathways, and outputs a resolved complexity graph: the minimal viable configuration that satisfies all constraints. Today this resolution is reached through two access surfaces - the FutureCraft configurator itself and a chat interface - both free and open. The configurator is also a point of control: an architect, a city, or any other user can adjust the configuration to their liking, and the configurator shows whether the result remains valid, becomes conditional, or falls out of admissibility as they do. Where the room for adjustment is widest is in the elements that do not bear on the building's carbon performance - cladding, finishes, fittings - and where it narrows is in the structural elements whose sequestration is the basis of how the platform is paid.
The configurator works against regulatory context today, since regulation is the imperative context category: you do not get to satisfy it optionally. The other context layers - climatic, material, carbon, demand, site - come into the configurator surface as the pilots mature. Through whichever surface, the underlying work is the same. Soil and program constrain what the structural system can be. Climate and use constrain the envelope. Budget and code constrain everything. Energy and carbon performance are parameters in the same graph, not consequences downstream of it. None of these decisions arrives in a single direction; each is a constraint on the others, not a determinant of the next. The Resolver runs against this graph of constraints in real time, against the regulatory and material conditions of the jurisdictions in the FutureCraft network as those data spaces come online.
This is what we mean by complexity. Not complication - which is when something is harder than it needs to be - but the genuine, irreducible interdependence of decisions in a system that has to perform at multiple scales at once. Resolving complexity well is what makes a building work. Pretending it can be resolved later, after the design is drawn, is what makes construction expensive.
The reason for resolving it at platform scale is the loop. The platform is free to use, by anyone, anywhere. Each use produces data the next use benefits from. Each project that resolves cleanly improves the patterns the next project draws on. Each carbon-verified building tightens the verification framework for the one after. The scale of the system is not the point; the loop closing inside the scale is. Over time, the measurable outputs of the work - sequestered carbon, healthy affordable housing, the gap between what cities need and what gets built - move in the right direction, and keep moving.
III. Perspicuity
The harder question - and the one that determines whether any of this matters in the world - is what it means for a platform to back a configuration. Anyone can produce a configuration. Many systems do. The question is whether the configuration, once produced, can be trusted as the right answer. Can a city stake permitting decisions on it. Can a manufacturer stake commercial commitments on it. Can a construction firm stake procurement on it. Can a community stake its housing on it. In a domain where the cost of being wrong is buildings that fail, this is not a small question.
The third layer of the DAIdalus stack answers it: the Perspicuity Resolver. The word perspicuity is unusual on purpose. It means clearness, the quality of being seen-through, the absence of hidden complication. The Resolver materialises the resolved complexity graph through BHoM, the open-source object model that is the working language of structural and building engineering. From there it exports the resolution into the working environments of everyone downstream of design: native BIM files for the engineers and the permitting authorities, fabrication-ready geometry and machine instructions for the factories, bills of material for procurement, and carbon and compliance artefacts that travel with the building rather than being assembled afterwards. A fabricator receiving an output from the platform receives the same geometry the structural calculation ran against. A city receiving a permit application receives the same constraint set the resolver satisfied. A manufacturer receiving a spec receives the same product references that determined the configuration. The output is not a description of a building that someone will then have to translate into something a machine can cut or a regulator can grant; it is already in the form the next person down the line works in.
What perspicuity adds to this is a discipline about when the output is fit to leave the platform at all. Every configuration the platform backs carries a state. It may be valid - the context, calculation, product, carbon, and compliance evidence is present and current. It may be conditional - usable only with named assumptions or further verification. It may be expired - once valid, but overtaken by changed regulation, certification, site data, or time. It may be non-admissible - missing what would be required to stand behind a binding decision. The platform only releases configurations whose state supports the decision they are entering. That is not a marketing claim; it is the rule the stack enforces at the point of release. A perspicuous configuration is one whose every decision can be traced - to a regulatory clause, to a climatic input, to a structural calculation, to an attributed design pattern, to a material specification with a verified Environmental Product Declaration - and whose internal logic is open to inspection by anyone with the standing to inspect it. Important parts of the above are fruits of exchanges with my friend Jan Bunge, who has been writing excellent pieces on the wider institutional question of when machine-produced outputs may legitimately count.
The output of the Perspicuity Resolver is downloadable, inspectable, and interoperable. The value is not file ownership. The value is the validated resolution that produced the file. Anyone using the platform is free to deviate from the configuration we produce - the design is open, the file is downloadable, the pattern library is a commons. But because we only back what we have validated, deviating means commissioning your own architectural and structural validation for the alternative. Most users will find that the configuration we produce is, in fact, the better answer in their context, and that the cost of independent validation is not worth bearing. The lever that holds the spec in place is not lock-in. It is the asymmetry between trusting a resolution that has already been validated and rebuilding the validation from scratch.
This validation discipline rests on a charter we publish openly. It is called the HOST://protocol, and it stands for the four commitments by which the platform conducts itself: Honesty, Openness, Safety, Trust. Honesty means we do not say a building contains what it does not contain - the gap between specification and reality is to be zero. Openness means the platform's standards, methods, and design commons are public, contributable, and inspectable. Safety means we engineer for the consequences of failure rather than the appearance of competence. Trust means we treat data sovereignty, attribution, and democratic accountability as operational requirements rather than as language to be deployed at will. Carbon performance is one of the things HOST governs: we measure it from configurator data, logistics, and satellite verification, and we represent it on a public ledger. The ledger is a volume measure of physical impact, expressed in atoms-and-energy terms. It is also the unit of account through which manufacturers pay to have verified product data calibrated into the resolver stack. When DAIdalus resolves a configuration that calls for a product category they serve, their products can be evaluated against actual performance, certification, carbon, logistics, and availability data. They are not buying placement; they are buying the right to be assessed properly inside real demand resolution. The same ledger is the basis on which the income from this is distributed - to the architects and engineers whose patterns enter the design commons, to the cities and data providers whose context the resolution runs against, to the channel and certification partners through whom verified projects reach the world, and to the platform that operates the loop.
One thing the HOST ledger is not is a substitute for regulated carbon-credit certification. The carbon FutureCraft counts is the physical substitution the platform actually causes - wood in place of cement, biological materials in place of mineral ones, sequestration measured against conservative baselines. That measurement is what keeps the unit of account honest, and it is the basis on which manufacturers pay. Where projects also generate certified carbon value under existing regulated regimes, that certification is handled through recognised certification partners and accounted for through the same ledger. What the platform does not do is propose itself as an alternative carbon-credit regime, and it does not participate in the voluntary carbon market in its current form. Whether and how certified carbon value is later valorised, by whom, and on what terms, is a question the platform expects to be in a position to answer responsibly at scale; until then, the discipline is to count the physical substitution, account for it transparently, and let the rest follow.
IV. The economy that arises
Once context, complexity, and perspicuity are resolved, the building economy starts to look different downstream. Materials are resolved at the moment the spec is written, not negotiated in the weeks after tender. Compliance is built into the configuration, not retrofitted by consultants paid to certify what was designed without them. Carbon performance is a parameter that determined a decision, not a report that explains one. Construction firms know what they will be procuring before they bid, and can plan logistics accordingly. Manufacturers are present in the resolution layer at the moment a building is being conceived, where their products are named in the design metadata if they fit the context - rather than spending their commercial energy on awareness campaigns hoping to be remembered later. The architect, freed from the structural and material questions that constraints answer, gets to do what architects ought to do: shape the human experience of the building.
None of this requires anyone to abandon what they were doing. Architects who deviate are free to deviate. Manufacturers who do not participate will continue to end up in buildings sometimes, through the marketing-and-relationship paths the industry has always run on, which will continue to carry a portion of demand. Construction firms who prefer to work the old way can. The platform is open and non-coercive. But the economics shift, quietly and decisively. Manufacturers who participate are paying a fraction of their current customer-acquisition cost for direct presence in actual demand resolution, scaling with realised projects rather than with marketing spend. Cities that participate have access to a configurator that produces permit-ready, carbon-disciplined, regulation-aligned building specifications at a marginal cost approaching zero. Once enough participants are inside the resolution layer, the cost of staying outside it - paying the prices and overhead of awareness-driven presence in a market increasingly resolved by other means - becomes structural rather than tactical.
The economic frame underneath this has a name. FutureCraft calls it post-competitive value engineering - the proposition that some problems are too vast and too consequential for the competitive model to solve, and that the route to solving them runs through cooperation around a shared infrastructure rather than competition over proprietary capture of it. Pre-competitive research consortia have been doing some version of this for decades in nanotechnology, semiconductors, and life sciences: industries that recognised they could not build the foundations alone, and pooled the foundational work so that competition could happen at the application layer above it. Construction has never had a foundation layer of this kind. The Digital Housing Commons, the resolver stack, the carbon verification methodology, the city data spaces - these are foundation. They belong below the line of competition, not above it. The values of any platform are visible in the way it deals with money, and the way this one deals with money is determined by where it draws that line.
Cities do not pay for basic participation in the platform or for use of the configurator; specialist integration, data validation, local implementation, or programme support may be funded separately where required. Architects, engineers, schools, and students do not pay to contribute to the commons; their work is attributed and remains theirs. Citizens and end users do not pay for the configurator or its outputs. The participants who pay are the manufacturers whose products enter resolved configurations - and they pay for something they currently spend a multiple of on awareness and relationship: direct presence in actual demand resolution, scaling with realised projects rather than with marketing. What they pay is denominated in the carbon their products' use sequesters or avoids, measured against the platform's verification methodology and represented on the HOST ledger. Carbon is the unit of account, not the unit of payment: money moves in money, but the price is set by physical impact. The income that arises is distributed across the system. A majority share sustains the foundation work that makes the rest possible at all: the engagement of the city network, the development and care of the Digital Housing Commons, the resolver stack, the carbon verification methodology, and the platform's continued openness. A defined share flows to the data providers, certifiers, and channel partners through whom verified projects reach the world.
A defined share also flows to the architects and engineers whose patterns enter the commons, attributed to the contributions a given configuration draws on. Today an architect designs once and is paid once: the building lives or dies in the jurisdiction it was drawn for, and the intelligence of the design does not travel. What the resolvers make possible - once their ingest is fully automated and the regulatory context of the network is computable end to end - is something the field has not previously had: an export engine for architectural design. A pattern contributed to the commons under a Creative Commons licence can be morphed by the resolvers into compliant configurations in any jurisdiction in the network, against that jurisdiction's codes, climate, materials, and site conditions. Every configuration that draws on a pattern is registered on the HOST ledger, and the pattern's authors earn their share. The pattern stops being a one-shot deliverable and becomes a productive asset. It is open source with a business model. FutureCraft therefore makes money without enclosing the commons: manufacturers fund their participation in the resolution stack, the ledger accounts for the physical impact that determines price, and the resulting income sustains the shared infrastructure and rewards the contributors whose work makes the resolution possible.
V. Where this goes
Today, what we have described is configured demand: buildings that are conceived from need and context, resolved through perspicuity, and procured against a verified spec. This is already a substantial shift in how construction works. It is not the destination.
Next, we open the act of conception itself to a wider community. The Hackable Architecture Catalyst and Competition - HACC - is the next stage of this work. It invites architects, schools, students, and cities into the design commons as authors, contributors, and improvers of the patterns the platform resolves against. The competition runs through 2027. The commons it builds outlives any single building. Hackable here means what hackable has always meant in the open-source tradition: capable of being read, understood, modified, and improved by anyone with the standing and skill to do so. It is the opposite of black-boxed software, and it is the opposite of the proprietary design knowledge that has fragmented across firms for the last half-century without ever becoming a commons.
After hackable architecture comes emergent architecture. Once need-in-context is computable, once complexity is resolvable, once perspicuity is enforced, once the design commons is wide and deep enough, and once the prefab, logistics, and assembly pipelines downstream of resolution are autonomous - which is a matter of years, not decades - buildings will arise the way more obvious things already do. The need is identified and capitalised. The context is read. The configuration resolves. The materials are produced. The components are fabricated. The site is prepared. The building is assembled. The whole pipeline executes against a perspicuous spec, and a building exists where one did not before. In the mature version of this system, need plus capital no longer disappears into years of unresolved coordination. It enters a resolution pipeline whose every stage has been validated upstream. This is not science fiction. It is the natural endpoint of work that is already in progress, in pieces, in many places, including this one.
The point is not that emergent architecture is imminent. The point is that getting the resolution layers right at this moment in time is the precondition for it. Manufacturers, engineers, cities, and architects who are present in the resolution layer in 2026 are present in the autonomous pipeline that follows. Those who wait to see whether it happens will find that it happened around them.
VI. What FutureCraft is
FutureCraft is the work of building this resolution layer. It is open-source by design, governed by a published ethics charter, free for cities to participate in, and structured to keep the commons of design knowledge in the commons - attributed, inspectable, and improvable by anyone, forever. We are not the future of construction. The future of construction is arriving with or without us, driven by demographics, climate, regulation, and the patient work of many hands across many places. What we are building is the layer in which that future can land cleanly: where buildings arise from need, where context does the structural work, where complexity resolves through validated patterns, where perspicuity holds the resolution accountable, and where the economics reward verified performance rather than purchased visibility.
The first manufacturers, engineers, cities, and architects to participate are shaping how this layer settles.
There is still time. There is always at least some time. A day with no more time is yesterday. A day with all time left is tomorrow. There is always at least some time for us today to build a new tomorrow. But there is, in fact, only this time.