What a Release Certificate Actually Proves at Ethen

A PASS heading is a scope statement: what was checked, on which tree and deployment, on which date — and what was explicitly left out.

Most release notes answer one question: is it out? An Ethen release certificate answers a narrower set of questions: which gates ran, against which source tree or deployment, on what date, and with what result. That distinction matters because the three kinds of evidence in a certificate — build evidence, authenticated-workflow evidence, and public-activation evidence — have different scopes, different failure modes, and different expiry dates. Confusing one for another turns a careful engineering record into an availability claim nobody actually verified.

This article walks through three real certificates — the Chat production release of September 17, 2026, the Designer standalone-app correction checkpoint, and the Studio V2 final closure — and shows how to read each line for what it proves and what it leaves open. Every certificate discussed here is a historical report: it proves only its dated scope. Nothing in this article should be read as a claim that any product is currently launched or publicly available.

A certificate is a dated scope, not a launch announcement

Ethen release certification works like a lab notebook entry. Each certificate names the thing under test (a branch and commit, a deployment ID, a local app port), lists the checks that ran, and records the outcome of each check in plain words: PASS, PARTIAL, NOT_RUN, NOT_PERFORMED, or OPEN. The overall status — sometimes PASS, sometimes PARTIAL — summarizes only those checks. It says nothing about other products, other environments, or any date after the one on the report.

Three habits make this reading stick. First, always check the status word next to the specific line you care about, not just the headline. A certificate can carry a PASS headline for one scope while a different scope inside it reads PARTIAL or NOT_PERFORMED. Second, note the identity of the artifact: a commit hash, a deployment ID, a project name. Evidence attaches to that artifact, not to the product name in general. Third, read the limits and follow-ups section as part of the verdict. The items listed there — untested flows, undecided configuration, work awaiting an owner action — are the boundary of the proof.

The three certificates below each demonstrate a different combination. Chat pairs strong build evidence with partial authentication evidence and a split public-activation picture. Designer pairs a PASS on standalone-app identity with an explicit NOT_PERFORMED on public activation. Studio pairs passing code gates with a PARTIAL overall status because most of the browser matrix is still waiting on an enrolled-login fixture. None of them claims all-products availability, and none of them should be quoted that way.

The three scopes, and why they stay separate

Before the examples, it helps to name the three scopes precisely, because every Ethen certificate separates them even when they appear in one document.

Build evidence answers: does this source tree compile, pass its checks, and produce a working build? It runs on a specific working tree — a branch, a commit, a Node version — and covers typechecks, builds, unit and behavioral test suites, and static policy checks. Build evidence is the cheapest to reproduce and the fastest to expire: the next commit can change it. It also says nothing about who can reach the result.

Authenticated-workflow evidence answers: do the signed-in paths behave correctly for a real user? This scope needs something build evidence does not: a test account, an enrolled session, or a stored login fixture. Without that credential material, signed-in flows cannot be exercised honestly, and the certificate must say so — usually with PARTIAL or NOT_RUN markers — rather than inferring success from the fact that the build passed. This is the scope most often misread, because a green build feels like proof that the app "works," when in fact nobody has yet logged in.

Public-activation evidence answers: can the intended public audience reach the intended host and use the intended entry points? This scope lives outside the code tree: DNS aliases, deployment protection settings, canonical-host decisions, enrollment gates, and kill switches. It can change without any code changing at all — an alias can be moved, a protection setting can be tightened — and it usually requires an explicit owner decision. A separate authorization is the norm, which is why certificates record activation as its own line with its own status.

Keeping these scopes separate protects both directions. It stops a green build from being oversold as a launch, and it stops a blocked activation from being misread as broken code. The Chat, Designer, and Studio certificates each show one side of that protection.

Chat, September 17: a green build, a partial auth pass, and two hosts

The Chat production release certificate dated September 17, 2026, is the longest of the three, and the best illustration of why the scopes must be read independently. It records a certified build, a controlled Vercel release, and a production smoke test — three phases, each with its own verdict.

