Roadmap — SmaRT v1.0.0 Program

Following the successful Bayeux Tapestry transport (v0.4), this roadmap turns the validated platform into a multi-tenant SaaS reference for exceptional artwork transport. It consolidates the workstreams from proposal 202603-SMA (6 lots, adaptable) and the priorities set in July 2026.

Primary goal for summer 2026: give the S-MA-C-H super-admin full autonomy to operate the platform — onboard new organizations, manage users, and administer data — so new museum and client contracts can be welcomed in good conditions.

Guiding principle: quality and architecture first. Each workstream lays clean, durable foundations rather than shortcuts.

---

Workstreams

1. Back-office console (super-admin)

A dedicated administration console inside SmaRT (/admin/*), restricted to the super-admin role, designed from the start as an extensible console: new sections plug in as the workstreams below are delivered.

Section	Purpose	Status
Organizations	Create, edit, archive organizations; cross-org overview	🎯 First delivery
Users	Create, edit users; org membership and role assignment	🎯 First delivery
Storage	Per-organization S3 space, monitoring data, processing routines	⏳ Workstream 3
Catalog	Datalogger stock, purchase/rental, transport crates	⏳ Workstream 4

2. Identity & Access Management (orgs / users / roles)

A dedicated iam microservice (Spring Boot 4 WebFlux, no database) exposing organization, user, and role management APIs on top of the Keycloak Admin API — modeled on proven in-house patterns (Locknest IAM).

Key architecture decisions (2026-07):

• Native first. Organizations use Keycloak's native Organizations feature (already in place). Per-organization roles (e.g. administrator of org A, viewer of org B) rely on native Organization Groups with realm roles attached (Keycloak 26.7), exposed in tokens per organization. When native Organization Roles land (Keycloak 26.8, expected end of September 2026), migration is confined to Keycloak — no API or UI change.
• No role-naming conventions ({org}:{role} realm roles) and no third-party organization extensions: both would conflict with the native trajectory.
• Realm as code. The Keycloak realm configuration (clients, scopes, mappers, roles) becomes reproducible through an idempotent setup — ending manual click-through configuration.
• Prerequisite: Keycloak upgrade 26.4 → 26.7.

First delivery scope: organizations CRUD, users CRUD, org ↔ user ↔ role associations. Deferred: email invitations, MFA management, password reset flows, audit trail.

3. S3 storage management

Per-organization object storage administration: monitoring data spaces, datalogger data processing routines (feeding the Artwork Passport), upload/download.

• Builds on the existing S3 integration in the backend.
• The storage layer stays S3-API agnostic: the current MinIO backend is slated for replacement by an alternative object store at the platform level (Ceph RGW, SeaweedFS, RustFS…) — SMACH will be one of the first consumers of that decision. No MinIO-specific feature may be used.
• Corresponds to lot 2 of the proposal (S3 Data Space, LTTB downsampling pipeline).

4. Catalog & commerce

Datalogger (logger box + probes) and transport crate stock management, purchase and/or rental — connected to Stripe and the public site. Corresponds to lot 5 of the proposal. Scoped later; the back-office console reserves its place.

---

Sequencing

Design of the console (UX/UI) proceeds in parallel with the Keycloak/iam foundations. Target for workstreams 1–3 in minimal version: end of summer 2026 (indicative — scope follows client needs).

Platform foundations (transverse)

Improvements carried alongside the workstreams, in line with the quality-first principle:

• Backend security hardening — explicit deny-by-default HTTP security, role-guarded IAM routes.
• Per-organization authorities — the backend derives roles from the per-organization token claim (super-admin remains the only global realm role).
• GitOps deployment — migrate SMACH deployment manifests to the platform's ArgoCD solution (replacing the legacy pipeline); the new iam service is deployed this way from day one.
• Frontend API layer — completion of the typed OpenAPI client migration.
• Role taxonomy alignment — reconcile current roles (viewer / administrator / super-admin) with the proposal's taxonomy (operator, client) before the realm setup is frozen. Decision pending with S-MA-C-H.

---

Created 2026-07-21 — updated at each milestone and steering meeting.