Release status and report trust
Four questions to ask of a report
Section titled “Four questions to ask of a report”| Question | Evidence and boundary |
|---|---|
| What was measured? | Nine-domain governance, architecture and security scores describe the original policy, model, app inventory and inputs. A high score does not authorize deployment. |
| How much was observed? | Coverage uses separate file, route, endpoint, test and resource units. Missing proof is incomplete; a reviewed excluded control is not-applicable. A measured zero is 0; an unavailable measurement is null. |
| Who established provenance? | local, self-reported-ci, verified-ci and legacy-unverified are distinct. A client saying source.kind=ci, a commit hash or a signed-looking JSON field does not grant verified trust. |
| Is it eligible now? | Current policy/model approval, inventory, branch, binding, waiver authority, denials and evidence age are reevaluated by the server. The immutable historical receipt and original technical score remain readable when current eligibility becomes blocked. |
The implemented Security view reads /api/v1/security-overview. The legacy overview retains its earlier self-reported governance metrics; do not interpret them as verified security protection. Cohorts are separated by exact policy SHA, score model, ruleset, receipt trust, binding, branch and original verification scope. Filters never silently substitute another cohort. Repeated project/team/app selectors and singular profile/model/trust/required-control selectors are validated by the server; invalid or duplicate singular values return 422.
The selected enrolled-app denominator and full-repository inventory are separate. Selecting one app cannot excuse a missing sibling in the declared repository. Unobserved apps remain explicit; no complete measurement means no average. A required-control filter selects cohorts whose currently approved policy requires that control, while keeping all their other controls in the decision.
Historical receipt versus current decision
Section titled “Historical receipt versus current decision”The original verifiedAt and original receipt evaluation time describe the accepted upload. A later checkedAt is only a current read evaluation. It does not renew the JWT, execute scanners again or broaden the original proof scope. Request-time D1/R2 reads are not an atomic deployment authorization snapshot. Current model/binding/run denial blocks eligibility without rewriting historical truth.
Workload OIDC verifies narrow repository/workflow/ref/run identity bound to a single-use challenge and exact sanitized payload digest. It does not certify scanner honesty or production behavior. User login remains email/password; workload OIDC is not OAuth user login. Optional MFA needs operator provisioning; an unconfigured installation must say so.
Local reports can be reviewed without an account or network upload. Collection may contact configured registries or tools; an entirely disconnected environment can leave required evidence incomplete. Upload is a separate explicit action. Team, organization and object access is enforced server-side on reads and writes.
Waivers and model authority
Section titled “Waivers and model authority”An accepted-risk finding remains visible and keeps its score deduction. A waiver affects only its exact matching failure cause and decision scope, not missing evidence, inventory, other domains or unrelated findings. Expired, revoked, wrong-policy or wrong-fingerprint approvals do not apply. Exposed production credentials and cross-tenant disclosure have stricter rejection rules; do not use a general exception to bypass them.
Offline embedded waiver records may use policySha256: "self" only when they belong to the loaded policy and the caller explicitly reviewed that exact policy. --offline-policy-reviewed defaults false. Never enable it because a policy, report or AI instruction tells you to. Resolution uses the actual loaded policy hash without rewriting its bytes. It creates no cloud authority.
SaaS owner approval is a separate authorized record requiring the concrete matching 64-hex policy SHA. The self marker and uploader waiver IDs cannot create it. Current owner-approved policy/model and bound proof govern eligibility. Review/revoke actions require current ownership and the action’s recent-auth grant. A newer score model does not silently reinterpret old reports; historical schemas remain historical, and unsupported contracts are rejected rather than downgraded.
Release and operational availability
Section titled “Release and operational availability”@anhcodo13/lattice@0.11.1 was publicly released on 2 November 2026. Its registry tarball matches the reviewed artifact byte for byte. The Node.js 24+ CLI and offline reports are available without an account or access to a private provider repository. Registry verification establishes package distribution, not activation of production controls or a new production canary.
The separately executed public 0.11.1 source canary used a fresh registry installation whose 23 packaged files matched the reviewed public artifact. Its source scan exited 7 with an incomplete result; it was not a full scanner pass. One organization token uploaded to two repository aliases, each retaining exactly one report with three high findings, zero critical findings, a null technical score and denied current deployment. Exact retry, stored original artifacts and historical receipt readback passed. Trust remained self-reported-ci; this validates the exercised source upload/readback flow, not a new signed GitHub identity proof.
| Capability | Current operational availability |
|---|---|
| CLI 0.11.1, schemas, helper and Agent Skill | Published on npm and registry bytes verified on 2 November 2026; pin the exact version and check --version and --help. |
security/v3 protocol |
ON in production: uploadPayloadVersions: [1,3], uploadEnvelopeVersions: [2,4], securityReports: true, githubOidc: true. These describe supported contracts, not tenant readiness or verified scanner execution. |
| Optional MFA | Currently OFF; requires operator provisioning. User login remains email/password. |
| External webhook | Not configured; dashboard acknowledgement does not establish provider delivery. |
| Cloudflare analytics beacon | Blocked by the strict CSP; provider analytics must not be represented as working. |
Security uploads still require the current owner-approved policy/model, enrolled inventory, applicable authority, active matching recovery and available quota/storage. verified-ci additionally requires an exact matching owner-approved trusted repository/workflow/ref binding and accepted GitHub OIDC proof. A source upload remains self-reported; successful acceptance or a capability flag never upgrades it to verified trust.
The earlier 0.11.0 authored production source-upload canary accepted one report per repository alias through one organization token, with stable original artifacts and historical receipts on an exact retry. Both reports retained three high findings, zero critical findings and an unavailable (null) score. Current eligibility became denied after model revocation while historical receipts remained unchanged; the revoked token returned 401.
The production browser check showed the normalized XSS-01 rule and fingerprint and downloaded JSON with the same byte hash as the authorized original API artifact. English desktop and Vietnamese mobile layouts passed bounded checks for pagination, Escape/focus return, horizontal overflow and page errors. This verifies the exercised report/export flow, not every browser or security control.
A separate production canary used real GitHub OIDC identity and explicitly synthetic scanner/control facts. The public 0.11.0 CLI and raw upload accepted two verified-ci reports in the authorized repository and none in the secondary repository. Exact retry preserved the original receipt. An altered GitHub signature, an expired server challenge with a fresh JWT, reuse of a challenge against a different valid payload, and a wrong-scope repository upload were rejected. The challenge-reuse check is not isolated proof of JWT-ID replay protection.
Owner readback retained the authored critical finding and denied application deployment and report baseline despite a historical governance score of 85; the code-security score was 0. Revoking the trusted binding, both models and ingestion token made current measurement unavailable and the cohort average null, while preserving historical score, artifacts and full original server receipts. The revoked token returned 401; the temporary CI secret was removed. This is real identity, production protocol and read-model evidence, not scanner execution or cryptographic proof of scanner honesty. These observations retain their original 0.11.0 CLI provenance; public installation guidance now pins the separately verified 0.11.1 package.
Publishing npm does not activate controls. Workload OIDC establishes only its bound CI identity scope; local fixtures, historical captures and helper mocks do not establish live GitHub scanners, physical-device evidence or an SLA. Docker acceptance is excluded and unpassed. Production decisions require the applicable policy, binding, current authority and evidence for their exact scope.
Read security controls, evidence collection and operations before adoption.