The build phase is the strongest part of the report. On branch ethen/v5 at commit f3a7fb22, with Node v22.23.2, the certificate records TYPECHECK=PASS and BUILD=PASS for the @ethen/chat-core package, with routes including /chat, /settings, /upgrade, the sign-in and sign-up pages, and the chat, models, settings, voice, projects, and artifacts API routes. The behavioral suites passed with zero failures: 268 of 268 in the core 19-file Chat closure set, and 300 passed with 4 pre-existing skips in the extended 26-file Chat-adjacent set. The report is careful about a discrepancy it found: an earlier uncertified claim of 293 of 293 could not be reproduced because no 293-baseline manifest exists in the repository, so the certificate records the suites it actually measured instead of inheriting the old number. Supporting policy gates — voice Permissions-Policy headers, settings consistency, 128 of 128 disconnected-settings assertions, truthful paid-flow state, and a 195-file migration tripwire — all read PASS, with zero P0 or P1 blockers.

So far, this is build evidence at its best: specific, measured, and honest about the one number it could not reproduce. But build evidence is where its authority ends. The certificate then moves to the release phase, and the picture gets more qualified.

The Vercel release targeted project ethen-chat-core with its root at apps/chat-core, and the deployment itself reached READY. The public-activation story, however, split across two aliases. The mandated host, chat.upcube.ai, had its alias restored to the new deployment — but every route on it returned a redirect to Vercel SSO, because project-level Deployment Protection gates that domain. The report notes this was pre-existing, not caused by the deploy, and that public users could not reach the app through that host until the owner decides to relax the protection. Meanwhile a second alias on the same deployment served public traffic correctly: the root returned 200 with the "Ethen Chat" title, protected pages redirected signed-out visitors to sign-in with a return URL, and the models API returned a 401 JSON denial for signed-out callers. Same deployment, same code, two different activation outcomes — determined entirely by configuration outside the tree. The canonical-host decision was explicitly left to the owner.

The authenticated-workflow scope is where the certificate is most disciplined. Its verdict is AUTH_PRODUCTION_SMOKE=PARTIAL. The signed-out boundary was proven correct on every protected route and API: 307 page redirects with return URLs, 401 JSON on API calls, correct voice headers on live responses, zero JavaScript exceptions, zero hydration errors, and responsive layouts with no overflow at mobile and desktop widths. But every signed-in flow — live send and stream, persistence across reload, the model picker interaction, authenticated settings content, the account menu, and upgrade purchase state — reads PARTIAL or NOT_RUN, because no test account was available and the team declined to hammer providers or fabricate sessions. The three console errors observed were the by-design 401 responses from signed-out prefetch calls, not defects. The certificate lists the untested follow-ups plainly — two-user isolation, real onboarding and expiry, connector OAuth, artifact recovery, screen-reader certification, cache endurance, gateway capacity — as NOT retested and NOT claimed.

Read as a whole, the Chat certificate proves a great deal about September 17 and nothing beyond it: a specific commit built cleanly and passed its suites; a specific deployment served correctly on one public alias while the mandated host stayed behind SSO; and the signed-out boundary held while signed-in behavior awaited an authenticated pass. Quoting its PASS lines as proof that Chat is publicly available today would erase every qualification the report took care to record.

Designer: what a PASS means when activation is NOT_PERFORMED

The Designer standalone-app correction checkpoint is shorter, and its headline status is PASS — which makes it the most instructive example of why headlines must never be quoted alone. Directly beneath the PASS lines sits an equally binding line: PUBLIC_ACTIVATION=NOT_PERFORMED. The certificate proves an ownership correction and a recertification of moved code. It proves nothing about public availability, and it says so.

