Business Intent Lifecycle
From existing systems to approved, executable specifications
A white paper on collaboration, accountable decisions and AI-assisted delivery
Executive summary
An AI-assisted delivery process needs more than a detailed specification. It needs a reliable way to establish what the organisation intends, resolve uncertainty and preserve that meaning as work moves between people, documents, agents and software.
This paper proposes a business intent lifecycle: a continuous collaboration loop connecting source evidence, human interpretation, explicit business decisions, engineering specifications and validation. AI helps extract, explain and prepare work. People retain authority over the decisions for which they are accountable.
The central principle is one authoritative meaning with different levels of detail. Business participants should not have to read an agent's entire execution plan. Engineers should not have to reconstruct decisions from scattered conversations. Both should be able to trace their view to the same approved rules, examples and definitions.
The approach is a reference model, not a claim of completed product implementation or measured productivity gains. It can be applied through existing enterprise platforms, a dedicated workspace or a combination with explicit ownership boundaries.
1. Establish authority before generating documentation
Business intent describes the outcomes, rules, constraints and choices that determine what a system should do. It is not identical to what someone said in a meeting, what a document implies or what existing software happens to implement.
A useful working model keeps four distinctions visible:
| Record | What it establishes | What it does not establish |
|---|---|---|
| Source evidence | A statement, document passage, code excerpt or observed result exists. | The evidence is complete, current or authoritative for the desired behaviour. |
| Analyst interpretation | The evidence has been examined and a meaning proposed. | The business has approved that meaning. |
| Approved intent | An authorised owner has accepted specified rules and examples. | The implementation or deployment conforms to them. |
| Verification evidence | Particular checks were performed against identified artifacts and conditions. | Every possible behaviour is correct or all risks are resolved. |
“One source of truth” therefore means one designated authority for each kind of record, linked through explicit versions. It does not require one enormous document, one universal access level or the replacement of every existing tool.
2. Make collaboration a continuous loop
The entry point may be a recorded discussion, a policy change, an operational exception or an existing application. A business analyst reviews AI-prepared interpretations before asking business participants to act on them.
In words: evidence becomes a reviewed question; a business decision establishes intent; engineering and verification act on that intent; feedback can reopen it. Architects and quality specialists investigate early rather than waiting for a complete specification.
A validation request should identify the decision required, the relevant evidence, an example or process flow, the impact and the responsible reviewer. Related questions can be grouped, but unresolved choices must remain visible. Meetings remain useful for competing priorities and complex disagreements; routine clarification can happen asynchronously.
The system should respect reviewer capacity. A notification is not a commitment to immediate availability, and an unanswered request is not agreement. Business participants must also be able to raise exceptions or challenge assumptions without waiting to be asked.
3. A worked example: changing a service request
The following example is entirely fictional. It illustrates the method, not an organisation's actual policy or an implemented feature.
An organisation handles equipment-maintenance requests. Three pieces of evidence disagree:
- An excerpt from the existing application rejects a change once a technician is assigned.
- An operating guide says customers may change a visit address before a visit starts.
- An operations representative explains that some changes require dispatch review because travel plans may already be committed.
The analyst should not let AI collapse these statements into a single confident rule. The code excerpt may omit another route. The guide may be outdated. The operational practice may be an undocumented exception.
Prepare a decision, not just a summary
After reviewing the evidence, the analyst asks the service owner:
When a technician is assigned but has not started the visit, should an address change be rejected, applied immediately, or submitted for dispatch review? What should remain unchanged while the request is pending?
The owner can examine a process flow and concrete examples without reviewing implementation instructions. The architect investigates scheduling dependencies, while the quality specialist challenges cases such as a visit starting during review or a change being withdrawn.
Record the approved meaning
For this illustration, assume the authorised owner explicitly chooses the following behaviour:
An address change submitted after assignment and before the visit starts creates a pending review. The existing assignment remains unchanged until dispatch approves the change. Once the visit starts, this change path is unavailable.
The choice is a fictional approval within the example, not a policy inferred from the source material. The decision records its rationale, approving identity and exact rule and example revisions.
| Example | Expected outcome under the illustrative decision |
|---|---|
| Assigned visit; change submitted before start | Create a pending review; retain the existing assignment. |
| Dispatch approves while the visit has not started | Apply the approved change and record the decision. |
| Visit starts before approval is completed | Do not apply the change through this path; return for resolution under the agreed process. |
If the last case has not actually been decided, it remains an open question. AI cannot invent its expected outcome simply because a test needs one.
Carry the decision into delivery
The engineering view adds state transitions, permissions, concurrent-update handling, integration effects and test design. It links back to the approved rule. Implementation and tests must not quietly replace “pending review” with “update immediately.”
Existing-behaviour tests can help reveal migration differences, but not every difference is a defect: some represent intentional, approved change. The review must distinguish preserving current behaviour from implementing a new rule.
4. Different views, the same meaning
The business-facing view and agent-facing specification are not independent documents that happen to describe the same feature. They are linked representations of a selected intent baseline: the exact rule, example and definition revisions being used.
The diagram shows three views of one baseline, brought together by a fidelity review. A discrepancy requests clarification; it does not authorise the reviewer or an agent to rewrite approved intent.
Progressive disclosure can reduce reading effort, but must not hide decision-relevant exceptions. A reviewer should know what they are approving and what remains unresolved. Technical detail can stay in the engineering view when it does not change business meaning.
A coverage map links important rules and exceptions to their representations and verification examples. Structural checks can identify missing links or stale revisions. Semantic review asks the harder question: does the representation preserve the intended meaning? A similarity score or a second generated summary is not sufficient evidence on its own.
Use shared terminology deliberately
A glossary defines concepts; a taxonomy organises their categories and relationships. Both should have explicit scope and ownership. “Assigned,” “started” and “approved” in the example must have meanings shared by business rules, state transitions and tests.
Existing enterprise terminology remains authoritative where applicable. Project-specific terms or exceptions are proposed and reviewed rather than silently redefining the enterprise vocabulary. A changed definition can affect multiple rules, so baselines retain the definition versions on which their meaning depends.
5. Keep interaction useful and decisions attributable
A contextual assistant can explain why a question matters, compare alternatives or help a participant prepare a response. It should cite the accessible source or decision revision and acknowledge missing rationale.
Exploration and contribution are different activities. A participant may need a private space to test an interpretation before sharing it. Only an explicitly selected, previewed contribution should enter the shared review flow. Private drafting must not silently become team knowledge. Processing, support access and retention still need clear policies; private collaboration is not a promise that no service logs exist.
The shared record should distinguish the contributor, analyst, approver and any AI-assisted generation. Decisions identify the exact approved content, rationale and time of approval. A changed rule creates a new revision and impact review; it does not rewrite history or inherit approval automatically.
Comments remain attached to the passage, example or process element and revision they addressed. When an artifact changes, the system should show whether an old comment still applies rather than moving it silently to different content.
6. Govern authority, not every keystroke
Automation works within a mandate: permitted actions, environments, data, budgets, checks and escalation conditions. The mandate is established by accountable people and enforced outside the model.
| Decision or action | Accountable responsibility | Permitted AI contribution |
|---|---|---|
| Release a question for business validation | Designated analyst | Prepare the question, evidence and alternatives. |
| Approve a business rule or exception | Authorised business owner | Explain consequences and identify ambiguity. |
| Accept material architecture, access or risk changes | Designated technical or risk authority | Investigate, propose and supply review evidence. |
| Execute a bounded engineering task | Team operating within an approved mandate | Perform permitted work and report results and failures. |
| Authorise a high-impact release | Designated release authority under organisational policy | Assemble verification and readiness evidence. |
An agent may suggest that a case needs review, but cannot waive a mandatory approval because it assigns itself a high confidence score. Failed controls, conflicting decisions and actions outside the mandate must stop or escalate.
Where routine engineering decisions use time-boxed consensus, that practice must not be confused with explicit approval of business meaning. Silence is not approval of a rule, an access change or a mandatory release decision.
More autonomous software factories can use the same model: autonomy increases within evaluated boundaries, while authority and evidence remain explicit. A successful supervised pilot is not proof that unrestricted autonomous execution is safe or operationally ready.
7. Fit the enterprise rather than duplicate it
A coherent interaction experience need not own every underlying service. Before implementation, identify existing authorities for identity, terminology, requirements, repositories, model access, delivery and operational support.
The collaboration layer needs to know which service owns each record, which version it is using, who operates the integration and what happens when that service is unavailable. Describing an integration is not evidence that it is connected or verified.
Living documentation can render approved knowledge through a documentation platform, while a separate application service manages contributions, permissions and approvals. Search and assistant responses should use the same authority and access rules. A rendered page or search index is a view, not an independent source of business approval.
Approved model services may be supplied through enterprise gateways or private-cloud arrangements. Network privacy, geographic processing, retention and training-use commitments must be evaluated separately for the selected service. An unavailable approved route must not cause an undisclosed fallback to another provider.
Project material also needs access controls on diagrams, downloads and search indexes—not only the page navigation. A public methodology article and a confidential project workspace are different publication audiences.
8. Build internal capability through delivery
The approach depends on practitioners understanding how it works, not merely learning where to click. Business contributors need an accessible decision experience. Internal analysts, engineers and quality specialists also need practical knowledge of AI limitations, context preparation, verification and recovery.
A useful progression is:
- Observe: a practitioner demonstrates a real task and explains the choices and failure modes.
- Pair: the internal practitioner performs the task with support.
- Lead: the internal practitioner makes the choices and produces the artifacts; a partner reviews.
- Operate: the internal practitioner handles an agreed task and a realistic failure with the normal support arrangements.
For an analyst, the demonstration may involve resolving conflicting evidence without inventing approval. For an engineer, it may involve diagnosing an agent's incorrect context. For a quality specialist, it may involve detecting an omitted exception and preventing invalid acceptance.
Evidence of learning should be task-specific and transparent. Training attendance, document access or an AI-generated competence score cannot establish independent capability. The objective is sustainable ownership of the process, not dependence on its original authors.
9. Evaluate meaning, effort and recovery
Evaluation should test the collaboration process as seriously as the generated artifacts. Useful exercises include:
- Code and policy disagree; the conflict remains visible until an authorised decision resolves it.
- A readable summary omits an exception; the fidelity claim fails even though the prose is fluent.
- A rule changes after approval; earlier specifications remain tied to their original baseline.
- A participant asks about a private discussion; the shared assistant cannot retrieve it.
- An approved model route fails; human work is preserved and no forbidden fallback occurs.
- An internal practitioner leads a change and explains how a seeded failure was diagnosed.
Software verification still spans domain/unit tests, interface and integration checks, end-to-end journeys and risk-appropriate security, accessibility, performance and recovery testing. AI evaluation adds grounding, ambiguity, contradiction and repeated-run checks. User acceptance tests business outcomes; it is not replaced by model-based review.
Generated tests must be judged against independently reviewed expected outcomes. Otherwise, code and tests can agree with the same wrong interpretation. Model and instruction changes should be evaluated against retained cases, including previous failures, without rewriting those cases merely to obtain a pass.
Measure stakeholder effort, analyst effort, waiting time, clarification cycles, rework, failure recovery and operating cost. Compare with a defined baseline and report assistance required. Do not substitute document volume or number of agents for useful outcomes.
10. Apply the method incrementally
A bounded pilot can begin with one fictional or authorised capability, a small evidence set, a reviewed decision and a proposed delivery package. Demonstrate traceability, fidelity, permissions and recovery before expanding integration or autonomy. Proposed tests and deployment plans must remain labelled as proposals until execution evidence exists.
The lifecycle complements the existing methodology rather than replacing its engineering practices:
- The Inception Cycle establishes context, quality goals, structural risks and trust boundaries.
- The Full Cycle provides the design, implementation, verification and review sequence.
- Human–AI Collaboration makes the division of judgment and assisted execution explicit.
The proposed extension connects those practices to the ongoing work of discovering, approving and revising business meaning. Its value should be established through observed use: can people reach sound decisions with less friction, preserve those decisions through delivery and take ownership of the process?
That is the intended outcome: not more documentation, but a dependable relationship between what the organisation means and what its systems do.