AISA v2.0 / Technical documentation / Assessment and offer workflow

Assessment and offer workflow

F verified factP decided planC open challenge

1. The selected stages

Stage	Work and evidence	Decision / result
O1 Assess effort	Clarify the request inside this task — restate the understood outcome, ask for what is missing, agree the scope and acceptance examples — then inspect current evidence and consult Data, Configuration or Development domain owners for the work required. Compare genuinely comparable completed work.	Work breakdown, effort range/confidence, dependencies, active work versus waiting and unresolved assumptions. No implementation.
O2 Prepare offer	Combine assessed scope with the commercial owner's actual terms: deliverables, exclusions, price/effort basis, proposed delivery time, conditions and acceptance criteria.	Versioned offer; internal commercial-term review where required. Missing rate/price/date remains explicitly missing.
O3 Customer decision	Present the exact offer revision and obtain accept/reject/change response.	Customer CG-11 with scope `offer`; no target grant. Changed terms return to O2; changed scope/effort returns to O1.
O4 Communicate decision	Confirm the accepted/rejected terms to the customer and the named owner, including next responsibility and any remaining conditions.	Gated message evidence and scoped result returned to Support closure.

P O4 raises a precipitation event: the estimate meeting the actual decision — what was assumed, what it cost, what the customer accepted — is filed as a proposal for the asynchronous workflow, which never delays the communication (Stage Precipitation).

P The module manifest owns these stage identities and edges. The case walkthrough shows the shared-parser request; DV-16 covers the generic paging request. The archived evidence supplies neither an actual commercial offer nor a promised date, so those examples keep O3 and final completion pending.

Agent ownership and continuity

P commercial.coordinator retains the proposal scope and decisions under Support root. One commercial.assessor task owns clarification and O1 effort investigation with the same evolving brief. Clarification uses the focused-question segment of the common communication method; a separate communicator is needed only for the selected draft/send work. O2 belongs to commercial.offer_preparer, which receives the complete assessment and supplied commercial terms after investigation. Preparing an offer is this agent's responsibility, not a duplicate prepare-offer micro-skill. O3 remains the coordinator's revision-bound customer decision; O4 communicates that disposition.

P The offer preparer receives original objective, evidence refs, assumptions, dependencies, exclusions and missing terms, not only an effort number. Changed scope returns to assessment; changed terms return to offer preparation. Missing facts stay visible. These handovers use existing task, plan-confirmation and versioned-paper contracts; they create no implementation grant.

2. The assessment and offer papers

P The assessment records objective/revision, evidence refs, work items and the owner/discipline needed for each; estimate basis and comparable case refs; effort range and confidence; dependencies and external waiting; assumptions, exclusions and unanswered questions. Effort is not elapsed time. Historical case waiting does not become implementation effort, and an estimate is not a committed delivery date.

P The offer binds the assessment and source brief revisions, commercial owner, deliverables/acceptance criteria, exclusions, provided price/rate basis with currency where monetary, proposed delivery terms, conditions and validity if supplied. Missing commercial facts block a complete offer; the LLM cannot invent them from an old case. The communicator may improve wording while preserving exact approved values and conditions.

P Parent plan confirmation orders preparation. Internal review validates terms where the organisation requires it. The customer gate then accepts only the displayed offer hash/revision. New scope or terms invalidate the affected acceptance. Only Support root presents unresolved human decisions; module agents return scoped papers and questions upward.

3. Endpoints and durable state

P Intake remains the existing request endpoint/source arrival. Root routes into the declared embedded commercial graph. Stage tasks and plan revisions use the same tasks/papers protocol. O4 messages use the existing gated channel-send path. O3 uses POST /client/requests/{caseId}/accept with scope: offer, gate id, artefact hash, expected version and accept/reject; only the authorised customer representative can answer that exact outstanding gate.

P Store brief, assessment, offer and customer decision as versioned papers; task/plan identities in the existing work records; gate decisions and message evidence in the existing gate/ledger records. Missing owner terms park the owning task with reason, actor and age. No database transaction spans the customer wait. The module's case record remains support; commercial identifies the selected declaration, not a new database case enum.

4. Experience and repetition

P Assessment uses the effort-estimation strategy: comparable scope, actual work, waiting, changed assumptions and estimation error. The module owner reviews reusable commercial/assessment lessons, while the case registry exposes the current pending/accepted disposition immediately. Publication updates the common routing synopsis by reference; it does not duplicate all domain memory or copy old prices into a new offer.

P Storage mapping. The source brief uses PAPERS kind brief; the assessment uses report; the offer uses packet; the customer decision and final communication summary use report. Names/body versions distinguish these documents. No new PAPERS kind or CASES.MODULE enum is implied.

PreviousAssessment & Offers — agents and methods NextCore Development offer type