RealPGRESEARCH CHRONICLE · 読むための記録
動く部品どうしの受け渡しが、結果を失敗させるとき
観測したこと
いまの解釈
残る不明点
次の確認
何が起きたか
個々の部品が動いていても、受け渡しがずれると意図した結果には届きませんでした。この記録は、実装そのものより部品どうしのつながりが失敗の中心になった場面を追っています。
どう考えているか
問題は一つの部品の出来ではなく、情報や判断や結果が次へ正しく渡るかにあります。つながりを確かめることが、実際の仕事では重要になると考えています。
まだ分からないこと
この問題がRealPG以外でも同じように重要か、どの受け渡しを優先すべきかは未検証です。
次に確かめること
動く部品の間で結果が食い違った事例を比べ、早く見つけられる確認を試します。
なぜ重要か
部分ごとの成功を、全体の成功だと早合点しないためです。
技術的な記録と証拠 / Technical provenance and evidence references
RESEARCH CHRONICLE · 2026-09-03–2026-09-04 · CURRENT
コードが安くなるほど、統合がfrontierになった
この記録が追っているのは、なぜ実装そのものより、現在のCompany Realityへ正しく接続する境界が主要な失敗源になったのか。
出発点では、個別のcomponentが動けば結果も正しいと見えた。 そこへ「outbound_submitted Realityとruntime outcome truthが食い違った。」という圧力が加わった。ここでは後から整った制度を過去へ遡って完成扱いせず、当時から残るevidenceと現在のcanonical recordを分けて読む。
現在の解釈では、Integrationはcurrentness・ownership・runtime・evidence・completion semanticsが交わるため、first-classなCompany problemである。 ただし、このpatternがRealPG以外へどこまで一般化するかは未証明である。 この未解決点を残したまま、次のverificationへ進む。
研究課題
なぜ実装そのものより、現在のCompany Realityへ正しく接続する境界が主要な失敗源になったのか。
以前と圧力
以前はどうだったか
個別のcomponentが動けば結果も正しいと見えた。
何が足りなくなったか
outbound_submitted Realityとruntime outcome truthが食い違った。
観察したこと
naive retryはduplicate external effectを作りうる。
- Cross-Lane workでは、技術的に正しいChangeでもownerが誤って割り当てられる例が露出した。
- implementationが正しく見えても、live caller stateがintegration snapshotと異なる場合があった。
- 有効にacceptedされたProduct Changeでも、completion recordがdownstream reconciliation contractと合わないとProductionへ到達できなかった。
- 一つのLaneがstable contractではなく別Lane sourceへ直接依存すると、Cross-Lane validationが壊れやすくなった。
そこから推論したこと
side effect、settlement、outcome truth、canonical pathは別の関心事である。
- Integrationはcurrentness・ownership・runtime・evidence・completion semanticsが交わるため、first-classなCompany problemである。
- implementationが安くなるほど、曖昧なboundaryの相対コストが大きくなる。
- Shared integration substrateへ昇格させるのは、同じboundaryが複数Objectiveを繰り返しblockするとRealityが示した後でよい。
どう進んだか
- OWNER_MISMATCHresearch boundary
application:v6:application-origin-target-enforcement-rendezvous:20260829 - CURRENTNESS_MISMATCHresearch boundary
machine:nagi-invocation-bound-preflight-reality:v0:20260829 - COMPLETION_MISMATCHresearch boundary
mirage:v12:lane-local-receipt-production-reconciler-gap:v0:20260902 - CROSS_LANE_COUPLINGresearch boundary
mirage:v13:lane-local-validation-must-not-require-application-source:v0:20260904
変えたこと
- 境界を切り分けてcanonical pathを追跡した。
- Ownershipとcurrentnessをassumptionではなくexplicit checkとして扱うようになった。
- Completion recordをbookkeepingではなくexecutable integrationの一部として扱うようになった。
- Cross-Lane reuseはdirect source dependencyよりstable contractへ寄った。
- Current Contextを、あらゆるlive stateの代替ではなくbounded projectionとして扱い始めた。
その後どう変わったか
- 統合上の失敗を観察したが、throughput改善は未証明。
変えなかったこと
- Local implementation qualityとtestは引き続き必要である。
- 一回限りのintegration frictionだけでgeneric platform abstractionを正当化しない。
まだ分からないこと
まだ検証できていない: later repairs improve throughput.
- このpatternがRealPG以外へどこまで一般化するかは未証明である。
- どのboundaryをshared substrateにし、どれをlocal repairに留めるべきかは、再発evidenceが必要である。
Counter / 注意点
- 通常のlocal bugとして正しくlocal repairされたfailureもある。
- 早すぎるintegration abstractionは、取り除く以上のcoordination costを追加しうる。
次に確かめること
一つのcanonical pathを再実行し、修理後の結果を判定する。
- Objective Lineageが複数domainでHuman reconnectionを減らすか測る。
- 複数Objectiveで繰り返したboundary failureだけをshared substrateへ昇格させる。
なぜ重要か
副作用と結果を同じ成功指標にしない。
このstatusは成功宣言ではなく、canonical recordの現在位置を示す。
証拠とprovenance
application:v6:application-origin-target-enforcement-rendezvous:20260829machine:nagi-invocation-bound-preflight-reality:v0:20260829mirage:v12:lane-local-receipt-production-reconciler-gap:v0:20260902mirage:v13:lane-local-validation-must-not-require-application-source:v0:20260904iris:v1:context-institution-effective-policy-projection:v0:20260906learning:nagi:v8:jane-outbound-submitted-reconciles-runtime-failed:v0:20260904learning:nagi:v8:application-mail-transport-service-boundary:v0:20260903
When handoffs between working parts still fail the result
RESEARCH CHRONICLE · A record for reading
Observed
Interpretation
Unknown
Next check
What happened
Individual parts worked, yet the intended result still failed when their handoffs did not line up. This record follows the point at which the connections between components became a larger source of failure than writing the components themselves.
What we think it means
The question is not only whether each part works. Information, decisions, and outcomes also have to reach the next part correctly.
What remains unknown
It remains unproven how broadly this pattern applies beyond RealPG and which handoffs deserve attention first.
What we will check next
We will compare cases where working parts produced mismatched results and test earlier ways to spot the break.
Why it matters
Success in separate pieces should not be mistaken for success of the whole job.
Technical provenance and evidence references
RESEARCH CHRONICLE · 2026-09-03–2026-09-04 · CURRENT
As code got cheaper, integration became the frontier
This episode asks: Why did connecting correct components into current Company Reality become a larger failure source than implementation itself?
The starting point was that working components appeared to imply a correct outcome. The pressure became explicit: outbound_submitted Reality and runtime outcome truth disagreed. The article keeps later institutional interpretation separate from evidence that actually remains from the period.
The current interpretation is that integration is a first-class Company problem because currentness, ownership, runtime, evidence, and completion semantics meet there. But how much of this pattern generalizes beyond RealPG remains unproven. That uncertainty remains part of the record rather than being edited out as the work becomes more readable.
Research question
Why did connecting correct components into current Company Reality become a larger failure source than implementation itself?
Before / pressure
Prior state
Working components appeared to imply a correct outcome.
Failure or pressure
outbound_submitted Reality and runtime outcome truth disagreed.
Observations / What we observed
A naive retry could create duplicate external effects.
- Cross-Lane work exposed cases where a technically valid change was assigned to the wrong owner.
- Live caller state could differ from the integration snapshot even when the implementation looked correct.
- A valid accepted Product change could fail to reach Production when its completion record did not match the downstream reconciliation contract.
- Cross-Lane validation became brittle when one Lane depended directly on another Lane source instead of a stable contract.
Hypotheses / Inferences
Side effect, settlement, outcome truth, and canonical path are separate concerns.
- Integration is a first-class Company problem because currentness, ownership, runtime, evidence, and completion semantics meet there.
- As implementation gets cheaper, the relative cost of ambiguous boundaries increases.
- Shared integration substrate should be promoted only after repeated Reality shows the same boundary is blocking multiple Objectives.
How it unfolded
- OWNER_MISMATCHresearch boundary
application:v6:application-origin-target-enforcement-rendezvous:20260829 - CURRENTNESS_MISMATCHresearch boundary
machine:nagi-invocation-bound-preflight-reality:v0:20260829 - COMPLETION_MISMATCHresearch boundary
mirage:v12:lane-local-receipt-production-reconciler-gap:v0:20260902 - CROSS_LANE_COUPLINGresearch boundary
mirage:v13:lane-local-validation-must-not-require-application-source:v0:20260904
Interventions / What changed
- Separated the seams and traced the canonical path.
- Ownership and currentness became explicit checks instead of assumptions.
- Completion records became part of executable integration rather than bookkeeping.
- Cross-Lane reuse moved toward stable contracts instead of direct source dependency.
- Current Context began to be treated as a bounded projection rather than a substitute for every live state.
Outcomes
- An integration failure was observed; throughput improvement remains unproven.
What did not change
- Local implementation quality and tests remain necessary.
- One-off integration friction is not enough to justify a generic platform abstraction.
Unknowns / What remains unknown
Not yet verified: whether later repairs improve throughput.
- How much of this pattern generalizes beyond RealPG remains unproven.
- Which boundaries deserve shared substrate versus local repair still requires recurrence evidence.
Counter-evidence / cautions
- Some failures remained ordinary local bugs and were correctly repaired locally.
- Premature integration abstraction can add more coordination cost than it removes.
Next verification
Replay one canonical path under separately established authority.
- Measure whether Objective Lineage reduces Human reconnection across multiple domains.
- Promote only repeated cross-objective boundary failures into shared substrate.
Why it matters / Why this matters
It keeps side effects and truthful outcomes from becoming one success metric.
The status marks the position of the canonical record; it is not a success claim.
Evidence / provenance
application:v6:application-origin-target-enforcement-rendezvous:20260829machine:nagi-invocation-bound-preflight-reality:v0:20260829mirage:v12:lane-local-receipt-production-reconciler-gap:v0:20260902mirage:v13:lane-local-validation-must-not-require-application-source:v0:20260904iris:v1:context-institution-effective-policy-projection:v0:20260906learning:nagi:v8:jane-outbound-submitted-reconciles-runtime-failed:v0:20260904learning:nagi:v8:application-mail-transport-service-boundary:v0:20260903