AI Integration Project Brief Template

An AI integration project brief should let a business owner, an application owner and a delivery team agree on the same piece of work. It should explain what enters the process, what the AI proposes, who can approve it and what the receiving system must confirm. A brief that describes only an “intelligent assistant” leaves those decisions to be discovered during implementation.

This guide provides a completed example and the reasoning behind its fields. It is intended for operations sponsors and IT project leads preparing a project enquiry, not for replacing a signed contract. Once the scope is understood, the integration statement of work can translate it into delivery obligations, acceptance arrangements and commercial boundaries.

A filled brief: bilingual course-catalogue amendments

The following scenario is illustrative. An education organisation receives approved departmental amendment documents and wants to prepare updates to its course catalogue. The proposed AI component extracts changes and highlights inconsistencies. Academic approval remains in the existing process; publication remains an authorised catalogue operation. The example does not include student admissions, grades or automated academic decisions.

Completed project brief for a catalogue amendment workflow

Brief field	Example entry
Business owner	Catalogue operations manager, responsible for amendment completeness and publication handover
Starting event	An authorised coordinator submits an approved amendment document and its department reference
Eligible input	Arabic or English text documents and readable scans within an agreed document category
Authoritative sources	Document repository for the amendment; catalogue application for the existing course identifier and current version
Proposed AI work	Extract changed fields, compare them with the current entry and prepare a reviewable change proposal
Completion state	The catalogue application acknowledges an approved draft update and returns the new draft reference
Excluded work	Academic approval, automatic public publication, student records, new application procurement and historical catalogue cleansing
Exception owner	Catalogue coordinator for ambiguous identifiers; departmental owner for conflicting content
Initial population	One agreed amendment category across a controlled set of departments
Success evidence	Correct proposal, preserved source evidence, authorised review and acknowledged destination update

The completion state deliberately stops at an accepted draft. If public publication becomes necessary, that is a separate operation with its own authority and acceptance evidence. This distinction prevents the word “update” from silently expanding the project.

Write the business problem as an observable gap

Describe the present work before prescribing AI. For example: coordinators compare amendment documents with catalogue entries, retype approved changes and investigate inconsistencies between Arabic and English descriptions. The problem is the effort and error exposure at that comparison and transfer boundary. It is not a general need to “transform education with AI”.

State how the baseline will be measured. Sample complete amendment cases, record staff review time and distinguish rework caused by unclear source documents from rework caused by transcription. If historical measurements are unavailable, mark the baseline as a discovery activity. Do not insert a guessed improvement percentage merely to fill a business-case field.

Include the simpler alternative. A better submission form may eliminate missing identifiers; a deterministic field mapper may handle structured amendments. The brief should reserve AI for the interpretation that remains necessary. This comparison makes scope more defensible and helps explain why a language model is present at a particular boundary.

Map source fields to destination meaning

A field list is useful only when it identifies authority and transformation rules. The AI must not choose which application owns a fact. Record whether each value comes from the amendment, the existing catalogue or an authorised human decision. Preserve raw values where normalisation could obscure the source.

Source-to-target map for the illustrative amendment

Field	Authority	Proposed handling	Failure route
Course identifier	Current catalogue	Resolve against the approved department and catalogue version	Hold if missing or ambiguous
Arabic description	Approved amendment	Copy the proposed change with its evidence location	Flag absent or contradictory text
English description	Approved amendment	Preserve supplied wording; do not invent an authorised translation	Request the missing approved version
Credit value	Approved amendment and academic process	Show the supplied numeric change for review	Block unsupported inference
Effective term	Approved amendment	Map to an allowed catalogue term identifier	Review an unrecognised or closed term
Destination version	Catalogue application	Check that the entry has not changed since comparison	Recompare before submission

Agree the payload with the application owner. The OpenAPI Specification provides a standard way to describe HTTP interfaces, but an interface description alone cannot decide which academic document is authoritative. Attach both the machine-readable contract and the human decision rules where available.

