Needs attention 0

Continue working

Activity

Applications

12 applications

Plan & create

Design the environment

Operate

Foundational platforms

Design system

Continue working

Activity

Needs attention

Minerva

Program management & acquisition

Artifex

Engineering

Sibyl

General productivity

Janus

Network infrastructure

Fabrica

Physical & logical environment model

Portus

End-user technology

Terra

Geospatial

Opifex

Operations & logistics

Rubigo

Infrastructure control plane

Sign in to Sigma

or

Preparing sign-in…

Amicus

Federation platform

Application patterns

Minerva

Executive dashboard

Operational overview, chart and data table, confidence display, sample reports and portfolio allocation.

Artifex

Documentation

Reference navigation, reading, bookmarks and in-place page authoring with explicit drafts and publication.

Sibyl

Wiki

Team pages, linked knowledge, page history, discussions and shared in-place authoring.

Sibyl

Chat

Channels, independent message histories, filtering, reactions, drafts and references to work.

Sibyl

Email

Mailbox navigation, message reading, folders, search and non-modal rich-text composition.

Artifex

Workflow

Configurable saved boards, issue details, click and drag moves, column mappings and advisory WIP limits.

Artifex

Code editor

Source navigation, editable buffers, local saves, search, terminal visibility and isolated previews.

Artifex

Forge

Repositories, branches, files, commits, pull requests, review gates and in-place editing.

Review Center · 2026-09-07.3

Modal control room with Identity, Current scenario, Scenario library, Runtime and Evidence; separate non-modal Scenario Guide. Virtual-credential changes end the session without replacing requests. PostgreSQL stores the structured catalog, instances and run evidence. The embedded catalog is read-only preview when dependencies are unavailable.

13 acceptance scenarios and one diagnostic detector. Runtime gates, first-install seeding, stable scenario revisions, and negative credential conditions are explicit. Automated action descriptors use rendered controls and independent SQL/DOM checks. This build’s external QA is not part of scenario-coverage totals.

Sigma / build & design review

Review Center

The implementation, its evidence, and the decisions still being worked through. All included in this HTML.

2026-09-07.2

Contracts and commercial first OA · 2026-09-08.3

Establish supporting contracts through the product workflows, including the first approver for a commercial organization.

Commercial first-OA onboarding

A prospective first OA supplies the proposed contract inside their initial account request. Submission creates a linked contract and appointment request transactionally. The ISO reviews the contract independently, then approves the account and scoped OA appointment. Pending, returned, declined, future-dated, and expired contracts do not authorize account approval. Contract approval alone creates no account or authority.

Contract work

Vesta → Contracts offers drafts, submitted revisions, return and correction, ISO approval or decline, and current availability. An active OA may submit for organizations they represent; a prospective commercial OA has only the narrow permission to submit or correct their own linked proposal. ISO decisions include the actor, relevant authority, and submitted revision. Approved contract details remain read-only.

Approval periods and identity

Commercial initial account sponsorship pins the independent contract approval. Its end date participates in the ISO's maximum-date calculation and is checked again at provisioning and activation. Public user identifiers remain unassigned until provisioning. Account approval, provisioning, and usable OA authority remain distinct. The government initial-operator path is preserved.

Organization abbreviations

Abbreviation is optional. Organization relationships still use a stable identifier. Empty abbreviations neither conflict with each other nor produce an empty line or separator in the directory.

Reusable scenarios

Eight new acceptance scenarios cover the commercial full lifecycle, focused commercial first OA, ordinary OA contract submission, the complete government onboarding foundation, contract return/resubmission, decline, future-dated approval, and failed submission/retry. Twelve new flow records or revisions reuse task-level credential, contract-detail, review, provisioning, and organizational setup behavior. Earlier definitions and runs retain their original revision pins.

Data upgrade

Schema 7 adds independent contract submission and decision records, contract revisions, and identifiers. Opening this release does not reset working data, the loaded scenario, or Evidence. Existing approved reference contracts remain historical records rather than being assigned invented review history. A pending commercial initial-OA request without contract information must be returned for correction; it cannot silently use the government exemption. Previously active accounts are not retroactively revoked by this upgrade.

Verification boundary

The current build QA view identifies actual checks and test environments. The browser workflow harness uses the production charts and SQL repository over a test-only SQLite adapter with direct projection. This does not establish PostgreSQL locking, PGlite durability, or real Datastar delivery. The delivered application retains the real runtime and contains no test-only database or projection adapter. Live scenario Evidence is not prepopulated with build-test results.

Deferred

Approved-contract amendments, renewals, early termination, support withdrawal, routine OA nomination and authority-management workflows remain subsequent increments. Contract registration here is an approved basis for access, not procurement or contract award.

Previous releases (archived)

Organization and first OA · 2026-09-08.2

Replace the next seeded prerequisites with product workflows: registered organizational scope and ISO-sponsored initial OA authority.

The composed journey

Establish an organization and its first OA runs 43 checkpoints. It begins at the existing out-of-band provisioned empty environment, executes the first-ISO commissioning flows, registers the organization through the ISO's Vesta screen, and passes the actual ISO and organization outputs to the candidate's request. The completed world has one organization, one ISO, one active scoped OA, and no contracts or ordinary applicant requests.

Separate decisions and activation

The ISO records account sponsorship and OA appointment as distinct decisions. The account-support date and authority date are explicit, bounded by existing policy and the sponsor's account/authority. A system-authorized provisioning command assigns public identifiers; the candidate then accepts responsibility and activates the account and scoped grant. No authority is conferred by the test-person catalog, the approver hint, submission, or approval alone.

Product surfaces

Vesta → Organizations registers a Government or Commercial organization with its allowed affiliations and shows initial approval coverage. Prospective OAs use Request initial OA appointment and the four-field ISO identity hint. Vesta → Appointments provides a persistent queue, separate sponsorship/appointment confirmations, date helper, return with explanation, decline, and next-request actions. The normal contract-backed account workflow remains intact.

Runtime and preservation

The production path remains Datastar, internal channel/SSE, interpreted commands, and transactional PGlite mapping. New SQL tables hold initial-operator requests, decisions, and provisioning records; scoped grants reuse the authority table. Working data, loaded scenarios, catalog revisions, historical run plans, credentials, and earlier evidence are not reset when this build opens. The original Origo style blocks are retained.

Focused scenarios and evidence

Five focused cases cover the ordinary appointment, return and resubmission, explicit decisions and dates, provisioning rollback/retry, and a wrong ISO hint. Their upstream commissioned state is prepared by command replay, explicitly not credited as earlier UX execution. The full composed journey executes those prerequisites through actual controls. Failed runs keep the guide at the failed checkpoint.

Verification boundary

Build QA distinguishes pure domain checks, production SQLRepository calls over a test-only SQLite driver with direct UI projection, and browser layout/interaction checks. Those do not establish actual PGlite/Datastar execution, production authentication, directory integration, or server security. No test-only database or projection adapter is included in this HTML. See QA evidence for recorded checks and limitations.

Next prerequisite

The newly appointed OA can subsequently submit the first contract for ISO review. Contract authoring, ordinary OA nomination, authority revocation/recovery, policy editing, and operational metrics are outside this revision.

Earlier release information · archived

M2.1 · Vesta runtime integration

2026-09-07.2 · Implementation delivered; real-runtime acceptance is pending.

Implemented path

Existing Vesta controls → genuine Datastar backend actions → scoped MessageChannel/SSE → interpreted application and request transitions → PGlite transactions → committed display projection. The Workroom compiler, transition and actor core and its loader/transport patterns were adapted from the retrieved source. Vesta's chart definitions, relational mapping and storage controls are new.

Working data and scenario data

Saved mode opens an IndexedDB-backed PGlite database under a single-tab ownership lock. Temporary mode is an explicit choice, not an automatic fallback. Working and scenario records have separate SQL data-space keys. Scenario replacement does not replace saved working requests, requirements, feedback or other applications' data. Actor switching is a separate lab operation that continues a request.

Migration and independent evidence

The old Vesta JSON snapshot is imported only into empty working data, with validated identities, request IDs, revisions, history and command receipts. The source is retained. An exact SQL read-back mismatch aborts the import. Export/import and offline-runtime packaging live under Account → Preferences → Access data. Inspect SQL records reads the tables rather than the UI projection cache.

Verification boundary

This build environment could not retrieve the pinned PGlite/Datastar assets. No claim is made that the full database-backed browser journey or offline runtime has passed here. Pure chart/domain tests, an explicitly labeled recording adapter for SQL parameter mapping, and Chromium failure-path checks are separate evidence categories. Check live runtime executes real SQL and a Datastar projection probe after the dependencies load in your browser. M2.1 is not accepted merely because the shell opens.

