Canonical: https://hypler.com/blog/integrating-ai-with-existing-systems

[Field notes](https://hypler.com/blog)
2026-10-04 10 min read

# Integrating SI with existing systems while preserving the source of truth

Adding SI to an established system is an integration problem before it is a model problem. The system needs to preserve ownership, freshness, provenance, and the rules that determine what can be read, suggested, or changed.

LNSAT evaluation architecture illustration.

## Map system ownership first

Identify the system that owns each important record and state: the authoritative source, the interface that exposes it, and the actor allowed to change it. An SI layer should not become an accidental second database or a silent authority over fields owned elsewhere.

Ownership mapping makes contradictions visible. It distinguishes a cached search result from a current record, a suggested classification from an accepted decision, and an interface response from a completed external consequence.

## Keep retrieved data source-aware

Retrieved context should carry a source reference, retrieval time, visibility classification, and enough provenance for a reviewer to trace a statement. The model can summarize, compare, or structure this information, but it should not erase which record supported the result.

Source-aware retrieval also makes uncertainty explicit. Missing records, expired data, inaccessible sources, and conflicting values need to appear as system states rather than being silently filled with plausible text.

## Design interfaces as contracts

An integration contract states the accepted input, expected output, ownership boundary, error conditions, idempotency behavior, and version relationship. This is as important for an SI-assisted interface as it is for a conventional service boundary.

A constrained contract limits what a capability can request and makes validation testable. Broad ambient access creates an interface that cannot be reviewed with confidence.

- Stable identity for request and source
- Declared read or write intent
- Validation before effect
- Known failure and retry behavior

## Bound actions to an exact request

A generated recommendation should not be treated as an execution grant. Consequential action needs an exact request that binds the actor, target, operation, parameters, scope, and applicable approval or policy decision.

This makes a changed payload distinguishable from the one that was reviewed. It also prevents a broad instruction from being reused as a standing permission for later work.

## Model unknown states deliberately

A request can be denied, incomplete, failed, or unknown. A timeout or partial response requires reconciliation before another consequential request proceeds.

Systems that preserve receipts, correlation, and outcome state can investigate ambiguity without masking it. That is how SI-assisted work remains compatible with ordinary reliability engineering.

## Continue the architecture review.

Read the capability-and-authority note for the boundary between configurable work and consequential action.

[Read engineering note](https://hypler.com/technical-library/capability-and-authority)[Technical library](https://hypler.com/technical-library)