Release scope

Every other page in these docs describes the agreed direction of WilsonOS. This page is the one that says how far it has shipped. It is a snapshot as of 15 September 2026, compiled from the engineering reports supplied for the September editorial revision; the live task ledger is authoritative after verification, and the date above is the date to trust.

Delivery rule

A capability is complete when its required behaviour is deployed and verified. A diagram, a merged change, or a transferred follow-up is not proof of completion. Urgent discovered incidents stay visible; unrelated cleanup is not folded into every release.

Reading the three columns

• live Reported implementation — deployed, with acceptance evidence.
• direction Current completion work — agreed and in progress; the scope boundary says what “finished” means.
• proposed Proposed / later scope — discussed, not commissioned by anything on this site.

Snapshot

Area	Reported position	Scope boundary
Chat and conversations	Core private conversations, streamed progress, and smart links are live; the next stage (shared conversations, scoped memory) is deployed in code with runtime-isolation setup and live acceptance pending; a further stage is built but gated	Finish reliable routing and recovery, private and shared agent conversations with explicit membership, scoped memory, and the required runtime tests
Media lifecycle	Storage cutover and the asset model conversion are verified; final legacy removal and backup verification remain subject to current evidence and approvals	Finish the media lifecycle: durable references, backup, and recovery criteria
Task folders and identity	Stable-identity folders and path mapping are reported live; fallback removal merged; final deployment and link checks pending	Preserve identity, editable titles, authoritative locations, files, and historical links
Human-only conversations	Proposed extension to the conversation model	Explicitly estimate zero-agent rooms, membership and history rules, and messaging behaviour before any build
Documents and diagrams	Existing file-based workflows and readers work; a consistent published-artifact lifecycle is proposed	Assess reuse of the artifact registry for source files, dependencies, immutable published versions, permissions, and verified backup
Customer records, calendar, funnels	Shared conceptual records exist and are used consistently; surfaces vary in maturity; no complete implementation census here	Explain the relationships now. Nothing here commissions a new CRM or analytics engine
Unified customer inbox	Future capability	Requires channel ingestion, identity matching, reply permissions, and explicit agent invocation
Semantic search and automated learning	Direction; current completeness not established here	Improve after reliable sources and access are in place. No new vector service and no autonomous skill-rewrite system is authorised

Foundations

Foundation	Position
Identity & access	direction Model defined; single-operator today; access rules being extended table by table ahead of multi-user use
Data governance	live One canon and one writer per record class enforced for tasks, media, and memory; nightly drift detection
Connections	live Gateway pattern enforced for media generation and editing; connections catalogued with scopes

How this page is maintained

• It is regenerated from the task ledger at each editorial revision, and the lastVerified date in the footer changes when it is.
• It never inherits a status from an explanatory page. If a concept page says live and this page disagrees, this page wins until the concept page is corrected.
• New capability proposals are kept separate from the completion of in-flight work. Finishing the foundation comes before labelling the next steps.

Related

How to read these docsWhat the status labels mean and where the source boundary sits.

FoundationsThe three planes whose positions are summarised above.

How it works in 5 stepsEach linked section carries its own status note.