Scope retained

The ordinary account journey and the existing Origo/Sigma surfaces are preserved. Commit and dropped-projection faults are observable. No CUE/Rego/Lean or Rust compatibility proof, live IdP, server-side authorization, or external directory provisioning is implemented. Events are an audit trail, not full event sourcing. The manual/human-speed/machine-speed scenario runner remains M2.3.

Earlier release notes and evidence

Vesta Access · 2026-09-07.1

Public entry, applicant request, high-volume reviews, and a shared Account / Identity surface.

Included

Public sign-in simulation; three-step request drafting; request status; Organizational Approver and ISO queues with 16 requests; explicit per-request contract support; return/decline notes; provisioning and activation; identity identifiers and expirations; simulated credential enrollment and removal; local cryptographic passphrase generation.

Preserved

The Sigma header, workspace switching, appearance controls, profile-based ranking, attention, feedback and original Origo sources remain. Existing Preferences controls were moved into Account without creating a second implementation.

Scenario preparation

Entry-state loading and actor switching are confined to this optional Review Center. Commands, repository evidence and DOM revisions are observable. Manual/auto-human/auto-machine scenario execution remains the next integration, not a completed feature.

Boundaries

No real account, authentication, hardware key, password verifier, or external provisioning service is created. Provider interactions and credential bindings are labeled local simulations. The passphrase generator performs actual local random generation; phrases are not stored or attached to an account. Website source could not be fetched again during this revision; new interaction rules are identified under Vesta Access.

Previous shared-shell baseline · archived

Shared shell baseline · 2026-09-06.12

Object-row presentation, explicit profile bindings, source-time semantics, and the settled workspace-shell pattern in Origo.

What changed

Home, full collections, universal attention, and Origo specimens now use the same three row variants. The object, action reason, location, and content preview have separate roles. Working text and essential metadata retain their sizes; complete-row fitting determines capacity.

My work and attention use the configured profile's explicit source bindings. Conversation read markers have a profile-specific namespace. Display-name changes do not change authorship; unknown bindings do not silently inherit KS or the seeded mailbox. Existing domain stores remain shared local fixtures, not protected multi-user data.

Activity is a latest-source projection. Only UTC/offset timestamps are treated as dated events. Relative display labels are not converted into invented dates. New chat messages and repository commits record their real creation time; historical sample records remain undated.

Baseline and evidence

The sidebar, identity, header, search, feedback and universal attention controls are retained. The guide and gallery use live shared controls and source-linked rows. Acceptance contracts are independent of Review Center; the QA evidence records external browser checks, not Scenario Lab runs or formal proofs.

Optional review tools

Removing Review Center removes these reports and the review installer, not the shell contracts, source adapters, search, feedback, attention or design-system content.

QA evidence

Evidence setResultSearch checks

Recorded limitations and test boundaries

Complete embedded evidence JSON

Source and porting ledger

2026-09-06.11 · Current change

Outline attention utility, global source count, non-modal panel, stable updates, contextual navigation, and independent removal of Review Center. Current eligibility rules and source records are unchanged.

2026-09-06.9 · Archived change

Header/canvas alignment, compact intrinsic command-strip sizing, Home-only deferred-update placement, and runtime platform shortcut hints. Panel rows, source stores, sidebar measurement and profile accounting remain unchanged.

2026-09-06.8 · Previous change

Removed only the account button’s visible Preferences subtitle. Existing action, accessible name and responsive sizing are retained.

2026-09-06.7 · Previous changes

Profile-scoped launch counters, a single entry-count boundary, settled sidebar ranking and a simplified graphical account control. No changes to the original Origo CSS, source-view content or sidebar-fit measurement algorithm. Complete older records below are historical.

Complete M1 records plus explicit changes for this revision. The older ledger is archived below rather than rewritten as a new historical record.

Changes in 0.1.1

Area	Treatment	Revision
Preview delivery	Adapted	The complete application is losslessly gzip-packed inside this HTML. Expansion requires no network, module import, persistent storage or child iframe. A bundled decoder fallback is included; expanded byte length and completion marker are checked.
Initialization and routing	Hardened	Initialization waits for DOM readiness and is guarded against duplicate entry. Opaque and about: preview documents use the existing session-memory history adapter without attempting to rewrite their embedding URL.
Architecture v9 reader	Repaired	The inaccessible nested iframe is replaced with a style-isolated Shadow DOM reader. The original v9 source string and both SVG figures are retained exactly.
Review Center	Integrated	Release overview, all QA results and limitations, the full porting ledger, formatted notes, and session diagnostics are directly readable in one view. Full original M1 evidence is archived and not presented as fresh revision evidence.
Editor networking	Explicit in previews	The original ProseMirror/Loro setup remains available. An embedded preview does not start downloading editor dependencies until the user explicitly enables setup from Review Center → Runtime. Top-level operation remains on-demand; no substitute editor is introduced.
Product/capability navigation	Discussion only	Record the user’s direction: an Origo authoring/studies surface, a Sigma activity front door, and reusable Sibyl capabilities hosted in product contexts. The M1 one-owner routing remains temporary. This revision does not implement new operational workflows or claim that Workflow belongs only to Artifex.

13Original Origo stylesheet blocks
Unchanged, with additive Sigma styles

10Preserved source views
Eight applications, Origo and gallery

11Registered Sigma products
Names and responsibilities from v9

Source baselines

origo_workspace_v5_2_preview_repaired.html

Full design system and application source · 994,510 bytes

SHA-256 ed528e16fd6d6c0c596897f3bbdd7d206cf069051a7a1f7a21c6219e5d162f1d

sigma_dapmo_product_architecture_v9(1).html

Authoritative product names and boundaries · 39,176 bytes

SHA-256 e865a28b145e913859f24426b5f59e92aa822213294b69c9d53a2edd3be0a0e8

Source preservation and integration changes
Area	Treatment	What changed — and what did not
Origo visual system	Preserved	All 13 source stylesheet blocks are byte-for-byte unchanged. The MIT notice in the embedded AmbientCSS core is retained. Sigma styles are added in a separate, scoped block.
Design guide	Preserved	The full original guide, its section navigation, surface studies, implementation contracts, handoff checklist and dynamically inserted authoring guidance remain in the document.
Gallery and studies	Preserved	Existing primitive demonstrations, structural checks, theme/lighting controls, curated palettes, scene presets, import/export, entity pickers and collaborative workbench are retained.
Eight application concepts	Preserved	Original markup and domain behavior remain. Sidebar visibility, shell labels and product-aware routes are integration changes; sample repository names and illustrative data are not globally renamed.
Product registry	Added	All 11 product names, groupings, domains and responsibilities come from v9. Card summaries paraphrase v9. Temporary monograms and prototype placement are M1 decisions, not approved product branding or new whitepaper claims.
Home and product landing pages	Added	A launcher, capability search, product switcher, recent-object list and honest architecture-only states. No generated operational metrics or simulated service health.
Navigation adapter	Adapted	Product-prefixed routes coexist with legacy Origo hashes. Browser/session-history fallback, object links, scroll restoration and existing authoring-exit behavior are retained.
Appearance compatibility	Adapted	The existing Origo appearance schema is retained. Original ten-surface presets receive defaults for new Sigma surfaces; exported presets include those new surfaces.
Whitepaper v9	Embedded	The entire supplied HTML is stored intact in the document, including both SVG figures and source references. The reader now uses a style-isolated Shadow DOM surface, without a nested browsing context. Heading targets and external-link handling do not alter the embedded original.
Offline authoring export	Adapted	The existing offline builder exports the combined Sigma document under a descriptive Sigma filename after the real editor runtime loads. It does not bundle browser-local user content.
Storage	Preserved / added	Origo data remains under its original storage keys. Sigma keeps only launcher history in its own namespace. Storage availability is detected; this is not a backup, migration or multi-user synchronization system.
Scenario Lab / cost model	Not integrated	M2 and M3 respectively. No substituted runner, new numerical model or fake passing scenario is presented in M1.

M1 structure checks

Inspect this document. These checks are not Scenario Lab, a usability audit or formal verification.

Not run in this session. Checks cover registry, retained views, unchanged styles, source embedding and navigation bindings.

Milestone sequence

M1 / this build

Origo foundation

Preserve the source; establish Sigma Home and v9 product boundaries.

M2 / planned

Scenario Lab

Port the existing runner and connect real UX to candidate requirements.

M3 / planned

Minerva planning

Port the substantial PGlite cost model and its time-based planning experience.

M4 / planned

Requirements curation

Author, review and version acceptance criteria and execution evidence.

M5 / planned

