The first Foundry work was deliberately narrow. The question was whether a local substrate could run a real FOLIO Licenses application without using Okapi as the application container, control plane, and gateway.
That question now has a practical answer. A user can open Lattice, authenticate through Zitadel, load a Loom-selected Licenses microfrontend, create a real license, and search for it again through mod-licenses, with Envoy handling routing and FOLIO compatibility headers.
That is enough evidence to stop treating the work as a single spike queue.
Why a roadmap, and why now?
A spike is useful when the uncertainty is concentrated. At the start, the uncertainty was technical and immediate:
- could Lattice dynamically compose a real Stripes UI module?
- could Envoy stand in front of the stack without becoming another Okapi?
- could Loom provide runtime intent without becoming a static config file forever?
- could Zitadel-backed OIDC work with the FOLIO-shaped browser and backend expectations?
- could
mod-licensesbe provisioned and called as a real module tenant?
The answer to those questions is now strong enough to change the management problem.
The risk is no longer that Foundry is smoke and mirrors. The risk is that every interesting direction starts to look equally urgent. Publisher automation, Kubernetes demos, local developer overrides, external ILS integration, platform services, operational catalog state, route publication, and executor hardening are all plausible next steps.
Without a roadmap, the backlog becomes a pile of valid ideas. With a roadmap, the backlog can stay executable while the project direction remains visible.
Roadmap is not backlog
This distinction matters enough to write down.
The roadmap records strategic goals and why their order matters. The backlog records concrete slices of work that can be implemented, reviewed, and closed.
That means a roadmap entry is not permission to start building everything under that heading. It is a statement of direction. A backlog item is the scoped commitment.
This is particularly important for Foundry because several concepts are adjacent but not owned here. ki-console is expected to provide the systems-user UX for requesting tenants, services, and demo environments. Foundry should not quietly become that console. Loom is a service provider to that upstream system: it executes workspace, activation, runtime, route, and reconciliation intents in an operational environment.
The roadmap helps protect that boundary.
The current position
The current state is useful because it has both visible evidence and internal structure.
The visible evidence is the Licenses create/search flow. It proves that the local substrate is not only rendering a screen. The system provisions the module tenant, injects the FOLIO compatibility tenant header at the gateway boundary, routes support calls to platform services, and calls the real Licenses backend.
The internal structure matters more for the next phase:
- Loom has persisted workspace and activation state.
- Lattice resolves runtime configuration from Loom rather than inferring tenant state from the URL.
- Envoy remains the routing and compatibility data plane.
- The local Docker substrate is one executor, not the execution model.
- The Stripes adapter has been extracted from the Licenses wrapper.
- The publisher can wrap and publish Licenses, Agreements, Open Access, and ILL UI artifacts to an S3-compatible target.
That combination makes a roadmap timely. There is enough platform shape to sequence work, and enough remaining uncertainty that sequencing still matters.
The roadmap as it stands
This is the first published roadmap. It is deliberately small enough to argue with.
It has five tracks:
| Track | Goal | Current state | Next pressure |
|---|---|---|---|
| Local developer runtime | Keep a reliable local Docker system that proves the architecture end to end. | Complete for Licenses create/search evidence. | Add first-class local component overrides without bypassing Lattice, Envoy, auth, tenant headers, or path compatibility. |
| Artifact supply chain | Turn FOLIO and K-Int UI modules into reusable Lattice MFE artifacts without hand-built wrapper repositories per release. | Complete for the first evidence set: Licenses, Agreements, Open Access, and ILL. | Harden CI behaviour, commit automation, adapter-version matrices, artifact verification, and failure handling. |
| Operational catalog and capability selection | Separate operational availability from workspace activation and from upstream product/offering management. | Implicit through publisher tracking and Loom static operational inputs. | Define the operational catalog boundary before persisting or importing it into Loom. |
| Kubernetes demo substrate | Install Foundry with Helm and provision demo workspaces from operational descriptors. | foundry-k8s exists as the substrate/deployment home; no Helm chart or Kubernetes executor exists yet. | Define the descriptor, reset semantics, and substrate responsibilities before implementing charts or controllers. |
| External ILS extension | Allow Foundry capabilities to extend existing FOLIO, Koha, TIND, or other library systems. | Boundary story only. | Define the Sovereign-style ILS-neutral interface and prove current self-hosted work has not blocked extension deployments. |
That table is the roadmap in short form. The rest of this section expands what each line means.
Track 1: local developer runtime
The local runtime is the proof harness. Every strategic claim should be testable locally before it becomes infrastructure theatre.
The current evidence is Licenses:
- start the Docker substrate;
- authenticate through Zitadel;
- load Lattice through Envoy;
- resolve runtime configuration from Loom;
- load the selected Licenses MFE artifact;
- create a real license through
mod-licenses; - search for that license through the UI.
The next local-runtime work is developer substitution. A developer should be able to keep most of the substrate running, but replace one backend with a service running in an IDE, or replace one frontend MFE with a JavaScript dev server. The important constraint is that the substitution should preserve the normal boundary: Lattice still composes the UI, Envoy still routes, auth still works, tenant headers still arrive, and path compatibility is still exercised.
The roadmap question for this track is:
Can local development stay convenient without teaching developers to bypass the exact boundaries Foundry needs to prove?
Track 2: artifact supply chain
The artifact supply chain exists because Foundry should not maintain one hand-built wrapper repository for every FOLIO UI module release.
The current evidence is wider than Licenses. The publisher has wrapped and published:
| Module | Release artifact | Branch-head artifact |
|---|---|---|
| Licenses | releases/licenses/v12.1.1/adapter-0.1.0/ | next/licenses/master/ |
| Agreements | releases/agreements/v12.1.1/adapter-0.1.0/ | next/agreements/master/ |
| Open Access | releases/open-access/v3.0.0/adapter-0.1.0/ | next/open-access/master/ |
| ILL | releases/ill/v2.1.3/adapter-0.1.0/ | next/ill/main/ |
That proves more than four uploads. Agreements forced the wrapper generator to merge source-module dependencies instead of carrying Licenses assumptions. Open Access proved the current adapter range against Stripes ^10.0.0. ILL proved that module-specific metadata overrides, such as translation namespace, belong in publisher tracking without turning the adapter into a set of bespoke wrappers.
The next work is hardening rather than widening for its own sake: CI behaviour, scheduled publication, git commit automation for tracking updates, adapter compatibility matrices, artifact signing or verification, and clear failure records when a module release does not fit the current adapter.
The roadmap question for this track is:
Can UI module publishing become reliable background reconciliation, while keeping runtime activation in Loom rather than in the publisher?
Track 3: operational catalog and capability selection
The operational catalog is the next boundary that needs care.
It is not a product catalog. It is not pricing, ordering, approval workflow, or systems-user UX. Those concerns belong upstream, probably in ki-console.
The operational catalog should answer questions Loom needs in order to execute activation intent:
- which UI module artifacts are available?
- which backend service images or releases are available?
- which support interfaces are required?
- which compatibility routes and headers are needed?
- which operational refs can be used for a workspace activation?
Today this information is scattered across publisher tracking and Loom static operational inputs. That is acceptable for the spike, but it is not a long-term shape.
The roadmap question for this track is:
Can Loom consume operational availability without becoming the product/offering management system?
Track 4: Kubernetes demo substrate
The Kubernetes track exists because the next useful demo is not just a developer laptop.
The target shape is:
helm install foundry ...
POST descriptor:
workspace: demo-1
frontendBaseUrl: https://demo-1.example.org
capabilities:
- licenses
- agreements
- open-access
- illThe expected result is a demo workspace that non-technical staff can use: login works, Lattice shows the selected apps, backends are provisioned, routes exist, and the workspace can be reset.
The reset requirement matters. A demo environment should be able to delete and reprovision demo-1 on a schedule, for example at 02:00, without confusing destructive demo reset with ordinary reconciliation.
The foundry-k8s repository now exists as the home for this deployment/substrate work. The first work is not to rush into chart YAML. The first work is to define the descriptor, Helm boundary, executor/controller responsibilities, identity integration, route publication model, and reset semantics.
The roadmap question for this track is:
Can Kubernetes deployment stay a substrate concern, while Loom continues to own lifecycle intent and reconciliation state?
Track 5: external ILS extension
Self-contained Foundry is only one use case.
The other strategic use case is:
I already run FOLIO, Koha, TIND, or another ILS. I want to extend that system with a Foundry capability.
That path needs to stay open even while the current work focuses on a self-hosted subset of modules.
This probably depends on a Sovereign-style interface: an ILS-neutral service boundary that lets modules call library capabilities without knowing whether the backing system is FOLIO, Koha, TIND, or something else.
The immediate work is not to implement the full extension model. It is to document the boundary and check that self-hosted decisions do not block extension deployments.
The roadmap question for this track is:
Can Foundry modules depend on stable library capability interfaces rather than each target ILS directly?
What this changes
The roadmap does not make the project heavier. It should make it easier to move quickly without drifting.
When a new backlog item is created, it should name the roadmap goal it advances. When a backlog item materially changes direction, the roadmap should be updated. When the roadmap changes substantially, the public narrative should be updated too, usually first with a current-state post and then with a roadmap/update post.
That last part is not marketing ceremony. It is a useful discipline. Foundry is a long-running, multi-agent project, and the blog is one of the ways we keep the argument inspectable from the outside. If the roadmap changes but the explanation does not, the project will start to look arbitrary even if the internal backlog is tidy.
The next shape of work
The next strategic chunk should move from local proof and artifact publishing toward operational composition.
The near-term question is:
Can Loom accept an operational descriptor for a workspace, select available UI artifacts and backend service refs, and drive reconciliation without becoming a product/offering system?
That question connects the roadmap tracks without merging them. It keeps ki-console upstream. It keeps Lattice as runtime composition. It keeps Envoy as the data plane. It lets Kubernetes support become an executor/substrate concern rather than a rewrite of the architecture.
The Licenses spike proved that the basic separation can work. The roadmap exists now because the next work needs to prove that the separation can scale.