Putting AI into a business workflow exposes a gap between finding relevant information and committing an action based on it. Search that works well for product recommendations still needs additional controls before it can support orders or refunds.

In “What ‘AI-Ready’ Actually Means,” published on September 27, 2026, Vibhor Kumar frames readiness as introducing AI while retaining control over data, authority, outcomes, and evidence. This is the author's architectural perspective.

What would that mean for a PostgreSQL application? Following retrieval through authorization, database changes, and external completion reveals which judgments AI can assist with and which conditions the system must enforce.

Product search must distinguish relevance from eligibility

Consider a request for a lightweight, waterproof travel jacket. Semantic retrieval can find relevant products, while SQL applies inventory, price, and shipping constraints. Kumar uses this combination to separate candidate selection from business eligibility.

First, identify which system owns the authoritative price and stock information. A searchable copy of a description does not establish current availability. The design needs to specify which data, at which point in time, determines acceptance.

There is also a retrieval constraint. With approximate indexes such as HNSW, pgvector filters candidates after scanning the index, so selective conditions can reduce the returned count. See the official filtering documentation.

Iterative scans, added in pgvector 0.8.0, search additional candidates, subject to scan limits. They do not guarantee the requested count. Nor does strict_order turn approximate retrieval into exact search: it orders returned results by distance. The ordering specification suggests measuring latency alongside the count remaining after filtering.

Control visible rows and authorized actions separately

An eligible product does not give its requester permission to inspect or modify another customer's order. Business eligibility and authorization require separate decisions.

PostgreSQL row-level security, or RLS, restricts which rows can be read or modified. Enabling it without a policy defaults to denying normal access. Superusers and BYPASSRLS roles bypass it, and table owners normally do too. Test with the actual application role, following the PostgreSQL 18 RLS specification.

For refunds, a proposed execution design would validate the authenticated requester, their relationship to the order, and delegated refund limits. A user or agent identifier supplied by the model is not, by itself, proof of authority.

Prevent duplicate refunds using both request identity and order state

Even authorized operations can be retried or run concurrently. Kumar's refund example combines an idempotency key, an order-row lock, and a limit check. Idempotency means repeated requests do not duplicate the business effect.

SELECT ... FOR UPDATE locks the selected rows and blocks conflicting modifications until the transaction ends. Whether an operation may proceed afterward remains a business decision. A lock does not create a rule rejecting an already-refunded order. That distinction follows from the PostgreSQL 18 row-lock specification.

The following is an implementation assessment of the published code. Reusing a key suppresses a retry, but a different key proceeds. The example does not check an already-refunded state or cumulative refunds. A production implementation therefore needs checks against the locked state, including remaining refundable value, positive amounts, and consistency between a key and its request payload.

Testing the same key twice is only one case. Concurrent requests for the same order with different keys test a separate property: preventing duplicate business actions. These are proposed tests derived from the design, not reported experimental results.

An outbox commits delivery intent, while external completion needs tracking

Accepting a refund also requires contacting a payment service. Separate database updates and API calls can leave one successful while the other fails.

A transactional outbox stores the business change and its outgoing event in one database transaction. A worker subsequently delivers committed events. This couples the update to delivery intent; the AWS transactional outbox guidance also explains duplicate-delivery concerns.

The database commit establishes the change and event, not external payment completion. A response can be lost after the destination has processed a request, so external idempotency and result reconciliation remain necessary.

A useful refund design distinguishes acceptance from confirmed payment completion. Although the published example writes refunded into the database, that value alone cannot prove external completion. Suggested operational signals include delivery backlog age, retry counts, and mismatches with confirmed outcomes.

Evaluate AI readiness against business completion conditions

Apply these boundaries to one workflow. The following is an illustrative design review covering product search through refunds.

Stage	Condition to establish	Enforcement point
Product retrieval	Relevant products satisfy sales constraints	Vector retrieval and SQL
Order access	The actor can access the order and perform the operation	Authentication, authorization, and RLS
Refund acceptance	Retries and concurrency preserve business rules	State validation, row locks, and idempotency management
Payment confirmation	External results are traceable and retries are handled	Outbox delivery, external idempotency, and reconciliation

A practical starting point does not require consolidating all enterprise data. Choose one workflow and identify its authoritative information, permitted actions, recovery path, and means of revoking authority. This translates Kumar's argument into a manageable adoption decision.

Evaluation can include time to completion, human rework, recovery frequency, and cost per completed operation, alongside response counts. These are candidate measures selected for the business outcome, not universal pass thresholds.

Vector support alone cannot establish readiness. The design should explain who may change state after retrieval, under which conditions, and how the result is verified. Keeping those boundaries in the system provides a foundation for changing models while preserving operational control.

Source

• Title: Vibhor Kumar: What “AI-Ready” Actually Means
• URL: https://postgr.es/p/9vM