Assignment
Create 25 synthetic records containing duplicates, missing owners, two formats, stale versions, and one deletion event.
Build sequence
- Profile completeness and permissions by source category.
- Define transformation and rejection rules with provenance fields.
- Run ingestion twice and reconcile source, accepted, rejected, and indexed IDs.
- Apply updates and deletions and inspect derived records.
Acceptance checks
- Every source record has an accounted-for outcome.
- Repeated ingestion does not duplicate records.
- The report identifies which data gaps block a pilot and who can resolve them.
Evidence to keep
Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.
Guided workshop: inspect data before promising answers
Create a synthetic inventory of six policy documents: a current password guide, an outdated invoice guide, a duplicate invoice guide with another filename, a scanned policy without extracted text, an Alder-only contract, and a document with no named owner. These represent distinct readiness issues.
Build a table with document ID, owner, tenant scope, version, last reviewed date, format, extraction status, duplicate group, and permission source. Count what is ready, blocked, or uncertain. Do not treat the absence of an access label as permission to share.
Worked finding: two invoice documents disagree about the refund period. Indexing both and asking the model to decide transfers a policy decision to a probabilistic component. The policy owner must identify the authoritative version. Until then, route those questions to review.
Migration plan: stage the source export, validate IDs and permissions, transform content, compare record counts and samples, build the index, then switch the active version. Keep a rollback pointer and deletion plan. Reconcile totals: extracted, rejected, duplicate, and excluded records should explain the source count under your stated counting rules.
Exercise: use the AI ingestion lab to import these records. Verify a duplicate import does not create duplicate visible chunks. Replace the invoice guide and demonstrate that the old version stops appearing. Delete the Alder contract and verify it is absent from retrieval, cached answers, and document downloads.
Acceptance evidence: preserve the original fixture manifest, transformed manifest, rejection reasons, permission checks, and before/after query results. Spot-check extracted numbers and headings against the source; a successful parser exit does not establish correct extraction.
Customer communication: write “Four of six documents are ready under the stated criteria; two require owner decisions” rather than “data looks good.” Give each blocker an owner and an action. Avoid presenting document count alone as a measure of knowledge coverage: one missing critical policy can matter more than hundreds of irrelevant pages.
Assessment: explain whether the pilot should proceed with a narrower dataset, wait for remediation, or stop. Data readiness is a delivery decision with business consequences, not just an embedding job that ran successfully.