Mullusi is the company behind Mullu, a symbolic product family for governed work. Mullu Govern helps teams review risky software actions before they execute, then keeps the approval, evidence, reason, and result in one inspectable record.
Start with Mullu Govern when work needs ownership, human approval, status clarity, and a durable trail before action. The product page is public; the live product service is not open yet.
Work request preview
Draft request
A finance workflow proposes queuing an invoice for review before any payment metadata is sent.
No execution without a named finance owner and the required invoice evidence.
The workflow above is illustrative. Use these public routes to verify what Mullu Govern is, which evidence is published, and what remains unavailable.
Mullu Govern is for teams that need a visible pause between a proposed software action and execution. It is not positioned as open runtime access or fully autonomous operation.
Policy changes, finance actions, customer-impacting updates, deployment steps, and work that needs a named reviewer.
Groups that need request context, proposed action, approval state, result, and unresolved limits in one record.
Release, deployment, and code-change actions that need review and a record before execution.
Money, vendor, support, and internal process actions that need an accountable approval trail.
The public site separates product explanation from runtime evidence. Use these routes to inspect what is visible now, what remains closed, and how the status is recorded.
Start with the Mullu Govern page to understand the offer, workflow, fit boundary, and current availability.
Open productInspect which claims are public, which evidence is present, and which runtime claims remain AwaitingEvidence.
Open proofConfirm the latest public route state, deployment surface, and runtime boundary before treating anything as ready.
Open statusTeams already have chat, docs, tickets, dashboards, and approvals. Mullusi focuses on the missing control step: make the proposed action visible, route the decision, and keep the evidence trail.
Turn a request into a proposed action with context, constraints, and owner visible before work begins.
Keep human judgment in the loop for sensitive work, policy decisions, operational change, or customer-facing results.
Preserve what was requested, what was approved, what happened, and what remains unresolved.
Separate public explanation from live runtime access so teams and visitors know what is ready and what is not.
Mullusi sets the purpose, governance, stewardship, research direction, and release boundaries. Mullu turns that foundation into named symbolic products people can understand and use.
Owns the company identity, product strategy, governance, research, public domains, and release accountability.
The customer-facing family for symbolic work products. Each product receives its own contract, route, status, evidence, and support boundary.
Governance, research, proof, status, documentation, APIs, infrastructure, and trust surfaces support the portfolio without becoming separate product brands.
Naming rule: Mullusi names the company and shared foundation. Mullu names the symbolic product family. A named product uses the Mullu prefix only after its product contract and release boundary are explicit.
Current work is local proof, claim boundaries, and prerequisite setup before public deployment or customer access.
Local proof first. Runtime claims AwaitingEvidence. No customer access or deployment claim.
Doctrine v1.2 is self-attested against Mullusi architecture and AwaitingEvidence on independent runtime witness until signed endpoints close.
Start with the product, try the browser preview, check proof status, review the public state, or contact the team.
The public website and Mullu foundation route are live. Runtime witness closure remains AwaitingEvidence until signed endpoints publish.
Technical boundary: Production Claim Boundary; public foundation route first; output-derived actions become proposals first; witness closure preparation remains separate; public site can record future surface expansion.
Trust comes from what you can verify, not from what we promise. Each pillar is named after what it lets you catch — not what it prevents.
Is a stamp recorded in the public log? Reserved until the witness endpoint publishes signed evidence.
ReservedIs the log itself append-only? AwaitingEvidence until cryptographic checkpoints publish.
AwaitingEvidenceWhich independent witnesses watch the log? Reserved until external monitors register their public keys.
ReservedEach pillar is the same shape: name what you catch, name the adversary baseline, name when it goes live. Borrowed from transparency-log practice and the Ethiopian canon-table tradition — both are witness apparatuses.
Mullusi helps a team move from a request to a reviewed action without scattering the plan, approval, evidence, and result across separate tools.
The public site starts with the product path. Deeper surfaces open only when they are ready to support users.
Mullusi is the company umbrella. Mullu is its symbolic product family, and Mullu Govern is the first public product route. Additional Mullu products stay staged until their route, contract, evidence, support, and runtime boundaries are ready.
Company trust surfaces and infrastructure support Mullu products; they are not presented as separate product brands.
The product family under Mullusi, beginning with Mullu Govern for planning, review, records, and controlled work.
Approvals, queues, notes, ownership, and status for work that needs a human check.
Schemas, local checks, and records for teams that need to connect their own systems later.
Public previews, search, browser inspection, and examples for understanding the workflow.
The roadmap is simple: define the offer, show the route, explain the status, and publish only when visitors can understand what is available.
Add or revise a deployed public-surface record in the structured registry.
Connect docs, demo, proof, status, and contact routes.
Confirm claims, accessibility, local rendering, and public boundary constraints.
Expose the product surface only after the public boundary is verified.
Mullusi is built for work where a proposed action should be reviewed, traced, and explained before it becomes a result.
In plain terms: the system should show what it is doing, why it is allowed, and what evidence remains open.
Important work should leave a useful trail: what was requested, what was reviewed, what evidence exists, and what state is still held.
In plain terms: if a work state matters, it should be inspectable.
Mullusi keeps its public identity, product route, docs, status, and contact paths connected.
Visitors can see what is live, what is staged, and what remains AwaitingEvidence.
Product pages, demos, docs, proof status, and release stages are kept as structured records.
New public surfaces enter the site when their route, docs, status, and support path are ready.
The public site separates product pages, docs, demos, status, and proof so visitors can find the right surface without reading the whole architecture.
In plain terms: each public page should help a visitor find the product, understand the status, or contact the team.
Interface links are treated as managed records so new public routes can be added without reworking the layout.
Reference material, architecture notes, and public learning paths.
Open Docs →Mullusi brings product help, developer access, team review, and status visibility into one work system.
A compact status view for live routes, staged work, and runtime evidence state.
Mullusi is for teams that want the speed of software assistance without losing review, records, ownership, or a clear reason for each result.
| Common workflow | Mullusi workflow | |
|---|---|---|
| 01 | A tool generates an answer | A work request becomes a reviewed proposal |
| 02 | Confidence is hard to inspect | Status, reason, and limits are visible |
| 03 | Records appear after the fact | The record travels with the work |
| 04 | One approval can cover too much | Important steps can be checked again |
Start with one practical loop: submit the work, review the proposed action, keep the record, and return a result people can inspect.
In plain terms: Mullusi helps teams know what happened, why it happened, and what still needs review.
Mullusi fits operational work where teams need help moving from intent to action without losing approval, evidence, or accountability.
Math, physics, engineering, biology, chemistry, and music are future product families. They stay on the roadmap until each has a clear route, demo, documentation, and support path.
In plain terms: the roadmap is sequential; staged domains do not compete with the foundation product path.
Search the routes that are public now. Product internals, SDK work, science engines, and research source stay private until a separate public release is ready.
Start with Mullu Govern, then use proof, public state, or contact when you need the current boundary or a partnership conversation.
