AGENCY PROJECT ASSESSMENT
Understand an inherited client project before committing to scope, price or implementation.
Use a structured assessment to organise the available context, separate evidence from claims and define the next responsible action. This is not an automated repository audit, repair service or technical certification.
- Context
- Received and attributable
- Evidence
- Observed separately from claims
- Questions
- Missing information remains open
- Decision
- Clarify · stabilise · repair · rebuild · defer
- Boundary
- One responsible next step
Pause before delivery when the project cannot explain its current state.
An assessment is useful when documentation is incomplete, ownership is unclear, the application behaves differently from the description, previous work cannot be reproduced or the client expects a fixed quote without reliable evidence.
The goal is to reduce uncertainty before implementation is promised.
Begin with the sources the client can responsibly provide.
Relevant context may include a product brief, screenshots, architecture notes, issue lists, decisions, provider inventory, observed behaviour and authorised high-level repository information.
Do not send credentials, private keys, source archives, raw Production logs or unauthorised client data through the public contact route.
Separate observed facts, supplied claims and unresolved questions.
The assessment should identify what is supported by evidence, what remains an assumption, which risks could change the recommendation and which missing information must be obtained before scope is accepted.
The current Airchor foundation supports structured existing-project assessment from supplied context. Repository-aware understanding is a later Control Plane capability.
- 01Received
- 02Classified
- 03Reviewed
- 04Linked
- 05Project Model
Sources remain separate from accepted facts; unified repository-aware intake is not shown as available today.
Known facts
Accepted and supported
Claims
Attributed, not silently accepted
Assumptions
Visible and reviewable
Missing information
Kept open
Risk
Qualified by evidence
DECISION
Which next action is supported?
- Choices
- Clarify · Stabilise · Repair · Rebuild · Defer
- Evidence
- Supplied context, observed facts, risk and missing information
- Outcome
- Evidence-weighted recommendation
- Owner
- Agency and client
- Status
- Responsible review required
BUILD SPECIFICATION · VERSIONED
Approved scope for one Build
- 1Objective
- 2Scope and exclusions
- 3Acceptance criteria
- 4Constraints
- 5Evidence requirements
- 6Human approvals
- 7Provider boundary
Decide whether to clarify, stabilise, repair, rebuild or defer.
The right outcome may be a focused repair, a stabilisation phase, a controlled rebuild, a deeper evidence request or a decision not to proceed yet.
The assessment should explain the recommendation, confidence, dependencies and evidence rather than presenting one option as automatic.
Convert the accepted recommendation into a bounded next step.
Where implementation is appropriate, the next outcome should be a roadmap and Build Specification with scope, exclusions, acceptance criteria, client responsibilities, ownership targets and evidence requirements.
Current and future support
Available now: structured assessment and recovery planning from supplied project context, with evidence, risk, assumptions, missing information and recommended next actions made visible.
In active development: unified sources, Project Model, Work Items and next-best action.
On the roadmap: repository-aware execution, independent verification and Tested Preview.