Cross-product workflow

Exercise one coherent handoff through normal product actions.

Complete current ledger JSON

Original M1 ledger · full archive

Contracts and commercial first OA · 2026-09-08.3

Establish supporting contracts through the product workflows, including the first approver for a commercial organization.

Commercial first-OA onboarding

A prospective first OA supplies the proposed contract inside their initial account request. Submission creates a linked contract and appointment request transactionally. The ISO reviews the contract independently, then approves the account and scoped OA appointment. Pending, returned, declined, future-dated, and expired contracts do not authorize account approval. Contract approval alone creates no account or authority.

Contract work

Vesta → Contracts offers drafts, submitted revisions, return and correction, ISO approval or decline, and current availability. An active OA may submit for organizations they represent; a prospective commercial OA has only the narrow permission to submit or correct their own linked proposal. ISO decisions include the actor, relevant authority, and submitted revision. Approved contract details remain read-only.

Approval periods and identity

Commercial initial account sponsorship pins the independent contract approval. Its end date participates in the ISO's maximum-date calculation and is checked again at provisioning and activation. Public user identifiers remain unassigned until provisioning. Account approval, provisioning, and usable OA authority remain distinct. The government initial-operator path is preserved.

Organization abbreviations

Abbreviation is optional. Organization relationships still use a stable identifier. Empty abbreviations neither conflict with each other nor produce an empty line or separator in the directory.

Reusable scenarios

Eight new acceptance scenarios cover the commercial full lifecycle, focused commercial first OA, ordinary OA contract submission, the complete government onboarding foundation, contract return/resubmission, decline, future-dated approval, and failed submission/retry. Twelve new flow records or revisions reuse task-level credential, contract-detail, review, provisioning, and organizational setup behavior. Earlier definitions and runs retain their original revision pins.

Data upgrade

Schema 7 adds independent contract submission and decision records, contract revisions, and identifiers. Opening this release does not reset working data, the loaded scenario, or Evidence. Existing approved reference contracts remain historical records rather than being assigned invented review history. A pending commercial initial-OA request without contract information must be returned for correction; it cannot silently use the government exemption. Previously active accounts are not retroactively revoked by this upgrade.

Verification boundary

The current build QA view identifies actual checks and test environments. The browser workflow harness uses the production charts and SQL repository over a test-only SQLite adapter with direct projection. This does not establish PostgreSQL locking, PGlite durability, or real Datastar delivery. The delivered application retains the real runtime and contains no test-only database or projection adapter. Live scenario Evidence is not prepopulated with build-test results.

Deferred

Approved-contract amendments, renewals, early termination, support withdrawal, routine OA nomination and authority-management workflows remain subsequent increments. Contract registration here is an approved basis for access, not procurement or contract award.

Previous releases (archived)

Organization and first OA · 2026-09-08.2

Replace the next seeded prerequisites with product workflows: registered organizational scope and ISO-sponsored initial OA authority.

The composed journey

Establish an organization and its first OA runs 43 checkpoints. It begins at the existing out-of-band provisioned empty environment, executes the first-ISO commissioning flows, registers the organization through the ISO's Vesta screen, and passes the actual ISO and organization outputs to the candidate's request. The completed world has one organization, one ISO, one active scoped OA, and no contracts or ordinary applicant requests.

Separate decisions and activation

The ISO records account sponsorship and OA appointment as distinct decisions. The account-support date and authority date are explicit, bounded by existing policy and the sponsor's account/authority. A system-authorized provisioning command assigns public identifiers; the candidate then accepts responsibility and activates the account and scoped grant. No authority is conferred by the test-person catalog, the approver hint, submission, or approval alone.

Product surfaces

Vesta → Organizations registers a Government or Commercial organization with its allowed affiliations and shows initial approval coverage. Prospective OAs use Request initial OA appointment and the four-field ISO identity hint. Vesta → Appointments provides a persistent queue, separate sponsorship/appointment confirmations, date helper, return with explanation, decline, and next-request actions. The normal contract-backed account workflow remains intact.

Runtime and preservation

The production path remains Datastar, internal channel/SSE, interpreted commands, and transactional PGlite mapping. New SQL tables hold initial-operator requests, decisions, and provisioning records; scoped grants reuse the authority table. Working data, loaded scenarios, catalog revisions, historical run plans, credentials, and earlier evidence are not reset when this build opens. The original Origo style blocks are retained.

Focused scenarios and evidence

Five focused cases cover the ordinary appointment, return and resubmission, explicit decisions and dates, provisioning rollback/retry, and a wrong ISO hint. Their upstream commissioned state is prepared by command replay, explicitly not credited as earlier UX execution. The full composed journey executes those prerequisites through actual controls. Failed runs keep the guide at the failed checkpoint.

Verification boundary

Build QA distinguishes pure domain checks, production SQLRepository calls over a test-only SQLite driver with direct UI projection, and browser layout/interaction checks. Those do not establish actual PGlite/Datastar execution, production authentication, directory integration, or server security. No test-only database or projection adapter is included in this HTML. See QA evidence for recorded checks and limitations.

Next prerequisite

The newly appointed OA can subsequently submit the first contract for ISO review. Contract authoring, ordinary OA nomination, authority revocation/recovery, policy editing, and operational metrics are outside this revision.

Earlier release information · archived

2026-09-07.4 · Credential binding

The Identity selector now reads credentials from the current Vesta identity rather than substituting catalog defaults. Earlier first-signup references are retained; no requests, decisions or account records are reset or rebound.

Identity and the virtual credential check use the same validation. Invalid inputs remain blocked, with a direct Choose another credential action on the bridge. Reload the selected credential once to replace an older virtual selection; a scenario reset is not required.

Build QA below distinguishes production code exercised with controlled fixtures from the still-unverified PGlite/Datastar integration. Earlier run evidence is retained under its original build.

M2.1 · Vesta runtime integration

2026-09-07.2 · Implementation delivered; real-runtime acceptance is pending.

Implemented path

Existing Vesta controls → genuine Datastar backend actions → scoped MessageChannel/SSE → interpreted application and request transitions → PGlite transactions → committed display projection. The Workroom compiler, transition and actor core and its loader/transport patterns were adapted from the retrieved source. Vesta's chart definitions, relational mapping and storage controls are new.

Working data and scenario data

Saved mode opens an IndexedDB-backed PGlite database under a single-tab ownership lock. Temporary mode is an explicit choice, not an automatic fallback. Working and scenario records have separate SQL data-space keys. Scenario replacement does not replace saved working requests, requirements, feedback or other applications' data. Actor switching is a separate lab operation that continues a request.

Migration and independent evidence

The old Vesta JSON snapshot is imported only into empty working data, with validated identities, request IDs, revisions, history and command receipts. The source is retained. An exact SQL read-back mismatch aborts the import. Export/import and offline-runtime packaging live under Account → Preferences → Access data. Inspect SQL records reads the tables rather than the UI projection cache.

Verification boundary

This build environment could not retrieve the pinned PGlite/Datastar assets. No claim is made that the full database-backed browser journey or offline runtime has passed here. Pure chart/domain tests, an explicitly labeled recording adapter for SQL parameter mapping, and Chromium failure-path checks are separate evidence categories. Check live runtime executes real SQL and a Datastar projection probe after the dependencies load in your browser. M2.1 is not accepted merely because the shell opens.

Scope retained

The ordinary account journey and the existing Origo/Sigma surfaces are preserved. Commit and dropped-projection faults are observable. No CUE/Rego/Lean or Rust compatibility proof, live IdP, server-side authorization, or external directory provisioning is implemented. Events are an audit trail, not full event sourcing. The manual/human-speed/machine-speed scenario runner remains M2.3.

Earlier release notes and evidence

Vesta Access · 2026-09-07.1

Public entry, applicant request, high-volume reviews, and a shared Account / Identity surface.

Included

Public sign-in simulation; three-step request drafting; request status; Organizational Approver and ISO queues with 16 requests; explicit per-request contract support; return/decline notes; provisioning and activation; identity identifiers and expirations; simulated credential enrollment and removal; local cryptographic passphrase generation.

Preserved

The Sigma header, workspace switching, appearance controls, profile-based ranking, attention, feedback and original Origo sources remain. Existing Preferences controls were moved into Account without creating a second implementation.

Scenario preparation

Entry-state loading and actor switching are confined to this optional Review Center. Commands, repository evidence and DOM revisions are observable. Manual/auto-human/auto-machine scenario execution remains the next integration, not a completed feature.

Boundaries

No real account, authentication, hardware key, password verifier, or external provisioning service is created. Provider interactions and credential bindings are labeled local simulations. The passphrase generator performs actual local random generation; phrases are not stored or attached to an account. Website source could not be fetched again during this revision; new interaction rules are identified under Vesta Access.

