- Larger touch targets (44x44px min)
- Clear button labels (☰ / ✕)
- Better spacing and padding
- Visible menu items with hover states
- All navigation tested and working
Verified 10/10 tests:
✅ Health endpoint
✅ Version endpoint
✅ UI loads with menu
✅ API missions list
✅ API mission detail
✅ File upload
✅ HTTPS redirect
✅ TLS certificate valid
✅ DNS resolution
✅ Response time <10ms
- Collapsible hamburger menu (☰) for mobile
- Clean header with just 'LandveX' title
- Developer mode toggle as small lock icon
- Menu items with emoji icons for clarity
- Full navigation hidden behind menu toggle
- Tested on pilot.landvex.com
- After each pilot day: identify 3 biggest irritations
- Fix only those before next pilot day
- Progress tracking with visual indicator
- Add new irritations on the fly
Part of OR-001 Operational Readiness.
Next: Pilot 001 — Break the system!
- Responsive font sizes with clamp()
- Shorter navigation labels (Explorer, Upload, Console, Health, Pilot, Ready)
- Developer Mode -> Dev
- Flex wrap for mobile screens
- Smaller padding and gaps
Tested on pilot.landvex.com
- Every pilot creates assets (Session, Mission, Artifacts, Metadata, Timeline, Report)
- Every failure is a Field Discovery (FD-XXXX), not a bug
- Every upload becomes permanent knowledge (Asset -> Metadata -> Knowledge -> Decision -> Learning)
- Measure the factory: Reality, Knowledge, Decisions, Learning, Economy
- Verified Decision Library: the biggest asset (2M observations, 400K cases, 150K verified)
- Sprint planning starts with real pilot observations, not backlog
- After 20-50 missions: workshop sorting into Bugs, Friction, Product Ideas
This is not a new ADR or architecture.
This is how we work every day.
Next: Pilot 001 — Break the system!
- Semantic: What is the object?
- Spatial: Exactly where?
- Temporal: When observed and how changed?
Rich geometry support from start:
- SpatialContext: facade, floor, zone, height, lane, direction
- Geometry: point, polygon, line with coordinates
- CameraPose: position, heading, pitch, roll
Precision in 4 steps: GPS -> triangulation -> 3D -> history
Stronger Decision Cases with exact location
Vision: Continuously updated georeferenced knowledge model
Next: Pilot 001
- Five levels: Reality → Digital Representation → Current State → Intelligence → Prediction
- Unique value: Every object gets a life history
- Not a digital twin focused on visualization
- Focus: verified observations, changes over time, decision support, business value
- Living operational model that improves with each verified observation
Vision:
LandveX is a continuously updated operational model of the customer's
infrastructure that combines verified observations, history, and decision
support to help organizations prioritize the right actions at the right time.
Complements Product Levels, Platform Architecture, Engineering Standard.
Next: Pilot 001 — break the system!
- Level 0: Public (free) — open map, trends, heatmaps
- Level 1: Professional — own areas, dashboard, reports
- Level 2: Enterprise — AI rules, Mission Engine, Hotspots, Credits
- Level 3: Platform — multi-org, custom models, white-label, federation
Design Principle: Progressive Disclosure
- Default: very simple
- Advanced: more detail on same page
- Same Decision Case, different detail levels
Core Principle:
All users work in same LandveX platform.
License determines intelligence depth, not objects.
Complements Platform Architecture v2.0 and Engineering Standard v1.0.
Next: Pilot 001 — break the system!
- API running on port 3002
- UI running on port 3003
- Version endpoint: /version
- Health check: /health
- Platform Readiness: Mission Import ✅, Artifact Registry ✅,
Storage ✅, Operations ✅, Developer Mode ✅
Go Live Checklist updated with current status.
Docker Compose configured (ports adjusted for existing services).
Next: Pilot 001 — Break the system!
Test: bad coverage, large videos, interrupted upload,
multiple phones, bad GPS, darkness, rain, poor lighting.
- Go Live Checklist for LandveX Internal Pilot deployment
- Version endpoint: /version returns environment, version, commit, build
- Ready for Internal Pilot deployment
Next: Deploy with Docker Compose
- Kubernetes-first for platform architecture
- GitOps: never manual cluster changes
- Local-first for dev experience, K8s-first for platform
- All infrastructure as code, same Git flow as app code
- Standardized service contract: /health, /ready, /live, /metrics, /version
- OpenTelemetry tracing, structured JSON logging
- Correlation ID follows entire pipeline: Session → Mission → Artifact → Observation → Evidence → Decision
- Intelligence Lab integrated in same platform, not separate cluster
- Platform principle: no new service introduces new deploy/log/config/observability pattern
Binding for all developers and AI agents.
Complements E-001, EP-1.0, Architecture Principles.
Next: Deploy pilot environment
- 4 roles: SuperAdmin, Operator, Reviewer, PilotUser
- Capabilities (not pages): mission.create, artifact.view, decision.approve, etc.
- Feature flags: ENABLE_REPLAY, ENABLE_MODEL_TRAINING, etc.
- Developer Mode toggle in UI (activated by permission)
- New rule: All features must link to module, capability, and role
Next: Deploy pilot environment
- LandveX is one platform, not two
- Same backend, database, API, map
- Intelligence Lab = Developer Mode (not separate product)
- Same Artifact Viewer, different detail by role
- Same map, different layers by role
- Role-based access: Erik, Johan, Pilot Customer, Municipality
Architecture Principle:
One platform. One API. One data model. One map.
One Artifact system. Multiple roles.
Next: Implement RBAC and Developer Mode toggle
- Fältfas: område, varför, infrastruktur, förväntade objekt, tid, problem
- Teknisk fas: session, mission, artifacts, upload, metadata, explorer, viewer
- Beslutsfas: rätt observation, evidens, beslut, varför inte
- Utvärdering: tid, osäkerhet, automation, värde, nästa steg
- Golden Mission-knapp för att markera #0001
Mål: Kan vi gå från verklighet till verifierat Decision Case utan
manuella genvägar?
Stoppregel: Ingen ny arkitektur förrän Pilot 001 genomfört.
Next: Starta Pilot 001 — film, upload, verifiera
- Verkliga data först
- Pipeline före modell
- Decision Case är målet
- Träna kontinuerligt
- STOP-regel: ingen funktion utan validering på pilotmaterial
- Sista princip: ingen modellförbättring färdig utan mätbar förbättring
Stoppregel: Ingen ny arkitektur förrän MVP-0 genomfört med verkligt uppdrag.
Next: Pilot 001 — First real field upload
- Field Console: 4 tabs (Upload, Queue, Artifact Viewer, Timeline)
- Health Dashboard: system pulse for 6 engines
- No more ADR documents until MVP-0 proven with real mission
Stoppregel: Ingen ny arkitektur förrän första verkliga uppdraget.
Next: Pilot 001 — First real field upload
- Dataset Explorer: list missions with processing status
- Artifact Viewer: mission details, metadata, processing status
- Mission Upload: simple video upload form
- React + Vite + React Router
- Proxy to API at localhost:3000
MVP-0 Acceptance Criteria:
✅ Upload video
✅ Create mission
✅ View mission in Dataset Explorer
✅ View artifact details
✅ See processing status
No AI. Just file transfer, storage, metadata, registry.
Next: Pilot 001 — First real field upload
- LANDVEX_PLATFORM_ARCHITECTURE.md: Five Engines (Reality, Knowledge,
Decision, Mission, Economic)
- Credit: first-class economic object with types (mission, validation,
training, priority, emergency)
- IntelligenceLedger: tracks value creation separate from financial accounting
- KnowledgeGap: missing information that drives missions
- Hotspot: composite score for mission generation
- Contradiction: conflicting information as opportunity
Key principle: Every component answers 'What value is created here?
Who pays for it?'
Next: PR-005A — Minimal Mission Import UI for MVP-0
- LANDVEX_PLATFORM_ARCHITECTURE.md: Five Engines (Reality, Knowledge,
Decision, Mission, Economic)
- Credit: first-class economic object with types (mission, validation,
training, priority, emergency)
- IntelligenceLedger: tracks value creation separate from financial accounting
- KnowledgeGap: missing information that drives missions
- Hotspot: composite score for mission generation
- Contradiction: conflicting information as opportunity
Key principle: Every component answers 'What value is created here?
Who pays for it?'
Next: PR-005A — Minimal Mission Import UI for MVP-0
- POST /api/v1/missions/import — multipart upload with video
- GET /api/v1/missions/:id — retrieve mission
- GET /api/v1/missions — list active missions
- Express + multer for file handling
- Uses application layer handlers (PR-002.5)
- In-memory repositories (swap for PostgreSQL in PR-003B)
Acceptance Tests (5/5 passing):
✅ Import mission with video
✅ Reject upload without video
✅ Retrieve mission by ID
✅ 404 for non-existent mission
✅ Health check
MVP-0 Definition of Done:
✅ Phone → Upload → Store → Retrieve
✅ No AI required
✅ First real artifact produced
Next: PR-005A — Minimal Mission Import UI
- Repository interfaces defined by domain (@landvex/domain)
- 6 in-memory adapters: Session, Mission, DecisionCase, Artifact, EventStore, UnitOfWork
- 9 tests verifying adapter contracts
- Domain unchanged — infrastructure depends on domain, never reverse
- ADR-006: In-Memory Adapters for Testing
Definition of Done met:
- All adapters compile against domain interfaces
- Unit tests pass (9/9)
- No PostgreSQL, S3, Express, AI in this PR
- Ready for PR-003: PostgreSQL adapters
- @landvex/domain package with TypeScript strict mode
- 3 Aggregate Roots: FieldSession, Mission, DecisionCase
- Branded IDs, Value Objects, Domain Events, Invariants
- 19 unit tests for IDs, FieldSession, DecisionCase
- Zero runtime dependencies (only TypeScript + jest for tests)
- Separates Entity / Value Object / Aggregate Root
- README documents Three Rules of the domain
Definition of Done met:
- Compiles without errors
- Exports all domain types
- Unit tests for invariants and value objects
- No PostgreSQL, S3, Express, AI models, queues
- Added Three Rules to README:
1. Domain knows nothing about AI (no AIObservation, YOLODetection, etc.)
2. Everything is an Artifact (common contract for all produced objects)
3. All decisions are reproducible (answer: which observations, evidence,
model, version, rules, reviewer, when, approved version)
- Renamed Human Intelligence → Experience Intelligence
- Broader scope: citizen surveys, customer satisfaction, field technician
feedback, contractor experience, service desk data
- More future-proof than 'Human Intelligence'
- Added Capability Tags for developers:
- Observation: [Detection, Vision, GPS, Image]
- Decision: [Decision, Recommendation, Business]
- Artifact: [Storage, Versioning, Lineage]
- Makes dependencies clear as platform grows
- Updated Domain Invariants:
- DecisionCase: must have at least one Review before Approved
- Review: must belong to exactly one Decision, must have reviewer
- Added Merge Criteria:
- All stakeholders (developer, AI engineer, product owner, domain expert)
can read model and understand same terms
- No AI objects, all Artifacts, reproducible decisions
Rationale: Lock domain language before implementation. Shared vocabulary
for code, docs, APIs, tests, and product discussions.
- Added Human Intelligence as separate external module (not in core domain)
- Positioning: External Intelligence Module, not part of Epic-001
- Architecture: Reality Intelligence with four branches:
- Infrastructure Intelligence (core, Epic-001)
- Operational Intelligence (future)
- Human Intelligence (future module)
- External Intelligence (future)
- Human Insight Artifact: Source, Geography, Period, Metrics, Confidence
- Usage: Linked to Area or Decision Case, never mixed with raw observations
- Example: Decision Case enriched with 'Many complaints last 30 days'
- When: After Epic-001 stable and 20+ Decision Cases exist
Rationale: Keep core domain clean. Human data is context, not observation.
Add after basic pipeline is proven.
- Package: @landvex/domain
- Zero dependencies on Express, PostgreSQL, S3, or AI frameworks
- Four package structure: domain, contracts, shared, infrastructure
- Domain never depends on infrastructure
- Aggregate Roots: FieldSession, Mission, DecisionCase
- Entities: MissionAsset, Artifact, Observation, Evidence, Finding,
Decision, Review, Action, Outcome
- Value Objects: MissionId, ArtifactId, SessionId, ObservationId,
DecisionId, GeoLocation, GpsAccuracy, Confidence, Severity, Priority,
Hash, StorageUri, Version
- Enums: ArtifactType, ReviewStatus, DecisionVerb, MissionStatus, SessionStatus
- Event Contracts: FieldSessionCreated, MissionCreated, MissionImported,
ArtifactUploaded, ArtifactValidated, ObservationCreated, EvidenceCreated,
FindingCreated, DecisionCreated, DecisionReviewed, DecisionApproved
- Domain Invariants:
- FieldSession: must have location, date, can have zero missions
- Mission: must belong to one Session, must have at least one Artifact
- DecisionCase: must have at least one Observation, one Evidence,
exactly one Decision, cannot be Approved without Review
- Artifact: must have unique hash, storage URI, versioned
- TypeScript interfaces for all domain objects
- Branded ID types for type safety
- Strict rule: No new feature may introduce new domain concepts without
approved change to domain model
- README: 'This package describes LandveX domain model. Contains no
dependencies to database, HTTP, cloud storage, or AI frameworks.'
- Next: PR-002 Persistence Adapter (Repository Interface → PostgreSQL/S3/Event Store)
Rationale: Lock the language before writing infrastructure code.
Shared vocabulary for code, docs, APIs, tests, and product discussions.
- Session is root (not Mission): Field Session → Mission → Asset → Observation...
- Event Sourcing: never overwrite status, status is projection of history
- Artifact Registry: first-class object with id, type, version, hash, lineage
- Decision Case immutability: Review → Revision → Approved Version (like Git)
- Review Task: Assigned → Reviewed → Approved → Closed
- Processing Graph: nodes not hardcoded chain, swap models without changing rest
- Data Quality as domain: Blur, Duplicate, Bad GPS, Low Resolution, etc.
- Decision Case comparison: show exactly what changed, which evidence, model, human
- Golden Missions + Golden Datasets: two levels
- Domain Event Viewer: timeline (09:42 Mission Created, 09:43 Video Uploaded...)
- KPI: Verified Decision Throughput (verified decisions per day)
- Architecture Principle: 'Produces verified Decision Cases through reproducible
and traceable pipeline'
Updated PR-001 Domain Model:
- Added FieldSession (root)
- Added Artifact interface
- Added Event sourcing types
- Session ID format: session_YYYYMMDD_NNNNNN
- Updated API to include /sessions endpoints
Rationale: Three fundamental objects (Session, Artifact, Event) make the rest
natural. Scalable, auditable, well-suited for public sector traceability requirements.
- Added Vision: 'LandveX Intelligence Lab is the internal factory where
raw reality is refined into verified Control Intelligence'
- Added Architecture Goal: Every artifact traceable backward to source
and forward to decision
- Added Development Rule: No Story starts with UI. Order: Domain model →
API → Storage → Tests → UI
- Added Story 1 implementation plan with 5 PRs:
PR-001: Domain Model (Mission, MissionAsset, Upload, types)
PR-002: Storage (S3/R2 bucket, PostgreSQL metadata, checksums, EXIF, GPS)
PR-003: API (POST /missions, POST /missions/{id}/assets, GET /missions)
PR-004: Events (MissionCreated, AssetUploaded, RawDatasetReady)
PR-005: UI (simple drag-and-drop upload with progress)
- Added Definition of Done for Story 1:
Phone → Video → Upload → Bucket → Metadata → Mission visible in Dataset Explorer
- Added ID Convention: mission_YYYYMMDD_NNNNNN, asset_NNNNNN, obs_NNNNNN,
decision_NNNNNN. Never UUID in UI.
- Added Artifact Viewer: show raw asset metadata, hash, GPS, EXIF,
storage location, version for debugging
Rationale: Clean architecture, testable without UI, traceable artifacts.
- Reordered stories to reach First Verified Decision faster:
1. Mission Import (was 2) — proves we can receive real data
2. Dataset Explorer (was 3) — makes data visible
3. Annotation Workspace (was 4) — first human-in-the-loop
4. Decision Case (was 5) — first verified decision
5. Replay (was 6) — proves chain is reproducible
6. Session Management (was 1) — organizes when core works
- Added Golden Mission concept:
- Real mission that never changes, used as regression test
- Every new model runs against same mission
- See immediately if something got better or worse
- Added Review as first-class object:
- Observation → AI → Human Review → Approved/Rejected/Needs More Evidence
- Makes entire quality flow traceable
- Added Dashboard v1:
- Sessions, Missions, Decision Cases, Pending Reviews, Verified Decisions
- Big button: [Continue Reviewing]
- Work tool, not BI system
- Added vertical user journey (demo script):
- quiXzoom → photo → import → save → explore → AI observation →
correction → Decision Case → full chain viewer
- If this works, core is proven
- Added definition of 'First Verified Decision':
- Built on real observation data
- Reviewed by human
- Complete evidence chain
- Fully reproducible from raw data to recommendation
Rationale: Reach core proof faster, add organization later.
Golden Mission enables regression testing from day one.
Review object makes quality flow traceable.
- STOP Rule: No new pipeline until 20 real Decision Cases exist
- Field Readiness Gate: 5 questions before building any feature
- Sprint Goal: Every sprint must produce more verified Decision Cases
- Six stories:
1. Session Management — organize missions by location/date
2. Mission Import — upload video/images/GPS/EXIF, store immutably
3. Dataset Explorer — browse, filter, search, map view
4. Annotation Workspace — review/correct AI, version history
5. Decision Case — full chain: Observation→Evidence→Finding→Decision→Business Impact
6. Replay — step through mission chain (V1: simple playback)
- Not in first release (intentionally postponed):
GPU Queue, Hyperparameter Search, Distributed Training,
Benchmark, Canary Deployment, Auto Retraining,
Bias Dashboard, Drift Detection
- Definition of Done: Complete vertical slice from reality to verified decision
- Definition of Ready for Epic-002: 20 real Decision Cases + Field Readiness Gate
- Technical stack: React+TypeScript, Node.js+Express, PostgreSQL, S3/R2, Bull, Python AI service
- Quality gates: TypeScript strict ≥80% coverage, no secrets, OAuth 2.0, immutable audit log, GitOps
Rationale: Prove the system works end-to-end before scaling.
Focus on learning from reality, not building everything upfront.
Bernt