AWSAWS Certified Generative AI Developer - Professional2026-101.4 Design and implement vector store solutions
Reconcile vectors against authoritative source revisions
Completed by the knowledge check
Learning objective
Reconcile incremental re-embedding, document deletions, stale vectors, and ingestion failures to maintain index consistency.
Core idea
A vector index is a projection of source content under a particular parsing, chunking, and embedding contract. Consistency means that retrievable evidence corresponds to the authoritative revision and permission state, and that withdrawn evidence is absent. It does not mean that the last ingestion request returned successfully.
Reconciliation compares intended source state with observed index state and repairs the differences. Change detection from 1.4.10 tells you where work might be necessary. Reconciliation proves that the work reached the correct outcome, including when a deletion, retry, or model migration does not resemble a normal document addition.
How it works
Classify the change before rebuilding
For a connected source, StartIngestionJob runs the incremental sync that 1.4.2 describes: unchanged documents are skipped, changed ones re-ingested, and deleted ones removed from the vector store. 1.4.2 also lists the conditions under which a metadata-only change reuses existing embeddings instead of calling the embedding model. What this objective adds is the observable: the job statistics report numberOfMetadataDocumentsModified, the number of metadata files updated or deleted, as its own counter beside numberOfModifiedDocumentsIndexed, so a metadata-only change is accounted for separately from re-indexed content.
In a custom pipeline, distinguish content revisions, access-policy revisions, and embedding-contract revisions explicitly. Those are application categories; Bedrock’s managed sync implements its own documented detection and optimization behavior.
A model, dimension, normalization, or chunking change can invalidate otherwise unchanged source projections. Routine incremental source synchronization is not evidence that a different embedding contract has been applied throughout the corpus. Plan a separate generation of the projection, validate it, and switch retrieval only after it meets the compatibility and evidence gates. Embedding compatibility belongs to 1.5.3 and 1.5.4.
Reconcile deletes as first-class changes
Deleting a source document and syncing a connected source removes that document from the vector store according to the sync documentation. In an application-owned index, preserve a mapping from source identifier to every generated chunk so the deletion removes all derived evidence. Removing a document’s title or its authoritative row while leaving its chunks searchable is incomplete deletion.
Separate document removal from resource teardown: dataDeletionPolicy governs what happens to vectors when the data source itself is deleted (see 1.4.2), not how withdrawn documents leave the index.
Managed connectors add one documented safeguard that can deliberately leave stale vectors behind. deletionProtectionConfiguration takes deletionProtectionStatus (ENABLED or DISABLED) and, when enabled, a deletionProtectionThreshold from 0 to 100, default 15. If a sync would delete more than that percentage of documents, it skips its delete phase and leaves the indexed documents in place. The Custom connector does not support it. This is the managed form of the rule that a partial inventory must not authorize mass deletion. Its cost is that genuinely withdrawn documents stay searchable until someone confirms the deletion was intended and reconciles the index, so alert on a sync whose numberOfDocumentsDeleted is zero when the source shrank.
Track a deletion marker in an application-owned projection ledger until absence is verified. Its purpose is to prevent a delayed update from restoring withdrawn evidence. Treat the marker as an application design, not an AWS ingestion status. Access revocations require the authorization boundary from 1.4.6 while eventual projection cleanup completes.
Keep direct ingestion aligned with S3 authority
Knowledge Bases direct ingestion supports S3 and custom data sources. IngestKnowledgeBaseDocuments submits documents directly for indexing; DeleteKnowledgeBaseDocuments removes indexed documents. These operations differ from a source sync through StartIngestionJob.
For custom data sources, AWS says the KnowledgeBaseDocuments operations update both the custom source and knowledge base without the IngestionJob sync path. For S3 sources, direct changes to the knowledge base do not update the S3 location. AWS explicitly warns that a later source sync can overwrite direct changes unless you make the same changes in S3. It also says not to submit IngestKnowledgeBaseDocuments and StartIngestionJob at the same time.
Choose one authoritative update flow and document any fast path. If direct deletion withdraws an S3-backed item immediately, also reconcile the S3 object before the next sync. If direct ingestion updates evidence first, update source content to the same intended revision. A fast path that bypasses authority without repairing it creates two competing versions of truth.
Inspect jobs, documents, and searchable evidence
Job status and the four indexed, deleted, and failed counters belong to 1.4.2, as does the visibility delay for stores other than Amazon Aurora. What reconciliation adds is how to read them. numberOfDocumentsScanned includes unchanged documents, so it is not a count of regenerated embeddings, and a terminal COMPLETE status alone does not replace document-level accounting. After the job, test that a changed document returns the intended revision and that a removed document no longer appears, using the retrieval boundary from 1.5.6.
For a custom projection, compare a complete authoritative inventory with the indexed revision ledger. Repair missing documents, obsolete revisions, orphan chunks, and failed work. Do not infer deletions from a partial or failed inventory. Repeated repair work should converge to the same state; an obsolete retry must not overwrite a later revision.
Key distinctions and trade-offs
Incremental sync versus full contract migration: Incremental sync reduces unnecessary processing of unchanged sources. A changed embedding contract needs corpus-wide compatibility evidence, not merely a successful incremental job.
Job completion versus verified consistency: Job status measures an execution. Statistics describe document outcomes. Retrieval checks establish whether readers can obtain the intended evidence. Keep these three signals separate.
Immediate withdrawal versus eventual physical cleanup: An authorization gate can prevent use of revoked evidence while cleanup completes. It does not excuse leaving orphan vectors indefinitely or proving deletion only through a hidden result filter.
Availability versus revision safety: Retaining a prior revision can preserve answers during a failed update, but only when the source and access policy permit that revision. A withdrawn policy must not remain an acceptable fallback because its replacement failed to embed.
Architecture / decision scenario
A policy assistant retrieves from two knowledge bases: a customer-managed knowledge base with an S3 data source for policies and notices, and a managed knowledge base with a SharePoint connector for team handbooks. It processes new policies, an edited handbook, a metadata-only ownership change, and a withdrawn notice. The team syncs both sources and inspects indexed, deleted, and failed-document statistics. It confirms the ownership change through numberOfMetadataDocumentsModified, and retries the failed handbook update after repairing its input.
A sync of the SharePoint connector after a large site cleanup reports no deletions because its deletionProtectionConfiguration skipped the delete phase; the team confirms the cleanup was intended and raises deletionProtectionThreshold before syncing again. An urgent direct deletion removes the withdrawn notice from the customer-managed knowledge base. The team also deletes the object from S3 so the next sync cannot restore it. Retrieval probes verify the handbook’s intended revision and the notice’s absence after the visibility interval. A separate embedding-model migration builds and validates a replacement projection; it does not rely on these ordinary source changes to refresh every unchanged document.
Common exam traps
- Treating scanned-document count as the number of regenerated embeddings.
- Assuming metadata-only optimization applies to CSV or custom transformation Lambda sources.
- Assuming a sync that skipped its delete phase removed withdrawn documents.
- Expecting deletion protection on a Custom connector.
- Deleting S3-backed indexed evidence directly while leaving S3 unchanged.
- Running direct ingestion and source sync concurrently despite the documented warning.
- Treating
COMPLETEas proof of immediate visibility and zero document failures.
What to remember
Reconcile the projection against source identity, intended revision, access state, and embedding contract. Inspect job status and document statistics, then verify searchable results. Keep direct ingestion and S3 authority aligned, and treat deletions and failed migrations as correctness work rather than routine additions.
Knowledge check
A team switches its knowledge base to a new embedding model. No source documents changed, and the next incremental sync reports COMPLETE. What establishes that the corpus is compatible with the new model?
An application-owned vector index receives a deletion for a withdrawn notice. Minutes later, a delayed retry of an older update for that notice arrives. What should the deletion design include?
A managed SharePoint connector uses deletion protection with the default threshold. After a site cleanup removes 40% of the documents, the next sync completes with numberOfDocumentsDeleted at 0. What should the operator do?
A withdrawn notice must leave an S3-backed knowledge base immediately, so the team calls DeleteKnowledgeBaseDocuments for it. What else must the team do?
StartIngestionJob at the same time, so that the sync confirms the deletionKnowledgeBaseDocuments changes are not reflected in the S3 location, and a later sync can overwrite them unless the same change is made in S3. AWS also says not to submit direct ingestion and StartIngestionJob at the same time.An ingestion job reports COMPLETE with these statistics: 1,200 documents scanned, 40 modified documents indexed, and 3 documents failed. The release note says “1,200 documents re-embedded”. What is the accurate reading?
COMPLETE means every document passednumberOfDocumentsScanned includes unchanged documents, so it is not a count of regenerated embeddings, and COMPLETE does not mean zero failures. Document-level accounting, followed by retrieval probes for changed and removed documents, decides whether the release is consistent.