Previous shared-shell baseline · archived

2026-09-06.12 · Shared shell baseline

Presentation

Attention rows separate the object title, outstanding reason and context. Continue working includes the recorded last-opened time and draft flag. Activity uses event titles instead of bold message bodies, with separate excerpts and actor/context metadata. All row icons use an 18px outline with consistent stroke. Final visible rows no longer double the footer separator.

Source meaning

Profile/source bindings are declared in the local configuration. An explicit authorProfileId or assigneeProfileId takes precedence over legacy bindings. The mailbox binding describes the existing local mailbox, and team-attention opt-in describes the existing local engineering queue. None of this grants authorization. Existing unscoped conversation read markers are not attributed to a user; the new profile-specific markers start fresh.

Activity rows with complete ISO timestamps sort ahead of undated snapshots. Time-only and relative strings are retained as source labels in tooltips, not interpreted as dates. No sample timestamp is fabricated. Activity remains a source snapshot rather than a complete history.

Origo

The new Workspace shell guide and gallery family exercise the same global controls and row renderer used in working applications. The twelve previously curated design areas and all thirteen original stylesheet blocks are preserved.

Limits

Scenario Lab is not yet integrated. Shared criteria are candidate acceptance contracts, with external browser evidence separately recorded. Native ChatGPT preview, native downloaded-file persistence and optional ProseMirror/Loro dependency success require their own environment checks. The new source bindings do not migrate all legacy domain data into a protected multi-user architecture.

Earlier release notes

2026-09-06.11 · Universal needs attention

The outline bell and its count are a permanent header utility immediately left of feedback. The total is drawn from the same source projection as Sigma Home and is not scoped to the active workspace or filter. The compact panel exposes All, Action needed and Unread with source links and the existing full queue.

Inspecting the panel never acknowledges or completes work. Source state changes update the badge; hovered or keyboard-focused rows wait for an explicit refresh. Closing returns focus, following work uses the normal route path, and mobile content behind the full-width panel is temporarily removed from keyboard navigation. Search and feedback do not stack over attention, and feedback drafts survive switching.

No remote notification feed or operating-system notifications are connected. This revision retains the existing local attention eligibility rules, including the seeded user, sample pipeline subscriptions and pending reviews. It does not introduce production authorization, recipient routing, or notification-event deduplication.

Current tests are scoped to this revision. Original Origo styles, sidebar sizing, launch accounting, source stores, search semantics and dashboard panels are retained. The small feedback hover treatment now matches the new outline utility.

2026-09-06.10 · Archived release notes

2026-09-06.10 · Workspace search & feedback

Search titles, saved body content, messages, files, work items, and Origo guidance. Private drafts are excluded. New matches are resolved from current records rather than a copied dashboard list. Product scope is explicit; a shared capability retains its host context.

Search routes preserve the query and scope. Search-only transitions do not manufacture product launches or overwrite the last working object. Existing body renderers, datasets, appearance machinery and sidebar fitting are retained.

Feedback drafts and local records are profile-keyed. Failed persistence is disclosed as session-only. A captured context never follows subsequent navigation silently. Saved history and export remain usable after Review Center is removed.

The source dataset has no full authorization model. Search association fixtures are not permission enforcement. Successful rich-editor loading and the native ChatGPT app remain separate environment checks.

2026-09-06.9 · Archived release notes

2026-09-06.9 · Dashboard framing

Priority 4, framing only. Panel information hierarchy is deliberately deferred.

Search now aligns with the bounded Home canvas, including centered ultrawide layouts. The empty leading desktop header cluster and the static “Your workspace” label no longer consume space. The section tabs remain on narrow and shallow Home layouts.

The global header has a 56px minimum with a fine pointer, or 60px with a coarse pointer. Search retains its 40px/44px minimum target and existing font size. Intrinsic header height is measured and shared with content surfaces when text needs more space.

The existing updates control appears in the header only when Home has a deferred update. It does not shift the panel rows under the pointer. Search advertises Ctrl K or ⌘ K according to the runtime platform; modified browser/debug shortcuts and text composition are not intercepted.

Current checks are scoped to these changes and relevant regressions, not a full rerun of all earlier releases. The native app preview and optional external editor runtime require separate verification.

2026-09-06.8 · Archived release notes

2026-09-06.8 · Account control

Label-only refinement.

The account button now displays only the avatar and profile name. Preferences remains the click/keyboard action and is retained in the tooltip and accessible name. The accepted layout and launch accounting are unchanged.

2026-09-06.7 · Archived release notes

2026-09-06.7 · Profile launches & account

Priority 3 only. The dashboard, header, width, workspace identity and measured-fit algorithm remain unchanged.

Launch accounting

One entry into a different application through normal navigation counts once, after successful route restoration. A sidebar shortcut has one delegated input path. Selector, directory, search, resumption and attention links use the same accounting boundary. Origo is included. Local views, reloads, history restoration, invalid routes and Preferences/Review detours are not additional launches.

Counter shards are keyed to the configured stable profile ID and open document instance. Tabs do not overwrite each other’s counters. Display names are not keys. Unscoped legacy counts are retained but not assigned to any profile: corrected ranking starts fresh. Equal counts sort alphabetically. The visible order settles on entry into Sigma; rendering, resizing and other-tab storage events cannot reshuffle it while choosing an application.

Account control

A neutral inline profile icon, full name and the short Preferences label replace initials plus a clipped subtitle. Click or keyboard activation opens Preferences directly. The compact rail retains the icon and an accessible name. No extra menu or remote image request is used.

Boundaries

The current HTML has one configured local profile. This release does not introduce sign-in, account switching, authorization or cross-device synchronization. Two-profile verification uses isolated configuration fixtures against the same storage. Only launch personalization is newly profile-scoped; domain data, authoring identity and other preferences retain their existing single-user model. When local storage is unavailable, launches remain in memory and Preferences reports the limitation.

2026-09-06.6 · Archived release notes

2026-09-06.6 · Workspace identity

Priority 2 only: distinguish switching from identity.

Changed

The selector uses a stable Sigma mark and Workspaces label in every application. The name/version block is non-interactive, without border, fill, shadow, hover or an extra keyboard stop. The Home route label is shortened and redundant workspace-name captions are suppressed. A compact monogram prevents narrow-rail truncation; full names and versions remain in the accessible description.

Preserved

The sidebar-fit controller, ranking, profile storage, account, header and product content are retained. All previous QA records remain historical evidence. Optional Review Center export remains available.

2026-09-06.5 · Archived release notes

2026-09-06.5 · Measured sidebar fit

Priority 1 only: complete-row fitting; reserved directory/account controls; keyboard-safe resize and explicit extreme-height fallback. Current evidence is under QA. Older notes below are historical.

M1.2 — Products, shared capabilities & a dedicated Origo surface

Build 0.1.2. This is a navigation and integration release; M2 Scenario Lab and M3 cost planning remain deferred.

Implemented

Sigma Home now projects attention and activity from the existing application state. Product switching resumes working locations; product overviews are separate destinations. Origo contains the full guide, gallery, Theme Lab, Lighting Lab and concept library. Basic appearance selection remains in preferences.

Wiki, email, chat and workflow can render in a host product without redirecting the user into Sibyl. Artifex, Opifex and Sibyl use the same workflow board and inspector, with explicit domain profiles. A personal work queue shows references to assigned work, not copies.

Integration findings resolved

Drag-and-drop now observes the same illustrative completion rule as the status picker. Dismissed entity pickers cannot leave delayed outside-click listeners that close a newer picker. Navigation preserves working input focus and selection instead of replacing them with the global toolbar focus. QA evidence records the exercised paths and distinguishes blocked or unverified environments.

Preserved and adapted

The thirteen original Origo style blocks, original guide, gallery, repository, communication, authoring and application content are retained. The original theme and lighting control nodes are moved into the Origo surfaces, not recreated. The v9 source and all prior review evidence remain embedded.

New sample data

The original twelve engineering work items retain their identifiers. Two personal and two operational sample items were added to exercise context-specific workflow; their provenance is recorded in the ledger. No real IT operations or messaging service is connected.

Evidence boundaries

See QA evidence for the exact current-run checks and environment. In-app candidate requirements are not approved requirements or formal proofs. Read receipts and home activity are local projections. Product context is not a security boundary.

Known limits

The rich authoring dependencies remain pinned and on-demand. Browser-local data is not bundled into HTML source exports. Native ChatGPT app preview execution requires a user-side check. Cross-product links do not implement authorization or federation.

Previous M1.1 release notes (archived)

