AI Native service capstone project

If an internal knowledge-support service's goal is merely “accurate answers,” each team may use different completion criteria. Replace this with observable conditions such as task success on a representative question set, support from evidence spans, zero unauthorized source exposures, P95 latency, and cost per successful task. Some are metrics for tracking improvement; others, such as personal-data exposure, must remain zero and are hard gates.

Out of scope and default behavior on failure also belong in the product contract. Decide whether to acknowledge missing evidence and hand off to a person rather than guess, and whether documents beyond the freshness limit may be used. Name the Data owner, model- and prompt-change owners, and incident contact to connect technical choices to user outcomes and operational responsibility.

Architecture diagrams should not just draw product boxes such as React and PostgreSQL; they should show which trust boundaries user identity and documents cross. The token sent from the browser to the API, the source documents that ingest reads from object storage, and the tool inputs and results the agent host sends to the MCP server are each distinct attack surfaces. Secrets must stay within the credential boundaries of the host or server, not in the model context.

The threat model maps scenarios onto the data flow: a malicious document using prompt injection to induce tool calls, vectors from another tenant appearing in search results, and an approval screen that differs from the actual parameters. Least privilege and input validation are preventive controls, tracing and auditing are detective controls, and disabling tools and revoking credentials are recovery controls. Only when each control is linked to an actual abuse test and an owner does the diagram become an operational document.

When ingesting a source, first store its source ID, revision, owner, ACL, parser, and content hash, then link chunks and embeddings to it as derived artifacts. If documents are treated as identical just because their file names match, there is no way to tell which vectors reflect edits and deletions. A reconciliation job is responsible for finding differences between source and index revisions and converging them within the allowed freshness.

On the query path, generate only candidates the user is permitted to access, and preserve source identity through every rerank and context-packing step. Answer citations must point to the span and revision actually used. Only after injecting permission changes and deletions and confirming that they disappear from the cache, vector candidates, and final answer within the defined time can you say that the data contract protects both search quality and security.

Separating the search tool from the ticket-creation tool allows different policies for reads and state changes. Besides an input schema, the creation tool must provide domain validation, authorization, an idempotency key, and a preview. Use audit identity to link the target shown by the Host to the target actually acted on by the server, so the approval UI is more than decoration.

An Agent loop needs not only maximum step and token limits but also repeated-operation detection, recovery per tool error, and human handoff. Multiple agents may research in parallel, but changes to the same ticket or database row must be serialized through one owner and a transaction. Prompt instructions help choose actions but cannot replace server authorization and concurrency control.

A release evidence pack binds the source commit, dependency lock, test and eval results, image digest, migration revision, and configuration schema into one release identity. In a canary, check not only HTTP 200 but also citation support, authorization violations, tool success, and cost per success. If a hard gate fails, do not increase traffic; fix the cause and rerun the same frozen cases.

Operational handover tests whether a new operator can find a run in the dashboard, disable a tool, and perform rollback and restore without the creator explaining it beside them. The runbook must describe the owner, alert meanings, safe initial diagnosis, credential revocation, data recovery, and known risks. The project can be judged complete only with evidence that both user outcomes and safety conditions recovered after failure injection.

Assume that, in a teaching leave-notice service, an operator approved notice draft revision 7. Before sending, another operator changes the date, creating revision 8. The system must detect the mismatch between approved revision 7 and current revision 8 and hold sending. Dismissing a date-only edit as trivial delivers a schedule the user never approved.

Show the changed date and recipient scope again. Record reapproval as a decision on new content, linked to the old approval without overwriting it. If an incorrect notice is sent later, investigators must reconstruct exactly what was approved. Link approver identity and decision time to detect improper reuse of old approval after edits.

Storing approval as a single Boolean is a counterexample. If it remains true after edits, another request can reuse an old decision. Approval without a target and revision cannot establish which change was approved. Storing the approved content identity and scope, rather than one Boolean, is central to preventing this failure.

Inject content changes, recipient changes and authorization revocation after approval. Verify that each mismatch is blocked before external sending. Unchanged valid approvals must still execute; a system that only holds work is not complete. Include external-send counts to reject implementations that display a hold while sending in the background.

A teaching enrollment service saves an enrollment and then sends a notice. Assume the messaging service accepted it but its response was lost. Canceling the enrollment and starting over can create duplicates or inconsistency with a notice already delivered. Preserve the existing enrollment identifier so follow-up queries track the original event rather than a new enrollment.

Leave the notification status linked to the enrollment identifier as unconfirmed, and look it up using the external receipt identifier. If acceptance is confirmed, complete the record without sending another message. If there is no basis for a lookup, show the resend risk to an operator and stop blanket retries. Record when the unconfirmed state began and who checks next so partial successes are not left unresolved indefinitely.

Code that assumes an HTTP error proves no external action occurred is a counterexample. A connection failure may mean the result was not received. Store transport outcomes separately from business outcomes to keep this uncertainty visible. Record fault-injection timing because recovery differs before and after external acceptance even with the same error code.

Inject failures before storage, after storage, and after external acceptance. A failure before storage must leave neither an enrollment nor a pending-notification record. After storage, preserve one valid enrollment and its pending-notification record; after external acceptance, leave the notification either confirmed or explicitly unconfirmed. Reconcile both systems to find missing pending records and duplicate outcomes. Verifying that reprocessing keeps the original operation identifier catches recovery that creates a new business operation.

Give a new operator a teaching incident in which some documents cannot be found. Set the cause as a stale route during an index-generation switch. Provide the known-good generation, current generation and failed query without revealing the diagnosis first. Fixed incident conditions make another operator’s results comparable after documentation changes.

The operator compares request records with search targets, identifies the wrong route and restores the previously verified route in the restricted environment. Check both the query’s evidence document and a denied-access case. A recovered answer alone does not prove preserved authorization. Check that current data was not lost during recovery rather than judging success solely from a quick normal response.

A handover that only progresses when the developer supplies a remembered file path is incomplete. Document the location and why it matters, then have another operator start afresh. Success by someone remembering the prior walkthrough does not establish reproducibility. Classifying each blockage as missing evidence or an incorrect step improves usability rather than merely document length.

The final submission includes the cause hypothesis, rejected hypotheses, before/after recovery evidence, and remaining limits. The receiving operator must explain which failure each action addressed. If that connection is unclear, precisely fill in the necessary observations and procedures rather than simply adding more material. Record the owner and recheck conditions for each remaining limit so unverified parts are not mistaken for completed work after handover.