Engineering / Controlled automation
AI workflows with approval at the action boundary.
PostgreSQL-backed workflows with isolated privileges, one-time approvals, action-bound retries and a leased Notion outbox that checks provider state after delivery.
- Context
- Kahla / Internal workflow engineering
- Contribution
- Founder / Workflow & integration engineering
- Project type
- Engineering case study
Scope
Approval-controlled workflows backed by PostgreSQL.
Contribution
Privilege boundaries, approval use, retries and Notion delivery.
Verification
A JSONB Decisions API defect fixed with a PostgreSQL 17 regression test.
01 / The problem
Permission to reason is different from permission to act.
An AI workflow can assemble a useful proposal while still needing a person to approve the external action. The implementation has to preserve that distinction through persistence, privilege boundaries and retries.
AI Office uses PostgreSQL-backed workflows to connect a proposed action to a one-time approval. External delivery passes through an outbox with leases and provider readback, giving the system a defined path for attempts, retries and checking the result.
Privileges need scope
A workflow component should only carry the authority its part of the job requires.
Approvals need identity
A one-time approval must remain tied to the action it authorizes.
Retries need continuity
A repeated attempt must preserve the original action boundary and intended result.
02 / My contribution
Making authorization part of the workflow state.
My work connects PostgreSQL persistence to approval-controlled workflows, with isolated privileges, one-time approvals and retries bound to the authorized action. A leased Notion outbox handles delivery work and checks provider state through readback.
The implementation uses TypeScript, Node.js, Next.js and React, with PostgreSQL for workflow state and Notion as an external delivery integration.
The project history also records a Decisions API HTTP 500 caused by JSONB double encoding, its fix and an added PostgreSQL 17 regression test. That incident account is user-confirmed history; this portfolio update did not rerun the original incident or regression.
Scope authority
Separate privileges and connect approval to a particular proposed action.
Control repeated attempts
Keep retries bound to the approved action and use leases to coordinate outbox work.
Verify persistence behavior
Repair the JSONB representation defect and cover it with a database regression test.
03 / How it works
Reasoning, authorization and delivery stay connected.
Explore the approval contract, the Notion delivery path and the database regression. These are conceptual models of the implementation boundaries.
Proposal → Approval → Authorized action
A decision authorizes a specific action.
The workflow stores the proposed action and its approval relationship rather than treating general access as approval to execute.
Propose action
A proposed action is persisted as workflow state. The proposal can be inspected without treating its existence as permission to make an external change.
Conceptual portfolio reconstruction. No internal decisions, approval records, Notion content or private operational details are shown.
Read all model notes
Approve an action
- Propose action — A proposed action is persisted as workflow state. The proposal can be inspected without treating its existence as permission to make an external change.
- One-time approval — One-time approvals provide a defined authorization boundary. A consumed approval is not a reusable credential for a different action or an open-ended series of changes.
- Action-bound retry — A retry retains the approved action boundary. Repetition should continue the authorized operation rather than silently change its payload or acquire broader permission.
Deliver to Notion
- Persist outbox work — The Notion outbox represents delivery work in PostgreSQL. Persisting the operation makes it available for coordination and recovery independently of a single request’s lifetime.
- Lease the attempt — A lease coordinates processing of an outbox item. It is part of managing retries and interrupted work; it is not a claim that an external provider can never receive a repeated request.
- Read provider state — The workflow reads back provider state after delivery rather than treating an attempted request as sufficient evidence of the intended result. This study does not expose the underlying Notion records.
Fix the JSONB boundary
- Observe failure — JSONB double encoding caused a representation mismatch at the persistence boundary and surfaced as an HTTP 500 in the Decisions API. The issue was a concrete implementation defect, not an inferred reliability score.
- Correct encoding — The repair removed the double-encoding behavior so the stored JSONB representation matched what the Decisions API expected.
- Add regression test — A PostgreSQL 17 regression test was added for the repaired persistence path. That test supports the specific encoding fix; it does not establish that every workflow or external integration is failure-free.
Choose a perspective, then select a stage. Keyboard: arrow keys switch perspectives.
04 / Key decisions
The choices behind the solution.
Tie one-time approval to the action.
Why it mattersAuthorization stays specific and inspectable across workflow steps.
The tradeoffChanged actions require a new authorization decision rather than inheriting a previous approval.
Use a leased outbox and provider readback.
Why it mattersDelivery work needs coordination, recovery and evidence of provider state.
The tradeoffLeases and retries add persisted state and do not create a universal exactly-once guarantee.
Test the JSONB fix against PostgreSQL 17.
Why it mattersThe regression needs to exercise the database representation that caused the API defect.
The tradeoffDatabase integration tests require a real compatible test environment and cover a defined behavior.
05 / What it produced
Explicit controls around useful automation.
The implementation brings PostgreSQL-backed workflow state, isolated privileges, one-time approvals, action-bound retries and a leased Notion outbox with provider readback into a connected delivery path. Private source and regression evidence supports those controls.
The user-confirmed implementation history records the Decisions API JSONB double-encoding defect that produced HTTP 500, its fix and an added PostgreSQL 17 regression test. This study separates that historical account from the workflow controls inspected in source. It does not claim unrestricted autonomous operation, universal exactly-once delivery or verification of every live provider journey.
Approval contract
Persisted action and one-time approval relationships define what may execute.
Notion delivery lifecycle
Outbox state, leases and readback make provider work inspectable across attempts.
Database regression
A PostgreSQL 17 test covers the Decisions API JSONB encoding repair.
Control belongs in the implementation.
Approvals and retries need more than interface labels. They need persisted relationships, privilege boundaries and tests that exercise the failure modes at the storage and provider edges.
Project context & references
2026 · Engineering case study
Private source inspection supports the isolated privileges, approval handshake, action-bound retries, leased Notion outbox and provider readback. The combined Decisions API HTTP 500 incident, JSONB repair and PostgreSQL 17 regression are user-confirmed implementation history, not a regression rerun or independently reproduced incident in this portfolio update. Operational decisions, approval payloads, Notion records, credentials and private repository links are withheld.
Next / Enterprise Infrastructure