Identity
What the object is and what must remain continuous while its state changes.
How Mullusi works
See a governed action form, stop, proceed, and settle.
Choose an illustrative scenario and inspect how Mullusi makes identity, rules, state, boundary, relationships, approval, evidence, and history explicit.
Illustrative scenarios
Not live runtime. No production, finance, customer, or external-system action is performed from this page.
Mullusi governed workflow
Request → structure → constraints → approval → execution → evidence → settlement.
Illustrative governed execution scenario
Current transition
A deployment request enters
- ΙIdentity
- ΛLaw
- ΣState
- ΓBoundary
- HHistory
Choose an illustrative scenario
Changing the scenario resets the causal sequence to its first event.
Active scenario
Software deployment
A proposed software change must pass validation, release policy, named approval, bounded deployment, and observed health evidence before it settles.
Illustrative deployment only. No repository or production environment is connected.
InputSoftware change request
Decision pointRelease-owner approval
Completion ruleObserved version and health evidence
OutputPersistent release receipt
Current stage
A deployment request enters
A proposed change exists, but its target, release rules, approver, and completion evidence are not yet explicit.
- Governing rule
- A release request must have stable identity and declared scope before planning.
- Evidence state
- Intent exists; validation and production evidence do not.
Symbol anatomy
Every important object carries five visible responsibilities.
The visual grammar comes from the Mullusi symbol kernel, not from decorative particles.
Law
Which transitions are allowed, required, blocked, or approval-gated.
State
What is currently requested, blocked, approved, executing, verified, or settled.
Boundary
Which inputs, outputs, disclosures, and real-world effects are permitted.
History
Which causes, alternatives, approvals, observations, and results must be preserved.
Typed relationships
A line has to say what kind of relationship it represents.
The Observatory separates dependency, constraint, authority, execution, observation, and evidential support.
A step cannot proceed until another condition exists.
A policy narrows which possible paths are admissible.
A named authority permits a bounded effect.
An approved gate allows execution to reach the scoped target.
An executed action produces effects that can be measured.
Evidence strengthens a verification or final receipt.
Public boundary
What this page demonstrates—and what it does not.
It demonstrates
- Multiple scenarios using one deterministic governed sequence.
- Approval before execution.
- Observed evidence before verified success.
- Persistent causal history after settlement.
It does not claim
- Live public runtime access.
- Production or payment execution from this page.
- Customer, vendor, bank, or repository data processing.
- Open API, pilot, or proof-stamp availability.
Next route
Move from the visual explanation to the product and evidence boundary.
Use Mullu Govern for the product story, then Status or Proof for availability and evidence context.