Document the user journey, including the interrupted journey

Describe who submits the document, where the proposal appears, what the reviewer can change and how approval is recorded. The reviewer should see existing values, proposed values and evidence together. A fluent summary without a field-level comparison is difficult to approve responsibly.

Then describe interruption. The user closes the browser; the catalogue application is unavailable; approval is withdrawn; another coordinator edits the same course. Specify whether processing continues, pauses or becomes invalid. A proposal based on an old catalogue version should not overwrite a newer edit merely because it was approved earlier.

These requirements feed the API contract and access-control design. Keep authentication, permission to review, academic approval and permission to submit distinct. One successful login does not establish all four.

Make dependencies visible before they become delays

Each dependency needs an owner, required evidence and a decision date. “Client to provide access” is too vague. Write “catalogue owner to demonstrate read-current-entry and create-draft operations in the test tenant using the proposed integration identity”. Record whether the action is completed, scheduled or unconfirmed.

Also record representative documents, field definitions, an available departmental reviewer, a non-production environment and permitted test data. Separate what execution depends on from approvals: credentials, a sample export and a release window are dependencies even when no committee decision is involved.

Maintain an assumption log. If the team assumes there is one active draft per course, identify who will verify it and what changes if several drafts can coexist. A useful assumption is falsifiable and connected to scope. Unsupported assumptions should remain visible in the integration timeline, not disappear into an optimistic delivery date.

Specify acceptance with cases, not adjectives

Replace “high accuracy” with a defined reference set, grading instructions and operational consequences. Include a normal amendment, a missing course identifier, conflicting language versions, an unsupported credit change, a withdrawn approval and a destination update that times out. Agree which failures block release and which can use an established exception route.

For each case, record the expected extracted fields, required evidence, allowed system action and final state. In the withdrawn-approval case, a correct field extraction is insufficient: submission must be prevented. In the timeout case, the integration must reconcile the outcome before issuing a new business operation.

Use the integration testing strategy to separate model behaviour from interface behaviour. A model might interpret an amendment correctly while the adapter maps the effective term incorrectly. Acceptance should reveal the component responsible for the defect so the team can fix the correct layer.

Add a readiness decision beside each open question

Use three explicit states: demonstrated, assumed and blocked. For each assumed item, record the test that would establish it and the owner who can supply the evidence. For each blocked item, state which deliverable cannot proceed and whether an alternative route exists. This turns uncertainty into manageable work rather than a general disclaimer at the end of the brief.

For example, if the catalogue exposes current entries but draft creation is unverified, the team can still define field mappings and review cases. It cannot yet promise an automated destination handover. That distinction allows useful preparation to continue while keeping the eventual delivery commitment honest.

Keep the brief concise without hiding uncertainty

The core brief can stay short if it points to controlled attachments: field map, interface evidence, process diagram, representative examples and acceptance cases. Assign each attachment a version and owner. Do not bury a scope change in a new screenshot sent during a meeting.

Before requesting proposals, ask three people to read the brief independently. Can the business owner identify the completed task? Can the application owner identify the authorised writes? Can the delivery lead identify what remains unverified? Disagreement is useful evidence that the brief needs another pass.

Keep requirements separate from solution suggestions. “Preserve current document permissions” is a requirement; “use a separate index for every department” is one possible design. Let suppliers explain alternatives and trade-offs against the same requirement. This produces a fairer integration vendor evaluation than asking each supplier to estimate a different interpretation of the project.

Use the brief to start a concrete enquiry

Share a version with sensitive information hidden, together with a representative input and the destination fields. Mark unresolved questions plainly. A useful enquiry can then focus on interface feasibility, acceptance and ownership instead of repeating a broad discovery discussion.

For a scope that needs to fit a wider estate, connect the brief to AI integration and delivery services. Discuss a completed integration project brief with the business outcome, application owners and the evidence still needed before implementation.