Observation Surface
The render layer. Any object brings its own UI. 11 ViewKinds auto-generated from the schema. Meridian-themed, AR-ready.
IOBOXX has two render targets — static HTML twin sites and the live observation app — and both sit on top of the same memory substrate. Every visible object on the surface is a live projection of a typed Object Store node, materialised from its current attributes and updating in place whenever a Fundi mutates it through MCP.
The surface is deliberately thin. It holds no state of its own, makes no decisions, has no routes in the traditional sense. Objects are the navigation. The decision filter is one line: if it adds client-side state, wrong; if it makes the surface thinner, right.
UNIVERSAL ADAPTIVE UIAny object — brings it
A single Universal Adaptive UI component takes a single prop: the type name. Pass it Invoice and it renders an invoice management interface. Pass it Coffee Variety and it renders a coffee variety catalog. The component never knows what an invoice is — it reads the schema and generates the interface.
The schema lives as __TypeDef + __FieldDef + __ViewDef objects in the Object Store. Where the data physically sits is a separate concern, covered under data. The surface only cares about the schema — and the schema is data.
VIEWKINDS11 views, auto-generated from the schema
Every type carries its own rendering instructions in a __ViewDef attribute. A generic renderer reads the config JSON and materialises the view — no per-type components are written. The catalogue is closed by architectural commitment: 11 view kinds cover every operational shape; nothing else is renderable.
| ViewKind | Purpose |
|---|---|
| list | Virtual-scrolled tabular triage. Sortable columns, lookup resolution, badges, monetary/date formatting, group-by. |
| form | Section-based detail surface with 14 field types, header actions, status bar, inline-table tabs, totals. |
| search | Quick-search, faceted filter chips, group-by. Composes with list, kanban, card. |
| detail | Composite: search + collection + form pane. The default landing view for any type. |
| column | Mobile-optimised Miller-column. Three collapse rules — stack, sheet, drillIn — fold down to a 375 px phone. |
| kanban | Stage-based pipeline with drag-and-drop column transitions. Authored, never auto-generated — a bad guess is worse than no kanban. |
| calendar | Time-scheduled objects in month/week/day. Auto-generated whenever a type has date fields. |
| graph | Bar / line / pie with row/col/measure field roles, date bucketing, stacking, cumulative modes. |
| pivot | Pivot table over numeric measures with row/col dimensions. Requires explicit groupable + numeric fields. |
| tree | Hierarchy / org-chart for parent/child relationships. Auto-generated when a parent reference field exists. |
| card | Visual grid: image, title, badges, body fields, footer, accent stripe. The discovery view for browsing rather than scanning. |
Closed catalogue. New visual shapes do not get added by writing new components — they get added by extending an existing ViewKind or by changing the schema the existing kinds render.
OBJECT CARDSThe atomic unit
Every materialised entity on the surface renders as an object card. The card carries semantic rendering instructions from the type's __ViewDef: monetary fields get currency formatting, dates get calendar widgets, lookups resolve foreign references, status fields get state-machine badges, boolean fields get toggles, URL fields get links. One renderer, every type.
Object cards are how the live observation app makes Fundi work visible. When a Fundi creates a Section, a Page, a TenderItem, an Invoice — the surface subscribes to oodb_object.onInsert and a card appears. Mutations land via oodb_attribute.onUpdate and the card re-renders in place. Deletions fade it out. No build step, no page reload, no route change.
DYNAMIC FORMOne panel, every edit
A single Dynamic Form handles all editing on the surface. Every create, every edit, every dialog flows through one self-contained panel with built-in dirty tracking, validation, navigation blocking, discard confirmation, delete confirmation, and custom renderer extension points. The form reads its layout from __ViewDef.config and its field types from __FieldDef — same data, different projection.
The 2026-03-18 refactor replaced six prior form patterns and more than ten ad-hoc dialogs in a single pass. CRUD on the observation surface is a byproduct of one component, not a per-type implementation cost.
MERIDIANThe visual vocabulary
The IOBOXX Meridian design spec governs every page on the surface — both the static twin sites and the live app. The aesthetic is Bloomberg terminal meets Stripe documentation: dark, precise, spacious. Content is the visual; cards and tables earn their space by carrying information.
- Deep navy background (
#030711) — not flat black. The 0.02 blue channel makes it feel like a night sky, not a void. - 3 px teal accent bar on every content card. The single most recognisable Meridian element.
- Red section badges mark page regions — chapter markers.
- Gold for numbers worth reading — KPIs, metrics, monetary values.
- Montserrat at light weight (300) for body, regular (400) for headings. JetBrains Mono for technical labels and section tags.
- Sharp corners — no border-radius. 30 %+ white space on every view.
Canonical reference: architecture-observation-surface-ioboxx-meridian-design-spec.md. Partner twins (ECA, CSP, STI, GOODFORUS) inherit Meridian's structure and override colour tokens via their DigitalTwin Identity object.
ARThe path to AR
The same schema renders on a 375 px phone (column view with dynamic collapse) and a 2,560 px desktop (list, kanban, pivot, graph). The radial navigation menu — concentric rings with scroll-wheel rotation and an embedded chat input — is the bridge from flat screens to spatial interfaces. A glass material system simulates AR-glass optical properties over a live video backdrop, so object cards already render as if they were floating in the wearer's visual field.
Voice is the primary input. AR glasses are the primary output. The flat-screen observation app is the rehearsal stage — the same Object Store subscriptions, the same ViewKinds, the same object cards. When the glasses arrive, the surface does not change shape. It changes viewport.