Website
The public Mullusi website and linked public routes are published and available.
01What is shown
What is verified, and what is still waiting.
This page says what you can check today and what is still only a claim. The website, the product pages and the browser demo are published.
Not yet. Runtime evidence is still awaiting the named checks. Customer access and pilot admission require separate decisions.
02Shown and not shown
What is shown, and what is not
Three lanes. Two are published and you can open them now. One is waiting for named proof.
Product pages
Mullu Govern is the product; Mullusi is the company.
Hosted runtime
These three checks concern the hosted runtime; customer access and pilot admission are separate.
Not yet means waiting for named proof. It does not mean the product direction is rejected, broken or cancelled.
03What would change the state
Runtime checks, named
Signed, reachable and validated checks can verify runtime readiness. Customer access and pilots each require a separate written admission decision.
-
Health
/healthReports that the service is up and which version runs.
-
Gateway
/gateway/witnessLists the API paths protected by the gateway.
-
Conformance
/runtime/conformanceLists the service's checks and whether each one passes.
04Evidence details
The record behind this page
Auditors read on. Below are the claim registry, the product lanes, the witness endpoints and the stamp schema, in their exact technical terms.
Evidence details (for auditors)
Plain meaning
AwaitingEvidence means waiting for named proof
It does not mean the product direction is rejected, broken, or cancelled. It means Mullusi will not claim a runtime service, customer access path, or proof stamp until the required witness endpoints are signed, reachable, and validated.
Decision summary
Published pages are available. Product services are not verified
Website surface
Published
The public website and linked routes are available.
Product boundary
Published
Mullu Govern is described as the current public product path.
Runtime witness
AwaitingEvidence
Health, gateway, and conformance witnesses are not closed.
Next action
Signed endpoints
Product-service claims require reachable witness endpoints.
Reading guide
Read proof by claim, evidence, boundary, and gate
Each proof block separates a published public surface from product-service evidence that still needs closure.
Claim
What the public page says is available, published, reserved, draft, or AwaitingEvidence.
Evidence
The record, route, registry, or witness that supports the current state.
Boundary
The exact line a visitor should not read past, including runtime and service limits.
Gate
The evidence condition required before the claim can move to a stronger state.
Product evidence lanes
Product records are loaded from the public registry. Each lane states the current product state, release gate, API boundary, docs route, and proof boundary without exposing private source.
Claim registry
Claim records are generated from product proof boundaries. Each claim has a stable ID, required witnesses, proof state, runtime witness state, and public render decision.
Runtime claim boundary
Interface guidance follows the selected language. Canonical witness names, endpoint paths, environment keys, and response fields remain unchanged for exact verification.
- Published website routes are public-surface evidence, not proof of product-service runtime availability.
- Product-service runtime closure requires runtime secrets, gateway URL configuration, expected runtime environment configuration, and reachable witness endpoints.
- Until those endpoints are published and validated, runtime readiness remains AwaitingEvidence.
- Marketing, docs, dashboard, and product pages should not claim production runtime closure ahead of signed witness evidence.
Proof stamp artifact
The stamp schema states which fields must exist before a public proof stamp can be issued. It binds a verdict to policy, registry state, runtime witnesses, trace reference, hash, and signature.
Interface guidance follows the selected language. Canonical schema fields, commands, response examples, and proof-state enums remain unchanged for exact verification.