Good-fit workflow
The first pilot should focus on a specific recurring workflow where planning, review, approval, and records matter.
Pilot partnerships
Focused pilots for review-heavy work.
Mullusi is preparing a future customer path for teams that need clearer planning, review, approval, and record keeping around important work. Pilot access is not open yet. A pilot will open only when the product path, support model, scope rules, and runtime evidence are ready.
Best candidate
Repeated review workflow
First step
Written fit discussion
Access boundary
No pilot slot created
Use case
Product path
Support model
Evidence
Pilot decision
Route state
Published boundary
Pilot state
Not open
Runtime evidence
AwaitingEvidence
Customer access
Not open
Next gate
Signed witness endpoints
A future pilot will require a narrow use case, clear support path, written scope, and runtime evidence. This route is a readiness boundary, not an intake form.
Fit assessment
A useful pilot starts with one bounded workflow.
Before access opens, Mullusi can still discuss whether a workflow fits the first pilot shape. Good candidates are narrow, repeated, review-heavy, and easy to measure.
Workflow
Recurring decision path
Risk
Human approval required
Record
Audit trail matters
Boundary
Data scope can be written
Readiness ladder
What has to be true before a pilot decision.
The pilot path is intentionally narrow. Each step separates a useful conversation from a product claim, runtime claim, or access claim.
-
01
Workflow named
One repeated workflow is described with owner, participants, decision points, and expected records.
-
02
Scope written
Data boundary, support expectation, stop condition, and human approval rule are written before any operational step.
-
03
Evidence closed
Runtime, security, rollback, and support evidence close through separate witnesses before pilot state can change.
-
04
Decision published
Pilot access remains closed until a separate readiness decision is published.
Product route
Mullu Govern must have a clear user path, docs, demo boundary, and supportable status.
Readiness evidence
Health, gateway, conformance, rollback, and security evidence must close before runtime claims expand.
Written scope
Any pilot must define the workflow, participants, data boundary, support expectation, and stop condition.
Current boundary
- Published
- Website, Mullu Govern route, proof route, playground, contact, and status routes.
- Draft
- Draft v1 work review contract for future API runtime readiness:
POST /v1/govern/evaluate. - AwaitingEvidence
- Pilot access, API runtime readiness, dashboard, sandbox, metrics, learn, and signed proof stamps. No customer access or deployment claim.