Repair a reviewed change, not a guessed meaning
API drift repair adapts an eligible changed API boundary so an integration can continue under its reviewed contract. AGINDOW’s published Node.js and Python SDKs implement verified selective repair for explicitly reviewed mechanical top-level field renames. The feature is off by default. It is not an autonomous semantic migration system: the application supplies the migration facts, tool and phase scope, confidence and independent verification. A detector finding is evidence of a difference and does not automatically become an applicable rename rule.
Example: preserve a customer identity during a rename
Suppose a reviewed CRM migration changes contact_name to display_name. Independent application data already binds customer-123 to Ada. A local verifier checks the reviewed migration identity, the unchanged customer ID and that both old and new name values agree with that authoritative snapshot. The complete configuration example implements this with a local fixture callable in both languages. It does not contact a vendor. A schema check alone would accept many plausible names; it cannot establish that Ada is the intended customer.
{"before":{"id":"customer-123","contact_name":"Ada"},"after":{"id":"customer-123","display_name":"Ada"}}Configure the rule and verifier explicitly
Node uses selectiveRepair with rules and verify; Python uses selective_repair with SelectiveRepair and RenameRule. Node rule names are from and to; Python uses source and target. Both scope by tool and request or response side. Prepare authoritative evidence outside the call: the synchronous verifier must not wait for a database, network service or LLM. Begin in observe, which reports a matched rule without changing payloads. Only repair or strict mode permits applying an independently accepted patch.
Apply only after every gate accepts
Repair requires confidence of at least 0.97; strict requires at least 0.99. These are policy thresholds, not measured production accuracy. Complete supported capture, an eligible reviewed rule and a true synchronous verification result are required. Existing statistical findings, halts, malformed results and bypass are not cleared to force a repair. Source absence preserves identity; destination collisions, insufficient confidence or refusal leave the payload unchanged under the applicable policy. Verifier faults or unavailable capture bypass inspection and preserve upstream behavior.
Preserve untouched fields and inspect the event
Only the reviewed top-level key changes; unrelated values are preserved. The no-repair path returns the original value by reference, while repair creates a replacement and records changed bytes honestly. A repair event describes an applied repair; a candidate or finding alone does not. Recent local events are bounded memory, not a durable archive. Configure storage separately when evidence must survive a restart. Successful payload verification does not prove that a vendor persisted the intended write.
Know when automated repair is unsafe
Nested or array migrations, numeric conversions, enum rewriting and automatic rule discovery are outside this SDK option. A source/payment_method mapping can require business meaning that matching types cannot prove. Do not increase confidence to bypass missing evidence. An unresolved semantic write blocks in repair mode; unresolved shape drift can pass through for upstream rejection. Strict halts unresolved drift including reads, while infrastructure faults still bypass. A response halt cannot undo a completed upstream write, and replay requires separate outcome reconciliation.
Publication and evaluation
Published 28 October 2026; last updated 28 October 2026. AGINDOW documentation team. These explanations describe pre-alpha SDK behavior for local evaluation, not production accuracy or reliability benchmarks. Start with the runnable quickstart and evaluate your own boundary before widening scope.