01Product

Mullu Govern: approval and evidence for risky work.

A planned review-and-approval layer between a proposed action and its execution. Your own systems would do the work; Mullu Govern would keep the decision and record.

Not open yet. Try the browser demo today, or ask whether it fits your team.

Try the demo Ask if it fits

Browser demo. Nothing to register.

Example stage

Switch the example stage. Held and blocked decisions also leave a record.

Approval record · Vendor payment
INV-2041
  1. Request
  2. Plan
  3. Review
  4. Approve
  5. Record
  1. 09:41 Request ops@ asks to queue vendor invoice INV-2041 for payment. Owner named: finance.
  2. 09:44 Plan Proposed action: add INV-2041 to the next payment run. Limits: no execution without a named finance owner and the invoice evidence.
  3. 09:50 Review Two questions. Amount matches purchase order PO-7731. Resolved. Unresolved: vendor bank details changed on 12 Oct, confirmed?
  4. 09:51 Hold Held for approval. One question open. Nothing runs.
  5. 10:03 Approve Approved by a named finance owner. Bank change confirmed with the vendor by phone, 09:58.
  6. 10:04 Record Record written. Rollback: reverse the queue entry. Receipt MGR-2026-0142
Record written: held, question 2 open. No execution. The record exists whether the action goes ahead or not. Approved by a named finance owner, 10:03. Not yet executed; your own system runs the step. Record written 10:04, rollback noted. Requester ≠ approver, evidence attached. Held Approved Recorded
Fig. 2 The same record at three example stages. Illustrative; nothing here runs outside your browser. This example is unsigned and does not demonstrate tamper protection.
02How it works

Five steps from a request to a record

Illustrative walkthrough: vendor invoice INV-2041. This shows the planned review, not a completed customer transaction.

  1. 09:41Request

    Operations asks to queue INV-2041 for payment and names finance as the owner.

  2. 09:44Plan

    The plan names the queue entry, invoice evidence and limits on execution.

  3. 09:50Review

    A reviewer checks the invoice and asks about the changed bank details. An open question holds the action.

  4. 10:03Approve

    The named finance approver decides after the bank-detail question is resolved.

  5. 10:04Record

    The decision, evidence and rollback note stay together. Execution would need your own system and a decision-checking integration.

Sample review record

What the record would keep

A review record should make the work understandable after the decision: what was requested, what was proposed, who reviewed it, why it was held or approved, and what remains unresolved.

Release note review
Example only
Request
Publish a public release note for the homepage clarity update.
Proposed action
Move the update forward after confirming copy, status boundary, and contact route.
Constraints
No access claim, no pilot promise, and no hidden approval.
Reviewer
Named human reviewer required before public release.
Verdict
Hold for approval until reviewer acceptance is attached.
Evidence
Draft copy, local validation output, status boundary, and contact route reference.
Unresolved questions
Confirm whether the release note should mention pilot timing.
Rollback note
Revert the public copy change and keep the prior status boundary if approval is declined.
03Design commitments

Four rules the record is built around

Planned product rules. The browser demo simulates evidence, reviewer and risk checks; it does not verify identities, resolve review questions or collect signatures.

  1. The requester cannot be the approver.

    Two different named people appear on every record, or it stays held.

  2. Unresolved questions hold the action.

    Any open question in Review keeps the verdict at Held until a person answers it.

  3. Missing evidence blocks the action.

    The plan names the evidence it needs. Missing evidence means Blocked until it is attached.

  4. Approved, held or blocked: every outcome leaves a record.

    Each outcome keeps the request, review and reason. Silence is not an outcome.

04Vocabulary

If your tools say pause, approve and resume

Four terms, mapped once.

pause
Review. The proposed action waits while a person reads the plan.
approve or hold
Approve. A named approver decides; a hold is a decision too.
resume
your own system executing. Mullu Govern does not run the action.
record
Record. Request, plan, questions, decision and rollback in one entry.

Mullu Govern cannot stop an external tool without an integration that checks the decision before execution. That handoff is planned; no external tool is connected in this demo.

05Boundary

What it will not do at launch

Said plainly, so a reviewer does not have to guess.

  • Execute actions. Your own system runs the approved step; Mullu Govern holds the decision and the record.
  • Review every action. It is for the actions that must be reviewed; the team decides which.
  • Decide for you. No automatic approvals. A named person approves or holds.
  • Replace your audit system. The record is meant to be exported as evidence, not to become the system of record for everything else.

What comes next is tracked on the status page as Available, Not yet or Planned, with no dates attached.

Evidence details (for auditors)
Runtime gate
AwaitingEvidence until signed witnesses publish
Witness endpoints
/health, /gateway/witness and /runtime/conformance must be signed and reachable before any service claim.
Claim boundary
Public access and pilot workflow are not claimed. The status page keeps the plain-language state.
Public proof
mullusi.com/proof/ remains available for visitors who need technical status and runtime evidence details.
06Next step

Try it in the browser, then talk to us

Try the demo Ask if it fits

Browser demo. Nothing to register.