MIZAN · live controls

Not a badge. A probe that fired, and what it failed to look at.

Every row below was produced by a program that made a real request against real production or the real repository and wrote down what came back. Each probe ships a negative control — the same assertion run against a deliberately wrong input, which has to come back DARK. A prover that cannot fail is not a prover, so when a negative control does not fail, the verdict it produced is thrown away and the control reads CANT-CHECK. Every run is hash-chained and published, so you can recompute all of it yourself and disagree with us in public.

What the three verdicts mean

There is no verdict called “pass”. CANT-CHECK is not a soft yes; it is the honest answer when we could not tell, and it is counted separately from LIVE for exactly that reason.

LIVE: The probe fired and observed the control working.
DARK: The probe fired and the control did not work. This is a finding, not a warning.
CANT-CHECK: The probe could not run, or its negative control failed to fail. Not a pass. Not a failure. Unknown.

The run these verdicts came from

Sealed at: 2026-08-13T04:23:30.519Z
Chain entry: seq 6
Head (rowHash): d769352f88e79e6da5a103b8a521769cbcba2ef035fbc283ff7644ec424872bb
Verdict counts: LIVE 8 · DARK 0 · CANT-CHECK 6

This entry is unsigned. It is hash-linked, which proves the rows are mutually consistent; it does not prove we authored them, and it does not claim to.

Every control, with its limits

The right-hand column is the product. A compliance vendor’s green badge cannot print it, because the badge is generated from configuration and has no idea what its own check declined to look at.

MZ-001 · probe auth-gate-fires
Authentication gate refuses unauthenticated callers
LIVE
Every path listed in PROTECTED_PATH_PREFIXES in apps/web/middleware.ts refuses an anonymous caller at the edge, before any route handler runs.
```
observed  24/24 protected prefixes refused anonymously (7 x 307->/sign-in, 17 x opaque 404)
method    GET https://steadywrk.app<each PROTECTED_PATH_PREFIXES entry>/<nonce> anonymously, redirect:manual -> status + Location
```
What this LIVE verdict establishes

Recompute this page yourself

This page is rendered from a hash chain, and the chain is published in full. Nothing here asks you to take our word for a verdict: fetch the feed, fold it forward from genesis, and compare the head to the one printed above. The verifier has no dependencies and imports nothing from our code — that is the point of it.

# 1. Fetch the chain. It carries its own algorithm description.
curl -sS https://steadywrk.app/api/public/mizan -o mizan.json

# 2. Recompute it from genesis — with our verifier, or with yours.
node security/mizan/verify.mjs https://steadywrk.app/api/public/mizan

# 3. Prove the verifier itself can still fail before you believe it.
node security/mizan/verify.mjs --selftest

# The formula, so you never have to run our code at all:
#   genesis_tag   = STEADYWRK-MIZAN-GENESIS-v1
#   prevHash(1)   = SHA256(genesis_tag)
#   canonical(x)  = JSON.stringify(x) with every object key sorted, recursively
#   rowHash(n)    = SHA256(seq | prevHash | sealedAt | canonical(payload))
#   prevHash(n)   = rowHash(n-1)      seq starts at 1 and must be contiguous

The feed lives at /api/public/mizan. Step 3 is not optional decoration: a verifier that always prints VALID would be as useless as a badge that is always green, so it builds a good chain, flips one byte, and demands that the second chain be rejected before it will believe the first.

What recomputation buys you: the head is a pure function of the rows served. What it does not buy you: proof that the probes fired, or fired against production. The chain commits to what the probes saidthey saw — a fabricated observation hashes exactly as well as a true one. Read each control’s method above, then re-run the probes in security/mizan/probes/ yourself. They are published for that reason.

Looking for something else?

Want to check STEADYWRK rather than a control? /verify-us lists every public surface, and — in the same size type — what no outsider can verify yet.
Want the posture narrative rather than the probes? /trust covers the instrument surfaces and the privacy position.

observed 3/3 sealed: /api/employee/documents=404 empty ct=text/plain, /api/employee/shifts=404 empty ct=text/plain, /api/employee/mizan-probe-msr0j9ct=404 empty ct=text/plain [real routes indistinguishable from nonce path] method GET https://steadywrk.app{/api/employee/documents,/api/employee/shifts,/api/employee/mizan-probe-msr0j9ct} anonymously -> status + body

observed https://steadywrk.app/ 200 csp=[1482ch, default-src 'self'] hsts=max-age=63072000; includeSubDomains; pr… xcto=nosniff xfo=DENY || https://steadywrk.app/api/health 200 csp=ABSENT hsts=max-age=63072000; includeSubDomains; pr… xcto=nosniff xfo=DENY method GET https://steadywrk.app/ (require CSP+HSTS+XCTO+XFO) and GET https://steadywrk.app/api/health (require HSTS+XCTO+XFO) -> response headers

observed HTTP 200 steadywrk.app/api/public/receipt-chain; count=21 links=21; 21/21 leaves recomputed; fold reaches published head 392ccb6382b1...; sig valid but key is same-origin (not independent) method GET https://steadywrk.app/api/public/receipt-chain -> recompute chain_n=SHA256(chain_{n-1}|n|ts|SHA256(canonical_json(receipt))) from chain_0=SHA256(genesis_tag); compare recomputed head to published head. The endpoint's own integrity claims are ignored.

