Inspiration
The theme “Blocks that make up the world” made us think about communities as systems made from many different kinds of blocks.
A community already has people, skills, languages, time, accessible spaces, equipment, organisations and local knowledge. The problem is that these pieces are often scattered, and it is hard to know whether they can actually be combined into something useful.
Most platforms begin with an opportunity or project that already exists and then try to match people into it.
We wanted to reverse that question:
Given everything a community already has, what can it actually build together?
And if something cannot be built yet:
What is the smallest change that would make it possible?
That became ASSEMBLE, a compiler for collective capability.
What it does
ASSEMBLE represents a community as a structured system of:
- people and organisations
- capabilities and languages
- availability and contribution limits
- accessible spaces
- shared resources and equipment
- initiative requirements
- possible capability-building interventions
A coordinator can inspect these blocks through the Community workspace, then select an Initiative they want to test.
ASSEMBLE compiles the current community state into a real constraint optimisation problem using Google OR-Tools CP-SAT.
Instead of simply saying a project “looks possible,” ASSEMBLE checks whether all requirements can be satisfied simultaneously, including the right people, skills, languages, availability, venue, accessibility, equipment and time.
If an initiative is feasible, ASSEMBLE returns a complete assignment that proves it.
If it is infeasible, ASSEMBLE does not stop at “no.” It performs bounded relax-and-resolve analysis to identify the actual blocker.
For example, our Multilingual Digital Help Clinic requires three digital helpers, but initially only one person qualifies.
ASSEMBLE identifies:
Required: 3
Available: 1
Shortfall: 2
It can then search the disclosed intervention catalogue for the lowest-cost sufficient intervention.
This distinction matters.
Borrowing more laptops may be cheaper, but laptops cannot solve a human capability shortage. Training two existing community members costs slightly more, but actually changes the system enough to make the Clinic feasible.
ASSEMBLE therefore reasons about capability transformation, not just resource matching.
Once an intervention is applied, ASSEMBLE creates a new immutable community state and requires a fresh solve before treating the new state as verified.
A verified result can then become an executable Project, where the operational team, venue, schedule, resources, accessibility, languages and readiness are derived from solver evidence rather than manually asserted.
ASSEMBLE also includes a Resilience Lab with three advanced tools:
- Structural Stress Test — removes one critical block at a time and re-solves the plan
- Minimum-Disruption Recovery — proves the minimum number of assignment changes required after something breaks
- Capability Frontier — compares which single investment increases the community’s future capability most
How we built it
We built ASSEMBLE as a layered reasoning system rather than a normal CRUD application.
Community constraint compiler
The backend converts human-readable community data into CP-SAT decision variables and constraints.
Conceptually:
[ x_{p,r}=1 ]
means person (p) is assigned to role (r).
The model enforces constraints around:
- role coverage
- skills and capabilities
- languages
- availability
- venue capacity
- accessibility features
- resource quantity
- contribution limits
Solver witnesses and independent verification
A solver result is not treated as a simple boolean.
A feasible result includes a full witness describing the people, roles, venue, time and resources that make the initiative possible.
That witness is then independently replayed against the domain model before ASSEMBLE accepts it as proof.
The architecture is therefore:
[ \text{Solve} \rightarrow \text{Produce Evidence} \rightarrow \text{Verify Evidence} ]
rather than simply:
[ \text{Solve} \rightarrow \text{Display Success} ]
Explainable infeasibility
When an initiative is impossible, ASSEMBLE performs bounded relax-and-resolve checks against different requirement groups.
This allows the system to identify whether the blocker is caused by capability, language, availability, venue, resource or contribution constraints.
The explanation is based on solver evidence rather than generated text.
Ordered intervention planning
ASSEMBLE evaluates possible catalyst actions, including ordered paths of up to two interventions.
Order matters because one intervention may create the prerequisite for another.
The system ranks successful paths by:
- total cost
- path length
- deterministic action ordering
This lets ASSEMBLE distinguish the cheapest action from the cheapest sufficient action.
Immutable capability states
Interventions never overwrite the original community state.
Instead:
[ S_0 \rightarrow S_1 ]
creates a copied successor state with an explicit machine-readable difference.
For example, training can add digital_support capability to two community members while preserving the original (S_0).
A state change is deliberately not treated as proof.
The initiative remains blocked until the successor state is independently solved again.
Proof-derived Projects
Once a state is verified, ASSEMBLE can derive an executable Project.
The user supplies only human metadata such as title, description and objective.
The backend reconstructs the authoritative state, replays the catalyst path, solves again, validates the witness and derives the operational details from that proof.
Resilience and recompilation
The Structural Stress Test generates controlled one-block failures from a verified plan and re-solves the model.
Recovery then uses a two-stage optimisation process.
First:
[ \min(\text{changed original assignments}) ]
Then, while fixing that minimum number of changes, ASSEMBLE optimises the normal planning burden.
This means the system first preserves as much of the original plan as mathematically possible, then finds the best valid replacement inside that minimum disruption.
Capability Frontier
The Capability Frontier applies each available catalyst independently and solves all initiatives before and after it.
This lets ASSEMBLE compare how much future capability each investment unlocks relative to its cost.
Product layer
The interface includes:
- Overview
- Community
- Initiatives
- Initiative Proof
- Projects
- Project Proof
- Resilience
- Collaboration
- Settings
- Technical Inspector / Judge Proof Mode
We also built a local identity and collaboration layer using FastAPI and SQLite, including local accounts, password hashing, HttpOnly sessions, roles, invitations and audit logging.
The visual layer uses lightweight custom civic illustrations and CSS perspective effects, keeping the decorative UI completely separate from the reasoning engine.
Challenges we ran into
One of the biggest challenges was making sure the project had real technical depth rather than just looking technical.
It is easy to display an OPTIMAL badge.
It is much harder to make sure that every status can be traced back to:
- a real solver result
- a valid witness
- the exact source state
- the exact intervention path that produced it
We also ran into several subtle engineering problems.
These included:
- correctly handling ordered action paths when one action depends on another
- preventing forged client state from being trusted
- keeping predecessor states immutable
- ensuring an intervention is never confused with proof that the intervention worked
- preserving
UNKNOWNinstead of turning uncertainty into false confidence - separating hypothetical Resilience scenarios from real operational Project state
- building two-stage recovery without accidentally optimising the wrong objective
- preventing stale browser responses from repopulating reset or changed state
- handling session lifecycle, role changes and invitation races safely
- making a technically dense interface understandable on both desktop and mobile
- preserving keyboard navigation, high contrast and reduced-motion accessibility
- keeping the visual layer lightweight enough that it did not interfere with the reasoning system
Late in development, we subjected ASSEMBLE to a large adversarial QA programme rather than just testing the happy path.
This uncovered real defects in:
- authentication and storage
- strict input boundaries
- analyser trust boundaries
- mounted UI validation
- documentation drift
We fixed these issues and converted them into regression tests.
Accomplishments that we're proud of
We are especially proud that ASSEMBLE is not just a concept demo.
The final system includes a real working technical chain:
[ \text{Community State} \rightarrow \text{Constraint Compilation} \rightarrow \text{Feasibility Proof} \rightarrow \text{Blocker Explanation} \rightarrow \text{Minimum Intervention} \rightarrow \text{Immutable State Change} \rightarrow \text{Independent Verification} \rightarrow \text{Executable Project} \rightarrow \text{Structural Stress Test} \rightarrow \text{Minimum-Disruption Recovery} ]
We are also proud of several engineering details:
- feasible solver outputs are independently replayed before being trusted
- Project readiness is derived from proof rather than client input
- ordered intervention paths are searched rather than treated as unordered sets
- hypothetical counterfactual states cannot become operational Project lineage
- minimum-disruption recovery is solved lexicographically
- the Capability Frontier compares capability growth and cost using Pareto analysis
- the core reasoning system does not depend on an LLM
- the app remains usable across desktop, mobile, keyboard navigation, dark mode, high contrast and reduced motion
Our final backend collection reached 1,975 passing tests, alongside frontend tests, browser journeys, responsive checks and independent solver-oracle testing.
One of the most satisfying parts of the project was deliberately trying to break ASSEMBLE and then turning every discovered failure into a regression test.
What we learned
The biggest thing we learned is that optimisation alone is not enough.
A useful decision system also needs to answer:
- Why is this possible?
- Why is this impossible?
- What evidence supports the result?
- What is the smallest meaningful intervention?
- Did that intervention actually work?
- What happens when the assumptions change?
- How much of the original plan can be preserved?
We also learned how important it is to separate different kinds of truth.
A hypothetical stress-test state should never become a real Project.
A state transition should never automatically become a verified result.
A solver result should never automatically become trusted evidence.
Those distinctions ended up shaping the entire architecture.
We also learned that communities are not static inventories.
Someone who lacks a capability today may be able to learn it tomorrow.
That means an intervention does not just move existing resources around. It can actually change the future state of the system.
That insight became one of the central ideas behind ASSEMBLE:
Communities are made of blocks, but the most valuable question is not simply what blocks exist. It is what those blocks can become together.
What's next for ASSEMBLE
The current prototype deliberately uses a small deterministic fictional community and a bounded intervention catalogue so that every result remains inspectable and reproducible.
The next step would be working with real community organisations to co-design:
- richer initiative templates
- larger capability taxonomies
- intervention catalogues
- real community capacity inputs
- more flexible planning horizons
- real operational data integrations
We would also like to connect persisted Collaboration spaces to the planning engine so that real community membership and declared capacity can become solver input rather than remaining separate from the fictional demo fixture.
Longer term, ASSEMBLE could become infrastructure for answering a deceptively simple question at community scale:
What could we make possible with what we already have?
Log in or sign up for Devpost to join the conversation.