PUBLIC DEVELOPMENT · DEVELOPMENT NOTE 01 · AS OF 2026-09-12

The week one email became a test of the whole company

One bounded record of a canonical outbound-mail objective. It distinguishes what Reality exposed from the interpretation of that evidence. It is not a claim that the objective is closed.

OBJECTIVEProve that one current candidate can move through exact review and authorization, Company Runtime, mail transport, and truthful outcome recording as one canonical Objective without Human stitching between stages.

BOUNDARYThis note creates no SEND or external-action authority. Reality Evidence remains a separate, read-only subsystem.

Observed

By 2026-09-03, four commercial messages already had outbound_submitted Reality. SMTP and OwnedMail were not an unproven transport from scratch.
At the same time, some messages could be externally submitted while Company Runtime still settled as failed, so transport side effect and system outcome truth were inconsistent.
Replaying one canonical message exposed boundaries in sequence: exact candidate reads, owner rendezvous, production migrations, Change Pipeline deletion and rename handling, deterministic processor drain state, and Supabase CLI observation/parsing.
As of 2026-09-12, mail Reality still contains no newer commercial outbound event after September 3. A second canonical message has not yet re-proven the path in external Reality.

Hypotheses / interpretation

The main problem was less the ability to send mail than preserving Objective continuity, exact identity across boundaries, processor liveness, and truthful outcomes as one company.
A successful local repair is not Objective success. After a repair, the system must return to the parent Objective and re-observe the required Reality.
Not every platform improvement should block one message. Only improvements required for safety or outcome truth should be promoted onto the critical path.

Interventions

The company froze a one-message canonical E2E Objective instead of adding another batch execution path.
Exact Learning-candidate reads and owner-rendezvous transport were added so selected supply could be carried by exact identity rather than latest-N or prose discovery.
Production migration convergence moved away from guessed history repair toward an epoch, bounded parser evidence, and fail-closed repairs.
Gaps in the Change Pipeline, rename authority, processor/drain handling, and CLI parsing were treated as bounded repairs followed by replay of the original Objective.

Outcomes

Mail transport itself has already been proven to externalize messages in Reality.
The canonical effort made company-wide liveness and control-plane gaps visible as concrete failure evidence.
But a second canonical message has not yet been externalized, so the repairs have not yet proven an improvement in throughput.

Unknowns

Whether the current source fully resolves the historical outbound_submitted versus runtime-failed mismatch.
Whether the next message is materially cheaper in Human intervention, elapsed time, and repair count than the first canonical cycle.
Which platform improvements are truly required for per-action safety or outcome truth, and which can remain parallel work.

Next verification

When SEND authority is separately established, move exactly one current unsent candidate through the same canonical path and record the packet → operation → runtime job → message → outcome chain, elapsed time, Human interventions, and repair count. If the second run is materially cheaper and faster, the repairs become evidence of learning rather than merely accumulated fixes.

PUBLIC DEVELOPMENT · DEVELOPMENT NOTE 01 · AS OF 2026-09-12

1通のメールが会社全体のテストになった1週間

canonical outbound-mail Objectiveについての、ひとつの限定された記録です。Realityが露出させた事実と、その証拠からの解釈を分けます。Objectiveが完了したという主張ではありません。

OBJECTIVE現在の候補から1件を選び、exactなreview/authorization、Company Runtime、mail transport、結果の記録までを、Humanが途中で継ぎ合わせずに1本のcanonical Objectiveとして通せる状態を証明する。

BOUNDARYこのノートはSENDや外部actionのauthorityを作りません。Reality Evidenceは別のread-only subsystemです。

観測されたこと

2026-09-03には、商用メール4通についてoutbound_submittedのRealityがすでに残っていた。SMTPやOwnedMailが一度も動いていなかったわけではない。
一方で、外部化されたメールがあるのにCompany Runtime側では失敗として終わるケースがあり、transport side effectとsystem outcome truthが一致していなかった。
canonicalな1通を再現しようとすると、exact candidate read、owner rendezvous、production migration、Change Pipelineの削除/rename処理、deterministic processorのdrain状態、Supabase CLIの観測/parseといった境界が順番に露出した。
2026-09-12時点のmail Realityには、9月3日より後の新しいcommercial outbound eventはまだない。canonical pathの2本目はまだ外部Realityで再証明されていない。

仮説 / 解釈

主問題はメール送信能力そのものより、Objective continuity、境界間のexact identity、processor liveness、結果の真実性を一つの会社として保つことにあった。
local repairが成功してもObjectiveが成功したとは限らない。修理後には元のObjectiveへ戻り、必要なRealityを再観測する必要がある。
platform improvementをすべて1通のメールのblockerにしてはいけない。安全性またはoutcome truthに必要なものだけをcritical pathへ昇格させるべき、という仮説が強くなった。

介入

1-message canonical E2EをObjectiveとして固定し、別のbatch execution pathを増やさない方針にした。
exact Learning candidate readとowner rendezvous transportを追加し、selected supplyをlatest-Nやproseではなくexact identityで扱う方向へ寄せた。
production migration historyを推測で直さず、epoch化・bounded parser evidence・fail-closed repairで収束させる方向へ変更した。
Change Pipeline、rename authority、processor/drain、CLI parserで見つかった欠落は、それぞれ局所修理した後に元Objectiveを再試行する方針へ整理した。

結果

メールtransportがRealityで動いたこと自体は既に証明されている。
canonical pathを作る過程で、会社全体のliveness/control-plane上の欠落が具体的なfailure evidenceとして見えるようになった。
ただし2本目のcanonical messageはまだ外部化されておらず、この一連の修理が実際にthroughputを改善したとはまだ言えない。

未知のこと

現在のsourceが、historicalなoutbound_submittedとruntime-failedの不一致を完全に解消したか。
次の1通が、最初のcanonical cycleよりHuman介入・経過時間・repair数の面で本当に安くなるか。
どのplatform improvementがper-action safety/outcome truthに本当に必要で、どれが並行化できるか。

次の検証

別途SEND authorityが成立した時に、現在のunsent candidateを1件だけ同じcanonical pathで通し、packet → operation → runtime job → message → outcomeのchain、経過時間、Human介入回数、repair回数を記録する。2本目が明確に安く・速ければ、今回の修理がlearningに変わった証拠になる。