The correction itself was architectural. Designer had been entangled with a Creative app and shared workspace shells; the checkpoint records the owner decision that Designer is a first-class standalone Next.js app — package @ethen/designer, run from apps/designer, served locally on port 3014 — and not a route inside Creative or any shell. The evidence for that claim is concrete: an 82-file domain library, the component tree, 24 API routes, and the home page were moved byte-identically with git mv; shells, layout, error, loading, and not-found pages were rewritten for standalone operation; landing imports were replaced with native equivalents; one zero-importer orphan was deleted with history preserved; and the old monolith route became a dev-redirect and handoff-link compatibility page. Registry lifecycle behavior was left untouched, and environment files arrived through gitignored symlinks.

The recertification battery then re-proved the moved code rather than inheriting trust from its old location. Both the Designer and Creative typechecks came back clean with zero new root errors; lint showed only pre-existing warnings on moved files; and the moved suites passed in full — bridge 25 of 25, local 8 of 8, managed 6 of 6, gateway 10 of 10, release 7 of 7, transport 5 of 5, plus the 06, 07, 08, 09, and 11 suites and dozens of neighbor checks. Live checks against port 3014 confirmed home markers, tab switching, zero overflow from 390 to 1440 pixels, zero accessibility violations on the sampled pass, overlay focus trapping, honest unknown-document handling, and API auth gating, with no sandbox or database residue. Placeholder quality-assessment envelopes found during the work were repaired to "unmeasured" in both trees and regression-locked.

Just as important is what the checkpoint invalidated and what it fenced off. Prior 07 and 08 architecture claims that described the old entangled layout were appended as invalidated history — preserved, not rewritten — so future readers can see what changed and why. The limits section records that local file-store scopes follow each app's working directory, that the golden series was not re-run (with a recorded rationale about unchanged subject bytes rather than an inheritance claim), and that residual items like variant subscores and declared mocks await a follow-up pass. The next safe action is an owner review at the local port; public activation and paid allowances are named as new scope needing their own authorization.

This is Ethen release certification doing exactly what it should: the FINAL_CERTIFICATION=PASS line certifies the correction and the moved-code battery, while PUBLIC_ACTIVATION=NOT_PERFORMED fences off everything the team did not do. A reader who quotes the PASS without the NOT_PERFORMED inverts the document's meaning. The honest summary is one sentence long: as of this checkpoint, Designer is a standalone app whose moved code passes its suites locally, and nobody has yet activated it publicly.

Studio: why PARTIAL is a complete and honest verdict

The Studio V2 final closure certificate carries the headline JOB_STATUS=PARTIAL — and it is the clearest demonstration that PARTIAL is not a euphemism for failure. It is a precise statement that code gates passed while most of the authenticated browser matrix honestly awaits a login fixture only the owner can create.

The passing half is substantial. CODE_GATES=PASS covers 80 registered routes (27 pages, 53 API) with zero route hijacks, 429 of 429 STU34 assertions, 36 of 36 boundary checks, passing STU31, 42 of 42 STU32, and 63 of 63 STU33, plus clean BUILD and TYPECHECK. The job also closed two real blockers. The first was a genuine product bug: the standalone apps/studio had no edge gate, so non-enrolled browsers loaded the workbench with an HTTP 200. The fix — a new proxy.ts plus a server-side access guard with canonical denial states, operator allowlist enrollment, and readiness and kill parity with the monolith — was proven live: anonymous requests to the Studio entry and workbench APIs now return 401 with no Studio navigation or chrome, while public review, health, root, and auth entries stay public. The second was a test-contract fix scoping one bogus review-token 403 as an expected denial for that case only, with all other console errors still failing. Both fixes are the kind of evidence that only authenticated-or-not browser proof can supply — and the certificate is careful to say which half it has.