observed HTTP 200 count=0 links=0 head=null unsealed_rows=0; disclosure 484 chars present. Empty chain commits to nothing. method GET https://steadywrk.app/api/public/content-ledger -> recompute chain_n=SHA256(chain_{n-1}|n|ts|hash) from chain_0=SHA256(genesis_tag) and compare to published head; separately assert integrity.does_not_prove is >=120 chars / >=2 sentences and non-boilerplate, and that integrity.signing matches what the response actually carries. reason empty_chain_nothing_to_verify

observed 200 did:web:steadywrk.app — 2 verification method(s) valid. ed25519-2026-01: ed25519-pub, 32 key bytes; receipt-chain-ed25519-v1: ed25519-pub, 32 key bytes method GET https://steadywrk.app/.well-known/did.json -> JSON, then base58btc-decode each publicKeyMultibase and check 0xED 0x01 + 32 bytes

observed probe said CANT-CHECK: branch=main: gh failed: Resource not accessible by integration gh: Resource not accessible by integration (HTTP 403) || negative control returned CANT-CHECK (expected DARK): [negative control — deliberately unprotected branch] branch=ascension/claim-liability: gh failed: Reso… method gh api -X GET repos/karimalsalah/steadywrk/branches/main/protection reason negative_control_did_not_fail

observed all 27 runs-on self-hosted; runner registry unreadable: gh: Resource not accessible by integration (HTTP 403) method parse 26 .github/workflows/*.{yml,yaml} for runs-on + gh api -X GET repos/karimalsalah/steadywrk/actions/runners reason runner_registry_unreadable

observed wiring ok (direct pinned-binary invocation + in-CI negative control (detector proven able to fail on every run)); detector flagged 1 finding(s) [aws-access-token] on a freshly generated synthetic key using the repo .gitleaks.toml (allowlist in force) method "gitleaks" dir "C:/Windows/SERVIC~1/NETWOR~1/AppData/Local/Temp/mizan-scan-pYcpAT" -c "C:/actions-runner/_work/steadywrk/steadywrk/.gitleaks.toml" --report-format json --report-path "C:/Windows/SERVIC~1/NETWOR~1/AppData/Local/Temp/mizan-scan-pYcpAT/report.json" --no-banner --log-level error [8.30.1]

observed spend not verified: gh exit 1: gh: Resource not accessible by integration (HTTP 403). This is NOT a $0.00 reading. method gh api -X GET users/karimalsalah/settings/billing/usage -f year=2026 -f month=8 -> sum(usageItems[].netAmount) reason billing_figure_unverified

observed roster ENUMERATED ONLY — drift not assessed, no prior attestation to diff against. 3 write-capable: admin:karimalsalah, admin:usephedm, write:KarimCoSpace method gh api -X GET repos/karimalsalah/steadywrk/collaborators -f affiliation=all -f per_page=100 -> filter permissions to write|maintain|admin, sort

observed prod=9b51b45 via /standing-ledger (HTML, BUILD_HASH); main=9b51b45127b4945665cf1937cc0a93b8c59e438f via gh/ls-remote; 9b51b45 is a prefix of 9b51b45127b4945665cf1937cc0a93b8c59e438f. Silent: /api/health 200 body={"status":"ok"} (no build field); no build header among 7 candidates method GET /api/health (JSON + build headers: both silent by design) then GET /standing-ledger for BUILD_HASH; compared against `gh api repos/<repo>/commits/main --jq .sha` (fallback `git ls-remote`)

observed alert enumeration failed: HTTP 403 / Dependabot alerts disabled for this repository. Not reported as zero open alerts. method gh api -X GET repos/karimalsalah/steadywrk/dependabot/alerts -f state=open -f per_page=100 -> count by security_advisory.severity reason alerts_endpoint_unavailable_or_disabled

observed could not read the authenticated user record: gh exit 1: gh: Resource not accessible by integration (HTTP 403) method gh api -X GET user -> .login + .two_factor_authentication (compared against repo owner karimalsalah) reason user_endpoint_unreadable

What the three verdicts mean

The run these verdicts came from

Every control, with its limits

Authentication gate refuses unauthenticated callers

What this LIVE verdict establishes

Recompute this page yourself

Looking for something else?

What it does not prove, even when LIVE

Internal employee API prefix is sealed from the public internet

What this LIVE verdict establishes

What it does not prove, even when LIVE

Production serves the security response headers

What this LIVE verdict establishes

What it does not prove, even when LIVE

Published receipt chain recomputes from genesis to head

What this LIVE verdict establishes

What it does not prove, even when LIVE

Content-ledger feed states its own limits and recomputes

What LIVE would establish — this run did not

What it does not prove, even when LIVE

DID document serves a resolvable, parseable key

What this LIVE verdict establishes

What it does not prove, even when LIVE

Default branch is protected

What LIVE would establish — this run did not

What it does not prove, even when LIVE

CI runs on infrastructure the estate controls

What LIVE would establish — this run did not

What it does not prove, even when LIVE

Secret-scanning gate is present and able to fail

What this LIVE verdict establishes

What it does not prove, even when LIVE

GitHub Actions metered spend is inside the estate cap

What LIVE would establish — this run did not

What it does not prove, even when LIVE

Repository write access roster is known and unchanged

What this LIVE verdict establishes

What it does not prove, even when LIVE

Production serves the current main commit

What this LIVE verdict establishes

What it does not prove, even when LIVE

Vulnerability backlog on the default branch is counted and bounded

What LIVE would establish — this run did not

What it does not prove, even when LIVE

The account that owns production has MFA enabled

What LIVE would establish — this run did not

What it does not prove, even when LIVE