Ledgerly's delegated-billing feature was technically in beta. Engineering knew it. Product knew it. The release catalog said it. But on a Wednesday morning, a sales manager forwarded a proposal generated by the company's sales assistant. The proposal described delegated billing as generally available and promised that any account administrator could transfer ownership instantly.
Neither statement was true.
The 75-person SaaS company had not failed to document the feature. It had documented it in too many places. Product specifications described the intended experience. Identity owned the permission model. Billing owned financial invariants. Support had a beta troubleshooting guide. Security had a threat-model exception. Sales had copied an older launch brief into its AI workspace. Each team was operating carefully inside its own boundary, but the company's AI tools did not share one release state.
Ledgerly created a onemind Launch Project for delegated billing. It did not copy every source into one giant document. It referenced accepted entries from Product, Identity, Billing, and Security, then added launch-specific owners, cohorts, evidence, and public claims. Product alone could change release state. Identity alone could approve authorization rules. Billing owned invariants such as “an unpaid balance cannot disappear during ownership transfer.” Security owned threat controls. Sales and Support consumed those facts but could not redefine them.
The sales assistant's package changed first. It now received the beta cohort, two approved claims, three prohibited claims, and an escalation path for enterprise contract questions. The support assistant received released behavior for the current customer's cohort, diagnostic steps, and account-safe language. Cursor, Codex, and Claude Code received authorization rules, API contracts, migrations, and regression tests. The security agent received the threat review and evidence requirements.
Two weeks into beta, a customer named Acme Holdings opened a support ticket. An administrator had delegated billing work to a colleague, then the original account owner left the company. The colleague could prepare invoices but could not complete the ownership transfer. The support assistant searched its accepted guidance, found no answer, and escalated instead of inventing one. onemind created an Incident sub-Project linked to the launch.
Support attached an account-safe timeline. The Identity owner saw that the permission model assumed the original owner remained available. Billing identified a second risk: changing ownership during a pending invoice could alter who received the tax document. The coding agent proposed a simple bypass, but onemind surfaced the Billing invariant and the security rule requiring verified recovery.
The teams agreed on a recovery workflow requiring two authorized administrators or a verified support process. Identity approved the rule. Billing approved the invoice-state behavior. Security approved the evidence requirement. Engineering added the implementation and regression tests. Each approval was separate and visible; a product manager could not approve a security interpretation on behalf of Security.
When the accepted entries changed, onemind calculated the affected packages. It updated coding tools, marked two open pull requests stale, added a troubleshooting branch to Support, and changed the beta documentation. Sales received a narrower approved statement. A draft proposal already generated for another customer was flagged because it cited the superseded package; onemind did not silently edit the document, but it showed the salesperson what needed review.
Before general availability, the Launch Project displayed five readiness lanes. Code and tests were green. Security evidence was approved. Support documentation was current. Analytics instrumentation was missing one recovery event. Sales enablement still had two users on stale packages. The launch could not be marked ready until the missing event shipped and the stale users updated or received recorded exceptions.
The product owner changed the release state only after those items closed. That event rebuilt Support and Sales packages for general availability; it did not alter historical beta conversations or incident evidence.
Three months later, Ledgerly compared ordinary cross-functional changes. The time from an accepted product change to verified freshness across affected tools had fallen from an informal two or three days to the same business day in most cases. The more important result appeared in review: fewer support answers, sales drafts, and pull requests had to be corrected for facts the company had already decided. onemind did not make the teams agree. It made disagreement and ownership visible before contradictory versions reached customers.