Original M1 notes · exact Markdown archive

This browser session

Live diagnostics, separate from the recorded build tests. Copy these details when reviewing a preview-specific problem.

Authoring setup

The shell and all reading surfaces start without external requests. The original ProseMirror/Loro authoring implementation can load its pinned dependencies on demand. In an embedded preview, explicitly enable that setup here; the host may still request or deny network access.

No replacement editor is used when setup is unavailable. Enabling setup does not send your document content to a model or external service; it requests the editor libraries.

Runtime and portability

Loading runtime details…

No new network dependency on startup. The launcher, design system, gallery, concepts and whitepaper are embedded. Rich-text authoring retains the pinned ProseMirror/Loro setup. In embedded previews, explicitly enable downloads under Runtime before using it. The inherited offline builder requires those libraries to load successfully; it exports the full application but not the local content database.

Complete session diagnostics

Navigation & shared capabilities

M1.2 implementation decisions, distinct from the v9 architecture. These requirements are candidates; no Scenario Lab has been integrated yet.

Product ≠ capability ≠ object

A product supplies the working context. Sibyl supplies reusable communication, knowledge and workflow experiences. The work item retains its accountable domain and rules wherever it is presented.

Candidate UX requirements

Inspect this session

Migration boundary

The existing Origo renderers, editor, appearance engine and domain data remain in place. New context adapters surround them. The workflow profiles in this revision are lightweight JavaScript guards—not the planned CUE/policy calculus, a verified statechart interpreter, or production authorization.

M2.1 · Runtime & database

Datastar 1.0.3 → scoped MessageChannel / SSE → Workroom’s exclusive statechart interpreter → PGlite 0.5.8. The existing Vesta screens remain the working interface. No scenario runner is claimed here.

Working and scenario records use separate SQL data-space keys. Loading a fixture replaces only the scenario data space. Participant switching retains the same request; it is a development control, not authentication. New browser sessions reopen working data.

Import previous records before starting a new working request. Import never overwrites a nonempty working data space.

Not run in this browser.

Independent SQL evidence

Open the runtime, then inspect the database. There is no substitute SQL adapter.

Current runtime and storage state

Interpreted chart definitions

Effects execute on the browser thread behind the channel boundary; there is no worker, Rust service or server-side authorization here. The event table is an audit trail, not a full event-sourcing proof. A single database owner is enforced for saved storage.

Vesta Access · Entry states

Prepare a local starting point, then use the real product controls. These are fixtures and inspection tools, not an automated scenario runner.

Continue the same workflow as another participant

Switching the fixture actor is a privileged lab action, not authentication. It preserves the requests and handoff history. Return here with Ctrl / Command + Shift + L.

Participant

Current sandbox

Displayed projection cache (not an independent SQL read)

Adversarial controls

These controls affect only Vesta Access. A dropped projection is an intentional defect; a successful command is not evidence that the screen is correct.

Source and implementation boundary

The lifecycle captured in the prior read-only Vesta Lab review is retained: identity evidence, draft, organizational review, ISO review, approval, and activation after provisioning. ISO contract-support disposition remains explicit. The hosted lab did not respond to fresh reads on September 7, 2026; its Rust statechart, guards, and templates were not available for a source-code port.

Queue interaction, the synthetic Northstar fixture population, return/decline rules, credential confirmation simulation, and the two-step provisioning representation are UX implementation choices in this document. They are not attributed to uninspected source semantics. Invitation binding, accountability handoff, and privileged-access nomination are not implemented in this pass.

Vesta runs a versioned local command/repository/projection adapter. It now uses PGlite and the ported Workroom interpreter behind real Datastar SSE. It does not run the hosted lab’s Rust interpreter, CUE/Rego guards, or a real identity provider. Data in a client-only file is not protected by production authorization. All provider and credential bindings are visibly simulated; the passphrase generator uses real browser cryptographic randomness with a curated 1,050-word vocabulary.

Scenario Lab integration contract

The Scenario Testing POC separates fixture setup, pure domain decisions, repository effects, rendered projections, and independent assertions. Preserve that separation when adding manual, human-speed, and machine-speed execution. All execution modes must use the same DOM actions and checkpoints. No run is claimed by loading a fixture.

Commands have stable IDs, expected request revisions, actor IDs, and reset epochs. Domain rejection leaves records unchanged. A transaction-callback failure requests rollback. A transport or durability interruption may have an uncertain outcome; reload SQL state before retrying. Fixture reset increments the epoch. Inspect request and repository revision attributes in the DOM independently of VestaAccess.repository(). Generated passphrases are excluded from stored state, command logs, and snapshots.

The SQL reset boundary is the Vesta scenario data space only; saved working requests are separate. Review evidence, requirement curation, appearance, feedback, and the other product data must survive. One workflow can switch actor repeatedly without resetting its request.

First-signup manual exercise

Load First contact. Continue with CAC / PIV and confirm the demonstration identity. On the request, use Northstar Program Office and morgan.reyes@example.org as routing. Add a work purpose and future requested end date, then submit. Use Ctrl / Command + Shift + L to open the same workflow as Morgan, then Rowan, then Casey. Do not reload a fixture between actors. Return as Jordan to inspect activation and Identity.

Portfolio value

$12.8M

↗ 8.4%vs. prior period

Milestones complete

87.6%

↗ 3.1%42 active initiatives

Spend efficiency

94.2%

↗ 1.8%$412K variance

Open risks

14

↘ 2 critical4 need decision

Delivery performance

Weighted milestones completed · % of planned work

Actual completionPlanned baseline

Sample data · Focus the chart, then use ← / → to inspect points.

View data as a table

Completion and baseline for the selected period
Date	Actual	Baseline	Difference

Portfolio health

Composite confidence score

83/100

Schedule91%

Cost88%

Risk readiness74%

Executive signals

Items worth attention today

Delivery confidence improvedFive programs moved above their baseline trajectory this week.

Two decisions are agingArchitecture and procurement gates are now above 10 business days.

Priority initiatives

Highest-impact programs in the current operating window

Program	Owner	Health	Next gate
NX Nexus modernizationPlatform transformation	R. Chen	On track	Sep 12
AI AI enablementEnterprise capability	M. Patel	On track	Sep 18
DC Data convergenceInformation architecture	A. Brooks	Watch	Sep 09
CX Client experienceService redesign	S. Ortiz	On track	Sep 24

Portfolio allocation

FY27 planned investment by mission area

Platform41%

Data & AI25%

Experience17%

Operations17%

System architecture

A layered platform architecture that keeps product experiences independent while sharing identity, policy, event, and data capabilities underneath.

Approved Architecture decision 014 8 minute read • 6 contributors

✦

Design intent

Each workspace surface can feel purpose-built without fragmenting the underlying product. Shared services provide continuity; local components preserve task focus.

Overview

The experience is organized around a common application shell and a set of bounded workspaces. Dashboard, knowledge, communication, workflow, and development surfaces all consume the same identity, authorization, search, and event backbone.

The result is a cohesive product family rather than a collection of embedded tools. Users retain consistent navigation and lighting cues while the information density and interaction model adapt to the work at hand.

Unified application shellNavigation · identity · search · notifications

ObserveDashboards

UnderstandKnowledge

CoordinateChat & mail

DeliverWorkflow & code

Shared platform servicesPolicy · events · data · automation · audit

Experience boundaries

Workspace boundaries should be visible but not disruptive. Navigation state, global actions, notifications, and lighting remain stable. Toolbars, content layout, and local interactions change according to the work surface.

interface WorkspaceSurface {
  id: "dashboard" | "docs" | "chat" | "mail" | "workflow" | "code";
  shell: "shared";
  density: "calm" | "standard" | "dense";
  primaryAction: Action;
  capabilities: Capability[];
}

Governance

Shared tokens define contrast, spacing, typography, state, and semantic elevation. AmbientCSS then renders those semantic decisions through a coherent material and lighting model rather than becoming the source of the UX semantics itself.

# portfolio-ops28 members · Portfolio delivery and decisions

14 online

Today

MP

Maya Patel9:18 AM

The September 18 readiness review is still on the calendar, but the identity cutover has slipped by two days. Alex, can the notification change be reviewed independently, or do we need to move the gate?

AL

Alex Li9:24 AM

The notification service can ship independently. **OPS-148** is in review; the remaining decision is who owns retries after the third attempt. I recommend Operations owns the queue, with Engineering on call for poison messages.

OPS

OPS-148 · Decouple notification serviceIn review · Alex Li · 5 points

✦

Decision summary available

Aperture captured three decisions and two follow-up actions from yesterday’s readiness session.

RC

Robin Chen9:41 AM

