Skip to main content
Gateway’s source history contains design decisions, database migration work and several local execution experiments. Their value is cumulative learning, but they are not one continuous production release. This chapter explains the important transitions without requiring the reader to know the internal document register.

​
First, clarify responsibility

Early work brought together provider execution, supply selection, streaming, recovery and evidence. Further source review separated Gateway’s inference responsibility from professional commitments, caller-owned results and financial outcomes. That separation prevented an execution engine from quietly becoming a workflow manager. It also clarified that a delivery program is not a runtime actor and that a future ownership transfer does not replace today’s caller just because a diagram names it.

​
Then, make execution boundaries real

Accepted SQL text did not automatically mean the functions parsed or installed correctly. Successful installation did not prove that execution records and native-capacity changes committed atomically. The local work therefore progressed through narrower, observable boundaries: actual transactions, rollback and replay, protected confirmation, then a connected non-streaming path using fake provider transport and real PostgreSQL. This matters because a happy-path answer can conceal the very failures the design is supposed to handle. The hard questions appear when an acknowledgement is lost or when no output should have been released.

​
Streaming exposed ownership and waiting problems

Incremental delivery required more than splitting text into events. The system had to preserve output identity, distinguish liveness from generation progress, bound queues and retain delivery responsibility after provider completion. That work also exposed protected database waits that were not fully covered by the intended lifecycle bounds. The local streaming result was useful, but its qualification remained partial rather than being declared complete for convenience.

​
Caller integration exposed identity and state problems

The separate caller experiment demonstrated useful success, saved-result replay and a tested uncertain timeout path. It also revealed why canonical timestamps, distinct turn identities and explicit non-final state mapping matter. A replay key that works for one repeated frame is not automatically correct for two independent turns. A generic error branch that labels every interruption failed can erase uncertainty that the Gateway record still preserves.

​
Database migration is a separate history

The company core PostgreSQL 17 local-box migration has its own adopted configuration, role model and dated receipts. The advanced Gateway execution-evidence experiments used their own isolated profiles. Those histories inform implementation, but neither can supply the other’s missing deployment or disaster proof. A rollback image identifies an artifact; it does not identify the service running today.

​
The lesson for the next change

Reuse the actual accepted sources and tested boundaries. Preserve failed and partial observations alongside successes. Integrate sibling branches deliberately rather than combining their claims on paper. When ownership or storage changes, carry original identities, saved results and pending obligations through the transition. Bounded tasks, controlled resource use and task-owned cleanup are implementation disciplines, not a reason for the documentation editor to rebuild or operate the system. The final design handoff records these lessons and assigns implementation supplements to their owners. Reader Edition 1.1 changes the explanation and reading experience, not the underlying engineering decisions. See Design trade-offs and Implementation status.