The problem

AV and IT teams look after hundreds of meeting rooms, desks and shared spaces. The standard for each kind of space usually lives in a document or a slide deck. What is actually installed lives in a spreadsheet, an asset system and the vendor's cloud portals. Nothing connects them, so simple questions are hard to answer:

• Is this space built the way our standard says it should be?
• Which cable goes into which port, and do we have enough outlets behind the display?
• What is being replaced right now, and what is due next year?

The approach

1. Write the standard as data. Each space type lists its build options, the device each option needs, the outlets it needs, and a wiring template that says which port connects to which. Most are based on public industry guidance: AVIXA's display sizing, the Microsoft Teams Rooms and Zoom room sizes, TIA-568 cabling and the manufacturers' own space sizes, with every house assumption marked. The rest are a small house standard for home offices, comms rooms and IT stores.
2. Describe devices from the vendor's own documents. Every one of the 66 models has its size, power and every port, taken from datasheets and manuals. Each was read twice, independently, and the two readings compared field by field. Where a vendor is silent, the model says so under "gaps" rather than guessing.
3. Check it all at build time. Every file is checked against a schema, then cross-checked: does every cable fit the connector at both ends, is any port used twice, are there enough outlets, does every installed unit have a unique serial and asset tag? A mistake stops the build.
4. Show it as a console. The site leads with what to review, then lets you drill from a site to a space to a device and its ports.

How it's built

• The Keia framework underneath. The core vocabulary (space types, device classes, lifecycle stages, the split between a device's role and the physical box) comes from the Keia framework, an open way of describing environments. This console pins one version of it and never edits it; its own ideas sit in extension schemas.
• Data first. Plain YAML files, readable in any editor and reviewable in a pull request, checked by JSON Schema.
• A static site. Astro turns the data into plain HTML at build time. There is no server and no database to run.
• Design tokens. Every colour, size and radius is a token, so the five looks in Settings change tokens only, never components. Studio is the default; Enterprise uses PatternFly token values (MIT).
• Motion with purpose. Pages move by direction with the browser's View Transitions API, drawings and ports morph as you step between models, and switching tabs never moves the page. All of it switches off if your system asks for reduced motion.

The rule book

How Keia Atlas moves, lays out pages, draws devices and spaces, and words things, written down as short numbered rules so anyone adding to it gets the same result.

What's real and what isn't

Device models and their ports are real and public, and the space types rest on public industry guidance, with sources on every page and house assumptions marked. Aigna, its buildings, spaces, people and serial numbers are made up. Buildings are named after native Irish trees and spaces after Irish birds.

Demo dates move with today; the story stays the same. Real facts, such as firmware release dates and when a manufacturer ends support, never move.

What Keia logs about users

What Keia Atlas keeps about the people who use it, what it never keeps, and what the cameras and microphones in Aigna's rooms pick up.

Accessibility

What works with a keyboard, a screen reader, larger text or less motion, how to change it in Settings, and what does not work yet.