Since our last report, we have moved from navigation consistency into production Starter preparation. This entry covers September 10 afternoon through September 11: testing real account journeys, fixing the problems those tests exposed, and updating the website and operating services around the application.
Production Orion and staging Cell-1 now run the same application release, 20260911.8. Public registration remains closed while we finish the customer policies and final signup checks. Paid plans remain disabled pending Paddle approval and paid-flow testing.
Free Starter can operate independently of paid plans
Starter registration and organization provisioning now work without a payment card, Paddle checkout or a subscription confirmation. Server-side checks keep paid signup and upgrade requests unavailable while paid availability is off.
We completed production service alignment and prepared Orion’s provisioning and routing. During controlled acceptance windows, dedicated test accounts completed registration, email verification, password setup and recovery, sample loading, and system, model and component configuration.
Those tests also covered invitations, Viewer access, organization switching and account deletion. The temporary admission windows were closed afterward. This was release acceptance, not a public opening.
Recovering the organization setup a user already started
Interrupted signup exposed several places where a user could lose their path back to organization setup. Concurrent login tabs could overwrite transaction state, and an expired login transaction could return the user to generic sign-in without preserving the original setup request.
We isolated concurrent login transactions and preserved the original setup handoff when a matching transaction expires. Fresh authentication is still required. The no-organization screen now offers a route to continue existing setup, with recovery guidance when the browser no longer has valid resume state.
These changes help users finish the request they already started without creating a replacement organization or bypassing identity checks.
Invitations, permissions and leaving an organization
Production testing found an older restriction that prevented a hosted identity from accepting an invitation into a second organization. We removed that restriction from the hosted flow while preserving the user’s existing membership and role.
We verified an account switching between its own owner workspace and another organization’s Viewer workspace. Viewer pages explain their access restrictions and no longer suggest creation guides the user cannot follow.
Deletion testing confirmed both cases: leaving one organization preserves access to another, while deletion of the final organization removes the orphaned application and identity accounts. We fixed a database-reference problem that had blocked final deletion, while preserving historical audit evidence.
The departure screen explains that a free account has no subscription charges. Cancellation wording no longer implies an automatic prorated refund, and the retention wording acknowledges that historical audit records may retain an account email. Only the designated acceptance fixtures were removed.
Readiness profiles tested through real examples
We added help for readiness profiles and exercised seven published profiles across seven systems using Starter’s built-in factors. Five systems were new; two existing samples supplied the remaining examples after the Starter limit was reached. We did not bypass the limit or introduce custom fields.
The exercise found four defects, all subsequently fixed and deployed:
- Added factors could have blank categories and fail with a server error. They now receive defaults and validation before saving.
- A successful save could still leave publication blocked by an unsaved-changes warning. Saved-form tracking now follows the updated form.
- Systems inventory could say Not assessed despite completed assessments. It now uses the complete assessment result consistently with the detail page.
- Newly created systems could show a blank lifecycle label. Translations and a fallback for custom codes now keep the status visible.
Release verification also exposed timing inconsistencies in immediately effective architecture configuration and relationships. These operations now use database transaction time, so historical configuration and readiness checks agree about when a change becomes effective. Explicit scheduled dates remain supported.
Guidance that helps without obscuring the application
New hosted users once again enter the Welcome flow, and their chosen guide survives administrator setup. Active guides highlight the target with a blue pulse instead of covering the page with a grey overlay. Reduced-motion support and cleanup when a guide ends are preserved.
Password setup now gives feedback while the user types. Each requirement gains a checkmark when satisfied and returns to its pending state if the user removes something it needs. The checks use Keycloak’s own policy validator.
This required a separate identity-service deployment: updating an application cell alone does not update its hosted password screen. The new theme is now running in both staging and production. All 32 desktop/mobile identity tests passed, including required-password setup, confirmation mismatch and localized layouts. Existing accounts and password rules were preserved.
We also replaced blocking browser confirmation dialogs with inline confirmation. Account and organization deletion retain typed confirmation, and cancelling an action does not submit it.
Operating and recovering the release
Critical incident and recovery emails now use the existing Postmark service. We verified received messages and completed delivery records, enabled backup health checks on both cells, and added Orion disk checks covering its root filesystem and tenant volume.
Investigation links now lead to the matching Control environment. A delivered staging test alert was checked to confirm the corrected destination. Free external baseline monitoring remains in place; paid responder and push-alert features are deferred. No paid monitoring license was purchased.
Deployment retries now recreate or start stopped candidates and update the worker after activation. Both cells’ application, worker and monitoring worker are aligned to the final release and report healthy.
Encrypted backups were verified around the deployments. An Orion database backup was also restored independently with each recovery custody key. This verifies cell-database recovery; tenant-selective restore remains separate work.
The final application release passed 529 browser tests, with 63 approved optional skips and zero failures, alongside Go, database, recovery and controller checks. These totals describe the final suite and should not be added to earlier release totals.
Website updates
Production visitor analytics are now self-hosted, with protected dashboard sign-in. The staging website does not include the production tracking script. The production website also emphasizes free Starter and removes paid checkout and trial links while those plans are unavailable.
We prepared the partner-program proposal and published its first page to staging, including desktop and mobile navigation checks. Partner registration is not open, and the proposed pilot terms are not yet an implemented commission system. Staging’s website branch remains independent of production main.
Four customer policy pages are now available on the production website following the latest main-branch deployment:
They remain clearly labelled review drafts, not yet effective. Publication for review does not complete the outstanding retention decisions.
Both onboarding environments now support versioned policy acceptance. Once configured with an effective policy bundle, signup requires agreement and records the version, document fingerprint, timestamp and signup reference associated with the verified identity. A form opened against an older policy version must obtain fresh acceptance. That configuration remains inactive while the documents are drafts.
Before opening Starter
The remaining work is to settle retention decisions, reconcile and approve the final policy text, activate versioned acceptance, and decide how agreement applies to invited users. We will then verify the final signup journey and explicitly enable Starter admission and routing to Orion.
Paddle’s business approval and paid-flow testing remain separate prerequisites for paid plans. They do not prevent the free Starter architecture from operating.