The waiting half is where the PARTIAL comes from. The enrolled-authentication fixture reads WAITING_FOR_OWNER_LOGIN, and the release-verification item that depends on it reads OPEN_WAITING_FOR_AUTH_FIXTURE. The browser matrix stands at 1 passed, 0 failed, and 87 skipped across 88 total — with every skip explicitly marked as awaiting the fixture rather than silently dropped. The private-alpha access-control line captures the split exactly: PASS on code plus anonymous-browser proof, with the enrolled half still pending. The remaining step is owner action only — create the enrolled login state, then rerun the matrix — with no code work left for it.

The certificate's no-fake-pass ledger deserves emphasis because it shows what Ethen release certification refuses to do. No fabricated session, no hardcoded user, no disabled gating, no mass skip, no global ignore of 403s, no removed lifecycle checks, no public Studio, no static inspection presented as browser proof — and no push, merge, or deploy performed. The 87 authenticated skips are explicit fixture waits, and the historical Job 13 series certificates stay preserved as PARTIAL rather than rewritten. When the owner login lands and the matrix reruns, that rerun will be new dated evidence; until then, the honest verdict is PARTIAL, and the certificate says so at the top.

How to read the next certificate you see

With the three examples in hand, a short reading checklist covers most cases:

1. Start with the status words, all of them. Collect every PASS, PARTIAL, NOT_RUN, NOT_PERFORMED, WAITING, and OPEN line before forming a conclusion. In the Chat report, BUILD=PASS and AUTH_PRODUCTION_SMOKE=PARTIAL coexist; in Designer, FINAL_CERTIFICATION=PASS coexists with PUBLIC_ACTIVATION=NOT_PERFORMED; in Studio, CODE_GATES=PASS coexists with JOB_STATUS=PARTIAL. The document's meaning is the set, not the headline.
2. Attach each claim to its artifact and date. Chat's build evidence belongs to commit f3a7fb22 on September 17; its serving evidence belongs to one deployment ID and two named aliases; Designer's battery belongs to moved code verified at a local port; Studio's gate fix belongs to a specific proxy-and-guard change proven against anonymous browsers. Move any of those claims to a different commit, deployment, or date and the evidence no longer applies.
3. Treat NOT_RUN and WAITING as information, not gaps in rigor. Chat's unsigned-in send and stream paths, Studio's 87 enrolled-browser skips, and Designer's deferred activation each record a deliberate refusal to fabricate what was not measured. A certificate with honest NOT_RUN lines is more trustworthy than a blanket PASS with no scope lines at all.
4. Read limits and follow-ups as part of the verdict. Unretested capacity, undecided canonical hosts, cosmetic dashboard names, concurrent-work hazards, unmeasured variant subscores — these are the documented boundary of the proof. They tell the next owner exactly what to verify before extending any claim.
5. Never cross product or scope boundaries. A PASS for apps/chat-core says nothing about apps/studio or apps/designer, and a standalone-app PASS says nothing about public activation. Chat is a deliberately limited surface while Studio, Research, Designer, and Founder are separate target apps — but that separation is a design fact, not evidence that any migration or launch has shipped. Roadmap and implementation stay in different sentences.

One more caution applies to every certificate: configuration evidence expires fastest. Deployment protection, aliases, enrollment lists, and kill switches can all change without a commit, so activation lines should always be re-verified close to the moment they matter. Build evidence goes stale with the next merge; activation evidence can go stale with a settings click.

The point of the paperwork

Release certificates exist so that confidence can be audited later. When someone asks what was actually proven — which suites ran, which boundary was checked in a real browser, which host served which deployment, which flows still need a login — the answer should be a dated document with line-level verdicts, not a memory of a green headline. The Chat, Designer, and Studio certificates each model that discipline differently: Chat by splitting a READY deployment from an SSO-walled host and a PARTIAL auth pass, Designer by pairing a correction PASS with an explicit NOT_PERFORMED on activation, and Studio by wearing PARTIAL at the top while its code gates pass underneath.

The next time you see an Ethen release certificate, read it the way its authors wrote it: scope by scope, artifact by artifact, date by date. What it proves is exactly what its lines say — and what makes it trustworthy is everything it refuses to claim.