SPINE
Kjernen i ALTBIM-plattformen. SPINE eier prosjektdata, kjøringer, artifacts,
issues, tasks, observations, zones, assets og handover — ett felles API for
FORGE, NEEDLE, ATLAS, SCOUT og BEACON.
Hvorfor SPINE finnes: ALTBIM skal ikke bli mange separate apper med hver sin historikk. SPINE gir én prosjektlogikk, én datamodell og én sannhet som alle klientflatene kan bygge på.
Eier
Projects, runs, issues og handover
Neste fokus
API-kontrakter, webhooks og kommersiell åpning
Hva SPINE er og hvordan det fungerer
Hva SPINE er
SPINE er backend-kjernen i ALTBIM og felles system of record for hele plattformen. Det er her prosjektidentitet, runs, artifacts, avvik, oppgaver og observasjoner lever.
Hva SPINE skal gjøre
Produktet skal sikre at alle klientflater jobber på samme sannhet: én datamodell, én historikk og tydelige kontrakter som gjør videre skalering mulig uten databrudd.
Hvordan SPINE fungerer
SPINE eksponerer API-kontrakter som klientene leser og skriver mot. FORGE og NEEDLE publiserer produksjonsdata, ATLAS følger opp, og SCOUT/BEACON leser samme prosjektgrunnlag i felt.
Hvordan det føles i drift
For teamet skal SPINE oppleves stabilt og forutsigbart: tydelige endepunkter, sporbar audit, konsistent datakvalitet og trygg plattformutvikling over tid.
Produktgrafikk
SPINE Plattformmotor
api first
SPINE holder samme prosjektidentitet gjennom hele suiten, slik at data fra authoring, desktop, web og felt kan spores uten brudd i historikk.
Plattformflyt
infografikk
1
Motta Klientdata
FORGE, NEEDLE og ATLAS skriver operasjoner til samme modell.
2
Normaliser Og Lagr
SPINE lagrer runs, tasks, issues og artifacts med auditbar historikk.
3
Eksponer Videre
SCOUT og BEACON leser samme status, klare for felt- og kioskbruk.
Produktrolle
Felles system of record
SPINE eier Project, ProjectConfig, Run, Artifact, Issue, Task, Checklist, Observation, Zone, Asset, Space og HandoverPackage.
Prosjektdatamodell
Komplett datamodell for BIM-prosjekter: soner, oppgaver, avvik, handover-pakker og kjøringer.
Planlagte kjøringer
Cron-baserte kjøringer for automatisk IFC-behandling, validering og rapportgenerering.
Filbasert nå, PostgreSQL neste
Første fundament bruker filbasert plattformlager. Fase 2 flytter dette til PostgreSQL for multi-tenant drift.
OpenAPI / Swagger
Fullstendig API-dokumentasjon med interaktiv Swagger UI og ReDoc — alltid oppdatert.
Hendelseslogg
Komplett audit trail for alle operasjoner. Hvem gjorde hva, når — søkbart og filtrerbart.
Hva SPINE betyr i praksis
Én sannhet
SPINE finnes for at ALTBIM ikke skal bli seks separate apper med hver sin historikk. Det er her prosjektidentitet, runs, avvik, oppgaver og observasjoner faktisk hører hjemme.
Felles prosjektidentitet
Når FORGE, NEEDLE, ATLAS, SCOUT og BEACON bruker samme projectId og runId, kan aktivitet spores på tvers av authoring, desktop, web og felt uten databrudd.
Kontrakter før UI
SPINE definerer objektene og kontraktene som klientflatene må følge. Dermed kan ny funksjonalitet bygges uten at hver klient finner opp sin egen datamodell.
System of record
Klientene er arbeidsflater. SPINE er stedet som gjør aktivitet søkbar, delbar, sporbar og mulig å bygge videre på i senere faser.
Hvem SPINE er for
Utviklere og integrasjoner
SPINE gir et felles API og låste datakontrakter som alle ALTBIM-klienter og senere partnerintegrasjoner kan bygge på.
Produktlaget
Når nye flater kommer, kan de kobles på samme prosjektmodell i stedet for å starte som egne siloløsninger med duplisert logikk.
Prosjektorganisasjonen indirekte
Brukerne møter kanskje ikke SPINE direkte, men de drar nytte av at historikk, observasjoner, avvik og leveransedata følger prosjektet på tvers av alle flater.
Drift og skalering
SPINE er også grunnlaget for auth, audit, scheduled jobs, realtime og senere multi-tenant drift når plattformen modnes fra fundament til robust tjeneste.
Typisk datalivsløp
1. Prosjekt bootstrap
Et prosjekt opprettes eller gjenbrukes i SPINE, slik at alle klienter kan samles rundt samme identitet og samme historikk.
2. Klientene publiserer
FORGE sender runs, artifacts og issues. NEEDLE sender prosjekt- og module-events. ATLAS skriver tasks og observations. SCOUT og BEACON skal bruke de samme kontraktene.
3. Snapshot oppdateres
SPINE oppdaterer operasjonelt snapshot, governance og event-feed slik at status kan leses på tvers av kontor, desktop og felt uten ekstra synkroniseringslag.
4. Plattformen vokser videre
Når PostgreSQL, auth, webhooks og realtime bygges ut, skjer det på toppen av samme objektmodell i stedet for å bryte bakoverkompatibilitet mellom klientene.
Klientflyt
FORGE → SPINE
Desktop-kjøringer oppretter projectId, runId, artifacts og issues etter dokumentanalyse, IFC-berikelse, QA, IDS/BCF og Solibri-flyt.
NEEDLE → SPINE
Revit-pluginen skal være en tynn authoring-klient for metadata, NOFO, MMI, NS3457, TFM, etasjer og IFC-eksporttrigger.
SPINE → ATLAS
Kontorportalen henter run-historikk, avvik, artefakter, oppgaver og observasjoner fra samme prosjektgrunnlag.
SCOUT/BEACON ↔ SPINE
Felt og kiosk bruker tasks, zones og observations fra SPINE. Bilder fra felt lagres som artifacts, ikke som separate kiosk- eller mobildata.
Operativ informasjon
Autoritativ kjerne
SPINE er stedet der roller, prosjekttilganger, artifacts, observasjoner og kjøringer må håndheves konsekvent. Klientene skal ikke ha egne sannheter om hvem som har tilgang til hva.
Det viktigste akkurat nå
Nå handler SPINE om robust auth, prosjekt-RBAC, audit, storage-sikkerhet, invitasjonsflyt og en schema-/migrasjonsmodell som tåler videre produktutvikling uten å sprekke.
Hva klientene forventer
ATLAS forventer lesbar prosjektstatus. FORGE forventer trygg ingest av runs og artifacts. SCOUT og BEACON forventer at felt- og kioskdata kan speiles uten særbehandling per klient.
Neste milepæl
Etter dagens hardening-spor er neste naturlige steg å ferdigstille databasegrunnlag, rydde legacy-auth, styrke observability og gjøre prosjektmedlemskap til eksplisitt adgangsgrunnlag over hele API-et.
Roadmap
Felles prosjektkontrakter
SPINE har første kontrakter for projects, runs, artifacts, issues, tasks, observations, zones, assets, spaces og handover-readiness.
- project-ingest, analyze-documents, build-config og run-ifc
- Run-resultater med artifacts og issues
- Observasjonsbilder som artifacts
Fra filbasert lager til PostgreSQL
Neste store tekniske steg er robust database, auth, scheduled jobs, kildeintegrasjoner og varslinger.
- PostgreSQL og multi-tenant struktur
- JWT/Supabase Auth og rollemodell
- Scheduled runs, lokal mappe og BIMcollab-integrasjon
Handover, drift og åpen plattform
SPINE modner asset, space og handover-laget før offentlig API, webhooks og partnerintegrasjoner åpnes.
- HandoverPackage, COBie/IFC4-spor og asset-dokumentasjon
- Owner/operations-portal som eget lag
- Offentlig API og webhooks i Fase 5+
API-endepunkter
REST API — v1
SPINE eksponerer felles prosjektkontrakter under /api/. Klientene bruker samme projectId, runId og artifact-modell.
SPINE