The ownership split works for me. Please add the queue alert threshold to the rollback checklist before Thursday. The load-test evidence is attached below: readiness-evidence_notification-retries_us-east_2026-09-04_final-reviewed.csv

KS

Kyle Stewart10:02 AM

Keep the review on September 18. Maya owns the gate decision; Alex owns the retry policy. Leave the item **In review** until the alert is exercised. Can someone confirm who will run that test?

Messages stay in this browser

Enter to send · Shift+Enter for a new lineBold, code, lists & quotes

Inbox

Priority inbox6 unread · 24 messages

⌘K

Executive · Programs

Readout: modernization readiness review

MP

Maya Patelto Kyle Stewart, Portfolio Leadership

Today, 10:32 AM

Kyle,

Leadership aligned on the proposed MVP path during this morning’s readiness review. The portfolio remains healthy overall, and the schedule and cost posture support proceeding with the next decision gate.

Composite83

Schedule91%

Risk74%

Three decisions were confirmed: retain the shared application shell, treat the event backbone as a platform capability, and sequence the first workload migration behind the identity boundary validation.

The remaining risk is bounded: close OPS-148 and complete the service-boundary validation before the production readiness review.

I’ve attached the leadership readout and the action register. Please reply with any corrections before 1500 so we can publish the final record.

— Maya

PDF

readiness-readout.pdf2.4 MB · 12 pages

XLSX

action-register.xlsx184 KB · 14 actions

Sprint 18 · Platform runway34 of 50 points complete · ends in 6 days

68%

Backlog3

OPS-156◇

Map transition evidence to the release gate

securityautomation

Medium 23 ptsKS

OPS-161□

Add dependency visualization to portfolio detail

dashboarddata

Low5 ptsRC

OPS-164◇

Define retention policy for linked conversation decisions

governance

Medium2 ptsMP

In progress4

OPS-148□

Decouple notification service from workspace clients

platformarchitecture

High 75 ptsAL

OPS-151◇

Implement adaptive density for documentation

experienceresponsive

Medium3 ptsRC

OPS-153□

Connect unified search to the command palette

platformsearch

Medium5 ptsKS

OPS-154◇

Link email commitments to work items

mailworkflow

Low3 ptsMP

Review3

OPS-146□

Workspace shell keyboard and accessibility pass

shella11y

High33 ptsRC

OPS-149◇

Calibrate material response across light presets

design system

Medium3 ptsAL

OPS-150□

Refine portfolio health depth and responsive layout

dashboardvisual

Low2 ptsRC

Done2

OPS-141◇

Establish shared application shell and navigation

shell

Complete8 ptsAL

OPS-143◇

Define semantic elevation and surface tokens

design system

Complete5 ptsRC

src›app›app-shell.tsxfeature/workspace-surfaces

Saved locally

import { createRoot } from "react-dom/client";
import { WorkspaceShell } from "./components/workspace-shell";
import { surfaces } from "./workspace-registry";
import "./surface.css";
 
export interface SessionContext {
  userId: string;
  organizationId: string;
  capabilities: readonly string[];
}
 
const session: SessionContext = {
  userId: "kstewart",
  organizationId: "aperture",
  capabilities: ["portfolio.read", "workflow.write", "code.run"],
};
 
function Application() {
 const enabledSurfaces = surfaces.filter((surface) =>
    surface.required.every((capability) =>
      session.capabilities.includes(capability)
    )
  );
 
 return (
    <WorkspaceShell
      session={session}
      surfaces={enabledSurfaces}
      defaultSurface="dashboard"
      lighting={{ x: -0.72, y: -0.70, key: 0.76, fill: 0.56 }}
    />
  );
}
 
createRoot(document.getElementById("app")!).render(<Application />);

Aperture local source workspace

Edit and save files locally. CSS previews render in an isolated frame.

TypeScript / TSX are source snapshots; no compiler or server is connected.

Aperture / Engineering

workspace-shell Internal

Content

The Origo interaction contract

Quiet content. Tangible action.

01 / InformationRelease window

Tuesday, 15 September
09:00–11:00 UTC

Flat. Readable. No hover response.

02 / Interaction

Hover, focus, or press. The light belongs to the control.

A raised edge invites. A pressed edge confirms.

Rest visible edgeHover / focus nearer + brighterPress lower + tighterDisabled quiet + stationary

State contracts

The same controls used in the workspace, with complete behavior and difficult content.

Action states

Default, interaction and unavailable states

control.button

Default

Hover · visual specimen

Pressed · visual specimen

Keyboard focus · visual specimen

Disabled

A reviewer must be assigned first.

Loading → success · interactive

Save to exercise the pending state.

Persistent hover, pressed and focus appearances above are labeled specimens. Tab through the actual buttons to test real keyboard focus.

Field validation

Label, help, error and confirmation

control.field

Read-onlyReference ID

Readable and selectable, but not editable.

Content states

Make the next step explicit

feedback.content

Loading · visual specimen

Keep the region’s shape stable while content is pending.

Unavailable → recovered · interactive

! The preview is unavailable. Your draft is still here.

Choose “No records” in the content selector to test the table’s empty state and disabled bulk-selection control.

Meaning without color

Labels accompany every signal

feedback.status

Success✓ Evidence reviewed

Warning! Review overdue

Blocked× Owner required

No value— Not recorded

Zero is a value; “not recorded” is missing data. Do not use the same visual treatment or wording for both.

No primitives match that filter.

Actions

Controls that initiate, confirm, or change work.

Use depth to signal pressability

ButtonsPrimary, secondary, quiet, and destructive

Icon actionsCompact tools with clear selected state

Inputs

Data entry and choice controls with restrained physical cues.

Recess fields; raise manipulators

Text and selectionDefault field, search, and select patterns

Project nameRequired Environment⌄

Choice controlsBinary, exclusive, and segmented selection

Include archived items Enable live updates

Density

Feedback

Progress, system state, and compact status communication.

State must remain legible without color

Linear progressRecessed track with a lightly raised indicator

Migration

68%

Radial and statusCompact summary plus semantic state labels

72%complete

On trackWatchBlockedReviewKSMPAL

Surfaces

The small physical vocabulary used to build larger products.

Start matte; add energy deliberately

Surface hierarchyRaised, planar, and inset regions

RaisedInteractive

PlanarReading

InsetContainment

CalloutsContained emphasis without excessive elevation

i

Design intent

Use a tonal boundary and one semantic accent. Do not add elevation unless the callout can move or receive input.

Navigation & disclosure

Reveal the right amount of information, in place.

Three new interactive families

Accordion NewNative disclosure, keyboard included

What belongs on a raised surface?

Independent, manipulable objects. Keep dense text planar and reserve more pronounced edges for controls.

When should content be recessed?

Use a well to suggest containment: a chart plot, input field, or a track that holds a moving indicator.

Can I reduce the depth?

Open Lighting lab and choose Quiet for this tab. The same information and controls remain available.

Content tabs NewOne selection, a meaningful content change

Action menu NewA floating layer above a quiet field

Data & sequences

Two useful patterns for everyday business workflows.

State is visible, not just announced

Data table NewSort columns and select rows

0 of 3 selected

Step-by-step flow NewValidation, review, and confirmation

1Details

2Review

3Complete

Shared patterns

Workspace shell

Actual controls and source-linked rows used by the applications.

Attention · object and reason

Resume · location and draft

Activity · event and preview

Visual design system · v0.4

Make the work clear.

Origo creates coherence across distinct business applications by giving every surface the same visual physics, semantic tokens, and hierarchy rules. It favors clarity and restraint, then uses light, depth, color, shape, and motion to make interaction easier to understand.

Calm by defaultPhysically coherentSemantically layeredTask-specificTest every state

00 · The primary design intent

Make action feel tangible.

Origo uses a quiet reading field and a selective, physical interaction layer. Roughly 80% of the surface supports reading; the actionable 20% catches the light. These are design proportions, not numerical quotas. A strong material treatment must predict an action, a state change, or a temporary layer.

Make the invitation honest

A raised button presses down. A focused input gains a lit rim. A selected tab sits above its track. A draggable card lifts during movement. Menus float over the work they affect.

Do not disguise information as a control

Do not add hover glows to static KPIs, glass to document pages, or a floating shadow to every card. Preserve non-color cues and a visible focus outline. Never require hover to discover a primary action.

