Appendix FA 90-Day Sovereign Pilot Plan

A week-by-week plan for an institution at Level 1 or 2 in Appendix A to reach Level 3 with one working, governed, multi-system agent in production. It assumes a sovereign platform deployed from source into the institution's own cloud account, a vendor engineering team embedded with the institution's, and a hard problem chosen in advance. The plan is deliberately front-loaded with decisions, because the decisions are what take time; the engineering is faster than most institutions expect.

Before day one

• Choose the problem. One process that spans at least two systems of record and that real people do every week. Write down what "better" would mean in a sentence a department head would sign.
• Name the owners. A CIO sponsor, a process owner from the department, an engineering lead, a security lead, and the vendor's embedded engineers.
• Settle the contract. Source under perpetual license; everything built in the pilot owned by the institution; model providers paid directly or through capped credits; no per-seat line.
• Pick the deployment tier. For the pilot, the institution's own cloud account.

Weeks 1 to 2: Deploy and sign in

• Deploy the platform from source into the institution's cloud account, by the institution's engineers with the vendor beside them. Record the steps; they are the beginning of the runbook.
• Connect institutional single sign-on. Verify roles and organization scoping with three real users of different roles.
• Configure two commercial model providers and set a spend cap. Confirm the spend view shows tokens by agent.
• Run the four exit questions from Chapter 3 as a baseline. Two will be yes already; write down the other two as the pilot's structural goals.

Milestone: a signed-in user can chat with a default agent on the institution's own deployment, with a visible cost.

Weeks 3 to 4: The first connector and the broker

• Stand up the broker inside the institution's account, empty policy, deny by default.
• Connect the first system of record through a Model Context Protocol connector, running in the institution's account, with its credential in the broker's secret store.
• Write the first policy rows: one role, read scope "own" or "caseload," no writes.
• Build the pilot agent with that connector and a first skill written by the process owner in plain language.
• Verify the audit log shows every call with user, role, tool and decision.

Milestone: the agent answers a real question from live data, as the asking user, and the call is in the log.

Weeks 5 to 6: The second system and the ontology

• Connect the second system of record. Define the three or four concepts the pilot needs in the ontology and map them to the two connectors.
• Extend the skill to use both systems. Add the identity-resolution rule that links the person across them.
• Write the evaluation set: thirty to fifty real prompts with the properties of a good answer, graded by the process owner.
• Run the evaluation on both configured models. Record the results in the platform.

Milestone: the agent completes the multi-system task; the evaluation set exists and has been run.

Weeks 7 to 8: Surfaces and memory

• Put the agent where the work happens: the browser side panel for the process owner's team, the desktop application for anyone who wants it, an embed on the relevant internal page.
• Turn on memory with the three scopes; have two users verify they can see and switch off their own.
• Write the agent's shared memory: the standing facts and rules the process depends on, by the process owner.
• Set the approval mode to ask-first for any write tool, and add the first write tool if the process needs one.

Milestone: the team uses the agent from the side panel in their daily work; memory and approvals are visible and governed.

Weeks 9 to 10: Governance and the local model

• Add a classification tag to the restricted connector's results and a routing rule confining them to an approved model.
• Stand up one open-weight model on a team-tier machine or a cloud GPU; add it to the router as the restricted target and as the fallback.
• Re-run the evaluation set on the local model; record the difference.
• Attempt to violate a policy from the chat window, twelve ways; confirm the broker, not the model, refused, and that the attempts are in the log.

Milestone: restricted data never leaves the institution's infrastructure, and the attempt to make it leave is on record.

Weeks 11 to 12: Operate and verify

• Hand the runbook to the institution's team. Perform one deployment of a platform update end to end without vendor hands on keyboards.
• Re-run the four exit questions. Three or four should now be yes.
• Score Appendix B for the pilot estate. Set the target for the next quarter.
• Present to the sponsor: the sentence from before day one, with the evidence: usage, evaluation results, cost by model, the audit log, the exit verification.

Milestone: Level 3 in Appendix A for the pilot, with a documented path to extending it across the estate.

What the plan does not include

It does not include a data migration, because there is none. It does not include a security review of a new authentication system, because the pilot reused the institution's. It does not include a procurement cycle for hardware, because the local model runs on a team-tier machine or a rented GPU for the pilot. Each of those is a quarter in a conventional plan, and their absence is why ninety days is realistic.