The operating system for a laboratory still being built.
An in-development multi-tenant SaaS platform for connecting dental-laboratory cases, people, production, finance, and reporting under one tenant-aware system.
LabOS interface exploration using synthetic demonstration data; it represents product direction, not a claim of completed functionality.Interface view 1 / 1
This exploration shows the intended product surface; it does not prove completed feature coverage.
Synthetic demonstration data
01 / Status
Under development
Foundation work is active
02 / Ownership
Product + platform
Domain · modeling · engineering
03 / Platform
Multi-tenant SaaS
Next.js · PostgreSQL · Prisma
04 / Evidence access
Limited public view
Exploration image · no live tenant data
Build dossier starts here
The foundation is part of the product story.
The next chapters will inspect the dental-laboratory workflow, tenant boundary, authorization model, and the migration work that makes the platform safe to grow.
01 / Domain context
01 / DOMAIN MODEL
The problem is coordination, not another CRUD screen.
A dental laboratory coordinates cases, people, materials, deadlines, money, and communication at the same time. LabOS is being shaped around that operating reality instead of treating each record as an isolated feature.
Before / Product model
One operating picture replaces a stack of disconnected handoffs.
Fragmented work
LabOS direction
01
Case details split across paper, spreadsheets, and messages.
A case becomes the shared operational reference.
02
Staff knowledge and application access are treated as the same thing.
Staff records and application members remain separate, then can be linked deliberately.
03
Production state and deadlines require manual follow-up.
The product is designed to make ownership, stage, and next action visible.
04
Dentists, clinics, finance, and work history sit in separate contexts.
The domain model connects relationships to the work they create.
The connected domain
07 CONNECTED DOMAINS
LabOS is designed around the chain a laboratory already has to manage.
The sequence is a product model and a design test: every new surface should preserve the organization context and clarify what happens next.
01
Cases
The unit of work: patient and restoration context, deadlines, notes, and history.
02
Dentists + clinics
The relationships that originate work and give a case operational context.
03
Staff
People, responsibilities, and assignments—whether or not each person has an account.
04
Production
Stages, queues, assignments, and delivery visibility across the work in progress.
05
Inventory
Materials and stock movements connected to the work that consumes them.
06
Finance
Prices, payments, balances, and financial records protected by separate integrity rules.
07
Reporting
Operational summaries that help a laboratory understand what needs attention.
02 / Trust architecture
02 / TRUST ARCHITECTURE
The product promise depends on boundaries people can trust.
For a multi-tenant laboratory platform, the difficult question is not only what a user can see. It is which organization context, membership, permission, and resource policy must all agree before an action is allowed.
The trust path
Identity enters through the organization. Every domain action stays inside it.
01
Identity
Better Auth verifies the user and session.
02
Organization
Membership supplies the active tenant context.
03
Permission
A fixed role bundle is evaluated with default-deny rules.
04
Resource
The action is checked against the tenant-owned record and its policy.
The intended authorization path keeps authentication, membership, permission, and resource ownership distinct.
Authorization V1 / Decision records
ADR / 001—003
Make the safe path the understandable path.
ADR-001
Active migration
Derive tenant context from verified organization membership.
Why it matters
Loose lab identifiers make it too easy for a request boundary to drift away from the signed-in organization.
Current direction
Use Better Auth Organizations as the canonical membership layer and link the Lab domain entity to it.
What it costs
Every server action must carry and validate context deliberately while legacy paths are migrated.
The brief documents this as the current tenancy migration focus; production isolation results are not claimed here.
ADR-002
Authorization V1
Centralize permissions instead of scattering role checks.
Why it matters
As a product grows, ad-hoc role conditions become hard to audit and can disagree across actions.
Current direction
Use version-controlled role bundles, explicit permissions, centralized evaluation, and default-deny behavior.
What it costs
The policy surface needs design, tests, and migration effort before every module can rely on it.
The current brief names Owner, Admin, Manager, and Staff rules plus resource policies; it does not claim complete rollout.
ADR-003
Domain boundary
Keep a person’s job record separate from their application access.
Why it matters
A laboratory may need to track a technician who does not have a LabOS account—or revoke access without deleting the staff record.
Current direction
Model staff records and application members separately, then link them through explicit invitation and membership flows.
What it costs
Lifecycle operations become more deliberate, but access changes no longer erase domain history or rely on implied roles.
This separation is a stated product and architecture rule in the supplied LabOS brief.
03 / Evidence room
03 / ARTIFACT 001
Show the operating surface. Label the unknowns.
LabOS has one public interface exploration today. It gives the product a visual direction; the registry below keeps the missing proof visible instead of filling the page with invented screens.
LabOS interface exploration with synthetic demonstration data; the visual model is directional, not a completion claim.Artifact 1 / 1
This artifact establishes the intended visual and information-density direction for LabOS.
Capture registry
01 AVAILABLE / 05 REQUIRED
The next screenshot should answer a question.
A credible case study grows by capturing the states that explain the product’s trust model and day-to-day value.
E-01
Organization switcher
Show the active tenant context and how a user knows which laboratory they are operating in.
Capture required
E-02
Members + invitations
Show the distinction between staff records, members, roles, and invitation lifecycle.
Capture required
E-03
Case workflow
Show intake, assignment, production stage, deadline, and the next accountable action.
Capture required
E-04
Permission boundary
Show a safe allowed/denied state without exposing tenant or user data.
Capture required
E-05
Operational reporting
Show how shared domain records become a useful view for laboratory decisions.
Capture required
04 / Engineering ownership
04 / ENGINEERING OWNERSHIP
The hard part is making a SaaS platform safe to grow.
LabOS is being evolved in migration slices: each replacement has to protect tenant boundaries, preserve domain history, and make the next change easier to reason about.
The migration path
Replace ambiguity one boundary at a time.
The sequence keeps the platform reversible while the new rules become trustworthy enough to carry more of the product.
01
Inventory
Classify existing server actions, tenant assumptions, and authorization paths before changing them.
02
Move context
Derive organization scope from verified membership instead of trusting a loose lab identifier.
03
Cut over access
Migrate invitations, membership lifecycle, and staff linking to the organization model.
04
Verify isolation
Test allowed and denied paths, invariants, and legacy removal before widening the cutover.
What the engineering has to protect
The valuable work lives in the boundaries.
C-01
Tenant isolation
A user must not reach another laboratory’s resources by changing an identifier in a request.
C-02
Identity ≠ access
Knowing who a person is, which organization they belong to, and what they may do are separate decisions.
C-03
Membership lifecycle
Invites, revocations, staff links, and departures need explicit rules that preserve history.
C-04
Invariants under pressure
Ownership, financial mutations, and self-service actions need concurrency-safe behavior—not only a role check.
Where I contribute
Domain knowledge becomes platform leverage.
My role spans the translation layer: observing how a laboratory works, modeling the business boundaries, engineering the system, and testing whether the rules hold when the happy path disappears.
01
Observe
Use first-hand dental-laboratory context to identify the handoffs and exceptions worth modeling.
02
Model
Turn those realities into tenant-aware entities, membership boundaries, permissions, and resource policies.
03
Build
Implement the Next.js, PostgreSQL, Prisma, Better Auth, and organization workflows in reversible slices.
04
Prove
Test isolation, lifecycle behavior, and denial paths before calling a foundation dependable.
05 / Current state
05 / CURRENT STATE
A serious foundation is already a product decision.
LabOS is under active development. The current focus is the platform layer that makes future dental-laboratory workflows safe to build on: organizations, tenant context, invitations, staff/member linking, and permission evaluation.
Product status
Under development / work in progress
The direction
From connected records to a laboratory operating system.
The long-term opportunity is not another dashboard. It is one tenant-aware operating picture where cases, relationships, staff, production, inventory, finance, and reporting can reinforce one another.
01
Now / Foundation
Harden organization context, membership lifecycle, Authorization V1, and isolation testing.
02
Next / Workflow
The next credible proof is an authenticated, tenant-scoped workflow: switch organization, move a case, and show an allowed or denied action without crossing the boundary.
03
Later / Operating picture
Connect inventory, finance, reporting, and notifications without losing tenant or permission clarity.
End of build dossier / Start of conversation
Bring me the workflow that has outgrown its tools.
LabOS is the kind of product I want to keep building: domain-heavy, operationally real, and designed so trust is part of the experience—not a patch added after the interface.
