There is a version of this product that would demo better. It would send the emails, publish the posts, move the money, and report back. It would look like magic for a week and like a liability for the rest of its life.
A company's name is the one asset an owner cannot buy back. One wrong email to the wrong client, one public reply written in the wrong tone, one refund sent twice, and years of reputation are spent in a morning. No amount of speed is worth that trade, and owners know it. It is why most of them have never handed their inbox to anyone.
The floor
Morna draws a line through all the work it does. Above the line is work that is internal and reversible: matching payouts to invoices, researching tenders, sorting messages, checking stock. Reading and research simply get done. Other internal work runs on its own once the owner grants it, one kind at a time, and every run goes on the record.
Below the line is the floor: six kinds of action that are never done on the team's own authority, on any track record, ever.
- Moving money: payments, refunds, payment requests.
- Speaking in public: posts, public review replies, anything published.
- Sensitive replies: complaints, press and anything legal.
- Hiring, firing and offers.
- Deleting data.
- Anything new: work of a kind it has not done before.
Anything that leaves the company, an email to a client included, is treated the same way. It is drafted, it is explained, and it waits.
Five pieces of overnight work meet the floor. Two run on their own. Three wait for the owner.
A key for each yes
A promise not to send is only as good as the wiring behind it, so the wiring is the promise. A specialist in Morna can draft a message, but it holds nothing that can send one. The only thing that can fire a send is a key, and the only thing that can mint a key is the owner's approval.
Each key is used once, and it is bound to the exact words that were approved. If the owner edits the draft, the key is bound to the edit. What goes out is always, precisely, what was read. There is no path by which a draft changes between the yes and the send.
This matters most when something goes wrong. If a message ever left that should not have, the record shows who approved which words and when. The answer is never "the system decided".
A queue designed to shrink
Draft-and-approve has an obvious cost: approvals. An owner who has to tap yes forty times a morning has not been given a team, they have been given a new job. So the approval queue is designed to shrink over time, toward the floor and never through it.
Internal, reversible work that an owner is happy to delegate can run under a standing grant they set, one kind of work at a time. The floor does not move. Owners get fewer questions as they grant more kinds of internal work, and the floor never moves.
Trust you can check
The point of all this is not caution for its own sake. It is that trust in a team should be something you can check, not something you are asked to extend. The floor makes the risky work visible. The key makes approval mean something. The record makes every morning auditable. Together they are what lets an owner hand over the work without handing over the company.