Role / state	Required behavior	Material recipe
Reading content	Stable during light changes; no motion on hover.	Opaque, planar, clear text.
Action at rest	Recognizable before interaction.	Shallow body, directional edge and compact cast shadow.
Hover or keyboard focus	More inviting without moving neighboring content.	At most 1px lift; stronger edge and reflection. Focus also has an outline.
Pressed	Immediate, reversible physical feedback.	Body lowers; shadow tightens. No bounce.
Selected	Persistent state, not permanent hover.	Accent-tinted material, explicit marker and ARIA state.
Disabled or read-only	No action invitation.	No lift or moving reflection; preserve a readable label.
Floating controls	Above the work; dismissible and keyboard reachable.	Frosted background, directional rim, clear occlusion. Do not nest glass layers.

Glass is reserved for action surfaces and floating controls. It is a browser approximation built from translucent fills, blur, directional reflections, and AmbientCSS shadows—not optical refraction. Reduced-transparency and forced-colors fallbacks use opaque surfaces. Reduced motion removes lift and animated reflection.

02 · RESPONSIVE CONTRACT

One task first. More context when it fits.

Start with a complete, touch-ready single-pane experience. Add persistent navigation and supporting panes only when the primary content remains usable. A phone is not a squeezed desktop, and an ultrawide monitor is not permission to stretch paragraphs.

Available space	Layout responsibility	Interaction responsibility
Narrow / touch	One working pane. Page, channel, inbox, and file navigation use dismissible drawers. Wrap action groups together. Keep the composer visible.	Primary actions are always discoverable without hover. Use 44px action targets where practical; preserve text labels or explicit accessible names.
Tablet / compact desktop	Add a compact app rail, then a local navigation pane. Do not squeeze an editor or reader to fit optional context.	Maintain keyboard order and return focus after closing navigation. A resize must not change the chosen item or lose a draft.
Wide / ultrawide	Bound paragraphs to roughly 70–80 characters. Align message history with its composer. Tables, boards, and code can use a wider working frame.	Keep actions adjacent to the object they affect. Context remains optional. Never enlarge every gap merely because the screen is wider.
Short / landscape	Reduce toolbar overhead, not the reading font. Make the terminal collapsible. Every work scroller must retain useful height.	Dialogs scroll internally. On-screen keyboards must not cover the active composer; pinch zoom must remain available.

Query the component’s capacity

Use container width for dashboard and gallery columns. Test long labels, empty states, and mixed content at the thresholds, not only at device presets.

Do not hide a problem with overflow

Page-level overflow checks are only a first check. Inspect the actual header, composer, action row, drawer, and dialog. Preserve intentional internal scrolling for boards, tables, and source code.

01 · Core principles

The rules behind every visual decision

These principles are ordered. When principles compete, favor the earlier one.

01

Action has physical presence

Use coherent light, a visible edge, and slight elevation to invite interaction. Pressing lowers the control; focus is just as visible as hover.

02

Content keeps its calm

About 80% of the working field should support reading without demanding attention. The interactive 20% earns stronger light and material response; this is a balance, not a quota.

03

Depth describes behavior

Passive content is planar. Actions sit above it. Inputs are shallow wells. Temporary controls float. Do not make read-only content look like a button.

04

One scene, one light

Highlights, cast shadows, and pressed states share the same direction. Pointer response stays local to the active control; it never tilts the entire application.

05

Contrast survives the material

The material changes around the label, not through it. Keep text, focus, boundaries and state readable in every supported theme and lighting preset.

06

Consistency without uniformity

Share action behavior across applications. Let documentation stay calm, conversations stay readable, workflow cards feel movable, and repository tables stay precise.

07

Color is relational

Separate accent fill, accent text and selection surfaces. Derive them from a deliberate harmony, then test their roles in real rendered components.

08

Motion confirms cause

Respond quickly, move only a small distance, and settle. Give touch and keyboard users the same affordance. Respect reduced motion and never depend on hover alone.

02 · Scene model

Design the environment, then the object

Origo treats the interface as one illuminated scene. Designers specify semantic roles and geometry; the rendering system resolves the final material response.

TaskWhat the user needs to understand or do

Semantic roleCanvas, surface, control, status, overlay

GeometryPlanar, raised, recessed, rounded

MaterialMatte, satin, translucent, emissive accent

Rendered resultShared light resolves depth and highlights

Designers should not hand-tune unrelated shadows on neighboring components. Choose the semantic elevation and material; let the shared scene create the visible relationship.

03 · Depth and material

Use a small physical vocabulary

Depth is intentionally narrow. Most interfaces need a canvas, a planar surface, a shallow raised surface, a recessed region, and a temporary overlay.

Level	Use	Visual treatment
Inset	Inputs, tracks, wells, contained data regions	Concave edge, low tonal contrast, no floating shadow
0 · Planar	Canvas, reading surfaces, tables, persistent panes	Tonal separation and rules; no elevation shadow
1 · Raised	Interactive cards, buttons, selected tools	Shallow edge and restrained shadow
2 · Floating	Pinned controls, floating toolbars, high-priority objects	Clear separation; use sparingly
3 · Overlay	Menus, dialogs, command palettes	Strongest depth; always temporary

Matte

The default material. It supports long sessions, dense information, and broad surface areas without competing with content.

Default for reading and structure

Satin

A modest highlight that clarifies shape and interaction. Suitable for primary controls, indicators, and selected objects.

Use for focused interaction

High energy

Gloss, glow, or stronger saturation belongs only on a key state, active control, or compact data indicator.

Only with a functional reason

04 · Color

Build palettes from relationships

A named hue harmony sets relationships. Contrast-constrained role colors make those relationships usable. Accent fill, accent text and selected backgrounds have different luminance requirements and must not share one color token.

Color rules

1

Use role tokens such as accent, surface, text, success, warning, and critical. Never bind a component to a literal hex value.

2

Keep neutral surfaces close in hue and separate them primarily by lightness. This preserves calm while maintaining hierarchy.

3

Reserve the primary accent for focus, selection, active progress, and the highest-priority action in a local region.

4

Status meaning must survive grayscale. Pair color with text, iconography, position, or shape.

5

Validate every generated theme in light and dark mode. The relationship is the design; neither mode is a secondary skin.

Live theme roles

Accent fill--accent-fill

On accent--on-accent

Accent text--accent-text

Selected field--accent-surface

Surface--panel

Primary text--ink

Secondary text--muted

Control edge--control-border

Do

Use --accent-fill with --on-accent for filled controls; --accent-text for links; and --accent-surface for selected rows. Keep link underlines in reading text.

Avoid

A pleasing swatch is not a contrast test. Do not reuse a pale button fill as small link text on a light background. Never use color as the only status cue.

05 · Typography

Let type carry most of the hierarchy

Use a 12–32px scale at the default 16px root. Working text is 14–15px; sustained reading is 16px. Compact mode changes row spacing and working text by one step, never document text or metadata below 12px. Use approximately 1.65 line height for messages and 1.8 for articles.

Token	Size	Use
`--text-meta`	12px	Metadata only
`--text-label`	13px	Supporting labels
`--text-body`	14px	Controls, tables and code
`--text-content`	15px · 14 compact	Chat and email
`--text-reading`	16px	Documents and Wiki
`--text-title`	24px	Page headings
`--text-display`	32px	Home headings / focal metrics

Do not reduce body text to compensate for dense layouts. Reduce decoration, secondary metadata, or column count first.

06 · Motion

Confirm cause and preserve orientation

Motion connects user action to system response. It should be brief, interruptible, and removed when the operating system requests reduced motion.

State change · 120–180 ms

Hover, press, selection, focus, and small disclosure. Prefer opacity, transform, and tonal changes.

Spatial change · 180–280 ms

Panels, menus, view transitions, and objects moving between containers. Preserve a visible origin and destination.

Data change · contextual

Animate only when it helps the user understand direction or magnitude. Do not replay on every refresh.

Ambient effects · nearly static

Shared lighting may change deliberately in a lab or theme context, but routine work should not feel visually unstable.

07 · Accessibility

Accessibility is part of the visual grammar

Accessible states are designed with the component, not added after visual approval.

Contrast

Target at least 4.5:1 for normal text and 3:1 for large text, icons, controls, and essential boundaries.

Focus

Every interactive element has a visible focus ring that is not dependent on elevation or subtle color change.

Targets

Provide at least a 44 × 44 px touch target even when the visible icon is smaller. Dense pointer layouts still need 32 px minimum hit areas.

Redundancy

Never communicate status by color, glow, or depth alone. Include a label, icon, pattern, or explicit value.

09 · Implementation contracts

Make the rules executable.

Use the same role tokens and component classes in applications and the Gallery. Create an exception only when the task requires it, and document why it cannot use an existing contract.

Spacing and shape

Token	Value	Use
`--space-1 / 2 / 3`	4 / 8 / 12px	Icon–label relationships, related controls and small groups.
`--space-4 / 5 / 6`	16 / 20 / 24px	Rows, control groups and object padding.
`--space-8 / 10`	32 / 40px	Article sections and major regions.
`--radius-control`	8px	Buttons, inputs and search fields.
`--radius-object`	12px	Cards, linked work and grouped content.
`--radius-overlay`	16px	Dialogs and laboratories.

Use the appropriate component

Intent	Component	Required behavior
Perform an action	`.primary-btn / .soft-btn`	Native button, visible focus, pending state when needed, a truthful result.
Navigate to content	Named link or navigation item	A stable location; Back restores the previous page and reading position.
Collect a value	`.form-field`	Persistent label, help/error relationship, validation without erasing input.
Manipulate a work item	`.issue-card`	Pointer and keyboard entry; editable status as an alternative to dragging.
Interrupt for a decision	Modal dialog	Named dialog, initial focus, contained tab order, Escape, return focus.
Tune appearance while observing	Nonmodal laboratory	Move focus in; allow tabbing out; Escape returns to its launcher. Do not block the work.

Design for the content that does not fit

Do

Wrap message and issue text. Truncate navigation labels only when the full label remains available. Scroll a wide data table within its region. At 820px and below, let local navigation become a dismissible drawer.

Avoid

Do not shrink body text to preserve a composition. Do not let a long filename widen the page. Do not hide the only way to change status when dragging is unavailable.

States are part of the component

A handoff includes default, hover, pressed, keyboard focus, disabled and—when relevant—loading, success, error, empty and read-only states. Disabled actions explain their prerequisite nearby. A failed action preserves the user’s input and provides a specific recovery action.

Shared scene, selective physicality

Do

Keep reading backgrounds stable. Let shared light explain a button’s edge, an input’s recess, an issue’s movability or a temporary overlay. Test each effect under Quiet and Sculpted with the same content.

Avoid

Do not bevel every nested container. Do not let a theme experiment make body text faint. Do not raise a static paragraph simply because elevation is available.

Release checks

Check all ten views in both modes; one generated high-chroma palette; one extreme light; keyboard-only completion; reduced motion; long and missing values; and a 320px viewport. Check focus and control boundaries manually. Theme Lab’s computed-color samples and Gallery’s structural checks are useful evidence, not complete accessibility certification.

Shared workspace pattern

A consistent shell around specialized work.

Application identity and local navigation belong in the sidebar. The header provides workspace-scoped search, portfolio-wide attention, and feedback. Each product owns its working objects, local actions and domain rules; changing the host does not change an object's identity.

One implementation, wherever you work

The shell surrounding this guide is the same shell used by the applications. These controls open its actual search, attention panel, feedback composer and workspace selector. They are not a second set of demonstrations.

Compose the overview from working objects

Attention presents an object and an outstanding reason; resumption presents an actual working location; activity distinguishes what happened from its content preview. Use the shared row renderer and source adapters. Keep the object's route stable and never mark it read or complete merely because it appears in a summary.

Needs attention

Continue working

Activity

Integrate a product, not a second shell

Workspace
  identity: stable ID, name, publication version
  local navigation: capabilities and object routes
  search: published records with explicit workspace associations
  attention: source IDs, outstanding reasons, destinations
  actor bindings: stable profile mapped to source identities
  context: selection, draft, focus and return location

Search follows the workspace. Personal attention follows the person. Source bindings describe which local records correspond to that person; they do not authenticate them or grant access. A production source must enforce its own authorization before returning data.

State and responsive behavior

Reserve the selector and account area before fitting complete navigation rows. On Home, show bounded previews with a clear route to the full collection. Short or narrow windows change composition before typography; extreme constraints use an explicit scrolling fallback. A temporary panel must not move the object under a pointer or discard keyboard focus.

Empty, unavailable and stale are different states. New records can update the attention count while an inspected list waits for refresh. Feedback keeps its original application context and distinguishes a saved local record from delivered feedback. Activity snapshots are not a full audit log: only complete timestamps support chronological ordering.

Acceptance contracts

08 · Designer handoff

What an implementation-ready design includes

Handoff describes intent as well as appearance. A developer should understand the semantic role, states, and responsive behavior without reverse-engineering the mockup.

Semantic roleCanvas, surface, control, inset, overlay, or status.

Token referencesColor, radius, spacing, elevation, typography, and motion tokens.

Complete statesDefault, hover, pressed, focused, selected, disabled, loading, empty, and error where relevant.

Responsive rulesWhat wraps, collapses, scrolls, hides, or becomes a different control.

Content constraintsMinimum, typical, and maximum lengths; truncation and overflow behavior.

Accessibility evidenceContrast, focus order, keyboard behavior, labels, targets, and reduced motion.

0 of 6 reviewed

10 · Exploration

Calibrate the amount of physicality

Choose a treatment per work surface in Lighting lab. It changes object thickness, elevation, and recess depth—not navigation, meaning, or text. Compare the same content, then export the complete scene as a portable JSON preset.

Quiet

Minimal body height, near-planar containers. Start here for documentation, correspondence, and prolonged reading.

Balanced

Subtle edges on manipulable objects, shallow wells, and a calm field. Start here for Wiki and conversation.

Sculpted

Stronger separation between cards, deeper tracks, and polished accents. Treat as an exploration, not a universal default.

Use polished material for a small indicator or control, not paragraphs. Keep broad reading surfaces matte. Frosted overlays need a stable backing so text remains legible. Reduce or remove depth wherever it competes with the content.

This single-file exploration bundles the AmbientCSS core used here: calibrated lighting, edges, surfaces, recesses, and matte/shiny/glass treatments. Grain textures and the React control package are not included.

Origo

Design system

Application concepts

Explore application patterns in their working contexts.

Origo / appearance

Theme Lab

Author the shared appearance here. Basic appearance selection remains in Sigma preferences.

Theme lab

Generated paletteMineral Arc

Curated themes Reviewed in working views

A palette keeps your mode and light. A matched scene applies its recommended mode and lighting too.

Accent fillvar(--accent-fill)

Supportvar(--accent-2)

Tertiaryvar(--accent-3)

Surface#222925

Canvas#111513

HarmonyExtended analogous

Neighboring hues create a calm palette with enough separation for charts and state.

✦Generation chooses a curated seed hue, then derives supporting colors with a named color harmony. It never assembles unrelated random RGB values.

Portable scene JSON preset · v3

Preset name

Includes theme, mode, all light settings, and each tab’s depth treatment.

Reading & scene checks v0.4

Working density

Scene not checked yetCheck representative text pairs in the current view.

Checks use computed solid backgrounds. Images, gradients, focus geometry and screen-reader behavior still require review. Extreme scenes remain available.

Compare scenes same work, same position

Save a baseline, change the theme or lighting, then compare A and B in place.

Interaction study

Shared tokens and actual Origo component classes.

Reading surface / calm

Release readiness

Keep the content legible and the work in context. Light belongs to the controls, not to the paragraph.

ReviewOwner · Platform team

Decision note

Interactive specimen only · no product record is changed.

Review in a real product

Changes use the existing shared appearance engine. Return to the exact product context you brought into Origo.

This study is not a live duplicate of your product screen.

Origo / light & material

Lighting Lab

Author the shared appearance here. Basic appearance selection remains in Sigma preferences.

AmbientCSS lighting lab

Light invites action.Reading stays still. Controls catch the light.

Read only

Upper leftShared scene light

Lighting presets Independent of theme

Light X-0.72

Light Y-0.70

Key0.76

Fill0.56

Hue162°

Tint7%

Interactive relief Dashboard

Amplified edges, raised objects, and deeper wells. Compare against Quiet without changing content.

Extreme lighting can reduce contrast. Judge legibility in the final scene, not only the palette.

Portable scene JSON preset · v3

Preset name

Includes theme, mode, all light settings, and each tab’s depth treatment.

Reading check

Check this view after changing the scene.

Interaction study

Shared tokens and actual Origo component classes.

Reading surface / calm

Release readiness

Keep the content legible and the work in context. Light belongs to the controls, not to the paragraph.

ReviewOwner · Platform team

Decision note

Interactive specimen only · no product record is changed.

Review in a real product

Changes use the existing shared appearance engine. Return to the exact product context you brought into Origo.

This study is not a live duplicate of your product screen.

Account

Preferences

Color mode

Use a fixed mode or follow this device.

Curated appearance

A curated appearance applies a matched palette and lighting. The selected color mode remains in effect.

Local workspace

Application order uses your launch history.

Settings are stored in this browser when storage is allowed. The HTML is not a backup of browser-local documents, messages or drafts.

Authoring

Enable rich-text editing for documents and messages. Setup may request permission to load the editor.

Developer tools