The Software Delivery Partner Appointment and Technical Due-Diligence Playbook

Before appointing a software partner, check whether it can deliver and support the service you actually need. Examine evidence of discovery, design, security, quality, handover and exit arrangements against your requirements and controls. A relevant portfolio or affordable estimate alone does not establish capability.

1. The Market Connection Context

The bottom-line failure is familiar: a provider is selected before leadership can distinguish sales capability from the delivery system that will carry the organisation's customer, operating, financial and control exposure. Discovery assumptions harden into scope. Architecture diagrams conceal unresolved dependencies. Security questionnaires replace tested practices. Quality is reduced to a test phase. Commercial terms omit internal work, change economics, intellectual-property rights, operational support and an executable exit.

actual product and delivery risk
→ normalised provider evidence
→ discovery, architecture, security and quality diligence
→ commercial, IP, handover, support and exit controls
→ appoint, condition, validate, change, defer, reject or stop

By [decision date], the CIO/CTO and Product Sponsor will assign APPOINT WITHIN BOUNDARY, CONDITION, VALIDATE, CHANGE, DEFER, REJECT or STOP to one appointment decision. The signed record will name the service boundary, provider legal entity and proposed team, decision-critical evidence, mandatory failed gates, commercial and IP conditions, organisation-owned dependencies, handover and exit obligations, residual uncertainty and the next evidence gate. Appointment does not prove later delivery quality, security, compliance, adoption or value.

Use The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics for whether the investment and next phase should be funded. Use this guide for whether a provider should receive a bounded appointment. The Product Delivery Governance Standard: From Discovery through Production Acceptance governs delivery after appointment and owns discovery-to-production acceptance. Return architecture decisions to The Solution Architecture and Non-Functional Requirements Standard: Designing for Supportable Value when the appointment depends on unresolved solution or non-functional requirements. Provider claims remain interested-source evidence until independently checked against the work and risk in scope.

Working files

• Appointment Charter and Requirement Register
• Provider Team and Technical Evidence Register
• Commercial IP Support and Exit Control Register
• Appointment Decision and Handover Register

Evidence foundation and limits

The UK Sourcing and Consultancy Playbooks are VERIFIED official procurement guidance on delivery-model assessment, market management, risk allocation, evaluation and contract management. The UK Technology Code of Practice is VERIFIED official guidance on user needs, accessibility, security, open standards, purchasing and lifecycle ownership. The NIST Secure Software Development Framework is VERIFIED official guidance for preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. CISA Secure by Design is VERIFIED official guidance that security responsibility and secure defaults belong in product and supplier practices rather than being transferred to customers. WCAG 2.2 is a VERIFIED W3C Recommendation defining testable accessibility criteria; conformance for a proposed service remains unproven until tested. The UK Intellectual Property Office guidance on ownership of copyright works is VERIFIED official general guidance showing why commissioned-work ownership must be made explicit; qualified legal advice remains necessary for the actual agreement. Local provider identity, staffing, competence, availability, controls, prices, rights and delivery evidence are REQUIRES VALIDATION. This appointment method and its thresholds are PROPOSED; conclusions drawn from retained evidence remain INFERRED until accepted by named human authorities.

2. The Leadership vs. Delegation Boundary

The reader recognises that appointment requires product, technical, commercial, IP, account-control, support and exit diligence against the actual delivery risk.

Internal leadership is credible where it can challenge a preferred provider, inspect technical and commercial evidence, contact references with permission, protect confidential information and recommend rejection. Independent challenge is proportionate where the incumbent shaped the requirements, decision makers lack delivery expertise, conflicts exist, the service is consequential or switching would be difficult. Specialists decide within their qualification; a security reviewer cannot accept commercial exposure and procurement cannot certify architecture.

| Shared | Organisation and provider evidence boundaries, requirements, assumptions, test conditions, acceptance gates, handover obligations and change triggers are reconciled; the organisation retains decision rights. |

Use a narrower specialist for one bounded security, accessibility, privacy, IP, procurement, architecture or support question. Stop or escalate when identity, evidence access, conflict controls, mandatory gates, organisation-controlled accounts or executable exit are missing. Ask a provider how it preserves independent challenge, named ownership, reproducible evidence, transfer, change control and exit. The Software Delivery Partner Appointment and Technical Due-Diligence Playbook is the anchor only for software-delivery partner appointment; The Automation Partner and Commercial Due-Diligence Playbook: Scope, Cost, Risk and Exitability and The Transformation Partner Appointment and Commercial-Control Playbook retain their named automation and transformation appointment authorities. Reuse evidence only with matching boundary and retain one shared decision ID where gates combine.

Ask a proposed partner to show how it would test the riskiest discovery assumption, trace a requirement into architecture and acceptance evidence, respond to a vulnerability, keep organisation-controlled accounts and repositories current, demonstrate accessible work, transfer operational capability, calculate change, protect third-party and organisation IP, and execute exit. A confident verbal answer is not the same as a reproducible artefact, named owner and contractual obligation.

3. The Step-by-Step Execution Standard

Step 01: Charter the appointment decision

Purpose and decision served Bound one provider appointment and preserve a credible reject or stop route.

Accountable owner CIO/CTO.

Delegated lead and contributors Product Sponsor, procurement, architecture, security, operations, finance, legal and independent challenge.

Preconditions, inputs and access Accepted The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics phase boundary, current need evidence, The Solution Architecture and Non-Functional Requirements Standard: Designing for Supportable Value conditions where material, procurement authority and conflict disclosures.

Actions

1. Name the service, phase, decision date, authority, allowed dispositions and prohibited interpretations.
2. Record affected users, market or operating consequence, mandatory control domains and evidence access.
3. Separate appointment from funding, delivery, production acceptance and scale authority.

Evidence to retain Signed charter, predecessor decisions, authority map, conflict register and source index.

Decision or scoring rule Proceed only when the process may reject every provider and the next commitment is bounded.

Output and template Charter rows in T01.

Acceptance gate CHARTERED, CHANGE or STOP.

Leadership checkpoint CIO/CTO confirms appointment cannot inherit approval from the business case.

Human control point Product Sponsor accepts the need; procurement accepts the route and authority.

Failure modes and safeguards Reject a charter written to legitimise an incumbent, personal preference or predetermined platform.

Change, stop or escalation condition Stop if decision authority, conflicts, confidentiality or mandatory evidence access cannot be established.

Handoff to the next step The charter controls requirement normalisation.

Step 02: Normalise the actual delivery requirement

Purpose and decision served Make providers respond to the same outcome, risk and operating boundary.

Accountable owner Product Sponsor.

Delegated lead and contributors Product, research, architecture, operations, accessibility, data, security and workflow owners.

Preconditions, inputs and access Charter, validated problem evidence, constraints, existing estate and material non-functional conditions.

Actions

1. Define users, jobs, service outcomes, discovery unknowns, integrations, data and operating environment.
2. Separate mandatory conditions, evidence questions, options and implementation detail not yet justified.
3. Assign organisation and provider responsibilities, dependencies, acceptance evidence and exclusions.

Evidence to retain Normalised requirement, risk scenarios, dependency map, assumptions and unresolved questions.

Decision or scoring rule No provider is compared until material requirements have the same meaning and evidence test.

Output and template Requirement rows in T01.

Acceptance gate COMPARABLE, VALIDATE, RETURN or STOP.

Leadership checkpoint Sponsor accepts minimum coherent scope rather than a feature wish list.

Human control point Qualified owners accept mandatory control questions without certifying an answer.

Failure modes and safeguards Do not let a provider's proposed solution silently redefine the business problem.

Change, stop or escalation condition Return to The Solution Architecture and Non-Functional Requirements Standard: Designing for Supportable Value or The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics when unresolved architecture or funding conditions prevent comparison.

Handoff to the next step Comparable requirements govern provider identity and team checks.

Step 03: Verify the provider entity, team and claims

Purpose and decision served Establish who will contract, perform, govern and remain accountable for the work.

Accountable owner Procurement Lead.

Delegated lead and contributors Technology lead, product, finance, legal and authorised reference checker.

Preconditions, inputs and access Comparable requirement, declared entity, proposed team, subcontractors and claim list.

Actions

1. Verify contracting entity, authority, proposed named roles, allocation assumptions and subcontracting.
2. Trace material capability claims to scoped artefacts or authorised references and retain limitations.
3. Test continuity, replacement, conflicts, concentration and key-person dependence.

Evidence to retain Entity records, team matrix, role evidence, reference notes, claim-source links and conflicts.

Decision or scoring rule A corporate portfolio cannot substitute for evidence about the proposed team and actual scope.

Output and template Provider and team rows in T02.

Acceptance gate VERIFIED WITHIN SCOPE, VALIDATE, CONDITION or REJECT.

Leadership checkpoint CIO/CTO accepts which claims remain unverified.

Human control point Procurement confirms identity and contracting facts; technical owners judge role fitness.

Failure modes and safeguards Do not invent reference outcomes, infer availability from a biography or accept unnamed replacement rights.

Change, stop or escalation condition Reject material misrepresentation or inability to identify accountable delivery roles.

Handoff to the next step The verified team demonstrates discovery and product practice.

Step 04: Test discovery and product-decision practice

Purpose and decision served Determine whether the provider can reduce uncertainty before converting it into scope.

Accountable owner Product Sponsor.

Delegated lead and contributors Product lead, user research, service design, data, accessibility and provider team.

Preconditions, inputs and access Risk-ranked unknowns, user evidence, proposed approach and representative scenario.

Actions

1. Ask the proposed team to frame one risky assumption, evidence method, affected population and decision gate.
2. Inspect how contradictory evidence, accessibility, consent and unsuccessful findings change scope.
3. Require trace from discovery finding to product decision, excluded claim and next validation.

Evidence to retain Method demonstration, sample decision trace, research safeguards, dissent and limitations.

Decision or scoring rule Discovery fitness requires a falsifiable decision method, not a workshop catalogue.

Output and template Discovery evidence rows in T02.

Acceptance gate FIT, CONDITIONAL, VALIDATE or REJECT.

Leadership checkpoint Sponsor confirms the method could stop or change the preferred scope.

Human control point Research and accessibility authorities accept their bounded safeguards.

Failure modes and safeguards Reject methods that equate stakeholder opinion, prototype approval or activity with customer evidence.

Change, stop or escalation condition Escalate when research access, vulnerable-person safeguards or evidence ownership is unresolved.

Handoff to the next step Discovery decisions enter architecture and engineering diligence.

Step 05: Test architecture and engineering discipline

Purpose and decision served Assess whether technical choices remain traceable, supportable and reversible within the real estate.

Accountable owner CTO or Architecture Authority.

Delegated lead and contributors Engineering, platform, data, integration, operations and proposed technical leads.

Preconditions, inputs and access The Solution Architecture and Non-Functional Requirements Standard: Designing for Supportable Value conditions, system context, integration constraints, sample artefacts and decision scenarios.

Actions

1. Trace one decision from requirement through architecture, code, configuration, deployment and operation.
2. Inspect decision records, dependency governance, environment separation, observability and recovery design.
3. Test build reproducibility, repository control, privileged access and avoidance of undocumented provider infrastructure.

Evidence to retain Architecture trace, decision record, repository demonstration, dependency evidence and identified gaps.

Decision or scoring rule Tool familiarity cannot compensate for a failed mandatory architecture, ownership or recovery gate.

Output and template Architecture rows in T02.

Acceptance gate FIT WITHIN BOUNDARY, VALIDATE, CHANGE or REJECT.

Leadership checkpoint CTO records material technical dependence and decisions reserved for The Product Delivery Governance Standard: From Discovery through Production Acceptance.

Human control point Architecture Authority accepts only the appointment-level evidence boundary.

Failure modes and safeguards Do not treat a polished reference architecture as proof it fits the organisation's constraints.

Change, stop or escalation condition Return to The Solution Architecture and Non-Functional Requirements Standard: Designing for Supportable Value when a material solution decision lacks accepted evidence.

Handoff to the next step The architecture boundary controls security and quality diligence.

Step 06: Test secure-development and vulnerability practice

Purpose and decision served Determine whether security work is built into delivery and response rather than deferred to release.

Accountable owner Qualified Security Authority.

Delegated lead and contributors Engineering, platform, privacy, risk, procurement and provider security lead.

Preconditions, inputs and access Threat context, data classification, access model, secure-development evidence and incident obligations.

Actions

1. Map provider practices to preparation, protected development, secure production and vulnerability response.
2. Inspect identity, secrets, dependency, code review, testing, provenance, disclosure and remediation evidence.
3. Define incident notification, evidence preservation, responsibility, containment, retest and escalation.

Evidence to retain Control mapping, sample records, vulnerability workflow, limitations, qualified findings and response terms.

Decision or scoring rule Self-attestation or certification cannot close a scope-specific mandatory security failure.

Output and template Security rows in T02 and control conditions in T03.

Acceptance gate ACCEPT WITHIN SCOPE, CONDITION, VALIDATE or REJECT.

Leadership checkpoint CIO/CTO sees residual exposure without converting diligence into a compliance claim.

Human control point Qualified security, privacy and legal owners retain their separate decisions.

Failure modes and safeguards Do not request unnecessary sensitive evidence; use controlled inspection and redacted proof where proportionate.

Change, stop or escalation condition Reject concealed material vulnerabilities, unsafe account control or absent incident cooperation.

Handoff to the next step Security findings join quality and acceptance diligence.

Step 07: Test quality, accessibility and release evidence

Purpose and decision served Establish whether the partner can produce reproducible evidence across functional and non-functional quality.

Accountable owner Quality Authority.

Delegated lead and contributors Product, engineering, accessibility, security, operations and representative users.

Preconditions, inputs and access Acceptance risks, WCAG target, quality strategy, sample pipeline and defect evidence.

Actions

1. Trace acceptance criteria into automated, manual, accessibility, security, performance and recovery tests.
2. Inspect test independence, representative environments, defect decisions, regression and evidence retention.
3. Demonstrate how a failed mandatory test blocks release and returns to accountable correction.

Evidence to retain Quality strategy, sample trace, test output, accessibility method, defect disposition and limitation.

Decision or scoring rule Pass counts cannot offset a failed mandatory user, accessibility, security, data or recovery condition.

Output and template Quality rows in T02.

Acceptance gate FIT, CONDITIONAL, VALIDATE or REJECT.

Leadership checkpoint Product Sponsor confirms quality is an ongoing evidence system, not a closing phase.

Human control point Qualified accessibility and security authorities decide their respective findings.

Failure modes and safeguards Do not infer WCAG conformance from tooling or confuse a demonstration with production acceptance.

Change, stop or escalation condition Reject inability to retain reproducible evidence or honour mandatory stop gates.

Handoff to the next step Technical findings become commercial and responsibility conditions.

Step 08: Reconcile commercials, responsibilities and change economics

Purpose and decision served Make the price basis and risk allocation comparable to the actual delivery model.

Accountable owner Procurement Lead.

Delegated lead and contributors Finance, product, technology, operations, legal and provider commercial lead.

Preconditions, inputs and access Normalised requirement, technical findings, pricing schedule, assumptions and proposed terms.

Actions

1. Trace price basis to roles, units, inclusions, exclusions, dependencies, internal work and tax treatment.
2. Test how discovery findings, change, delay, rework, defects and third-party costs alter commitment.
3. Allocate each delivery and control responsibility to a capable party with evidence and remedy.

Evidence to retain Normalised commercial schedule, responsibility matrix, change mechanism, assumptions and deviations.

Decision or scoring rule No price is compared until scope basis and organisation obligations are normalised; cheapest is not automatic best value.

Output and template Commercial rows in T03.

Acceptance gate COMPARABLE, CONDITION, NEGOTIATE or REJECT.

Leadership checkpoint CFO accepts the commitment boundary without representing it as final lifecycle cost.

Human control point Procurement and finance accept commercial facts; executives accept exposure.

Failure modes and safeguards Never invent missing prices, rates, capacity or provider concessions.

Change, stop or escalation condition Escalate opaque price adjustment, unlimited organisation dependency or misaligned risk allocation.

Handoff to the next step Commercial structure enters IP, account and exit control.

Step 09: Secure IP, accounts, data, handover, support and exit

Purpose and decision served Ensure the organisation can lawfully use, operate, change and leave the delivered service.

Accountable owner CIO/CTO.

Delegated lead and contributors Legal, procurement, security, data, operations, finance and provider delivery lead.

Preconditions, inputs and access Proposed contract, component inventory, account model, support design and exit scenario.

Actions

1. Record ownership and licences for commissioned work, pre-existing materials, open-source and third-party components.
2. Require organisation-controlled repositories, cloud accounts, domains, credentials, telemetry, documentation and export routes where appropriate.
3. Define knowledge transfer, support levels, vulnerability work, continuity, termination assistance, data return/deletion and verification.

Evidence to retain IP schedule, component register, account matrix, handover plan, support terms, exit plan and legal decisions.

Decision or scoring rule Appointment fails when a mandatory right, account, operational artefact or executable exit remains unavailable.

Output and template IP, support and exit rows in T03.

Acceptance gate ACCEPT, CONDITION, VALIDATE or REJECT.

Leadership checkpoint CIO/CTO sees lock-in and residual provider dependence explicitly.

Human control point Qualified legal authority decides actual rights; operations accepts only demonstrable handover obligations.

Failure modes and safeguards Do not claim ownership merely because the organisation paid for work or confuse documentation delivery with capability transfer.

Change, stop or escalation condition Reject absent rights to use and operate the service, unrecoverable accounts or non-executable exit.

Handoff to the next step All evidence is reconciled into non-compensating appointment gates.

Step 10: Reconcile evidence and mandatory gates

Purpose and decision served Prevent presentation quality or aggregate scores from hiding a material failed condition.

Accountable owner Independent Challenger.

Delegated lead and contributors Evidence custodian and every decision-domain owner.

Preconditions, inputs and access Complete registers, source artefacts, provider responses, deviations and dissent.

Actions

1. Reconcile every material claim to source, scope, date, owner, limitation and proof status.
2. Keep discovery, architecture, security, quality, commercial, IP, handover, support and exit gates separate.
3. Classify each as accepted within scope, conditional, validate or reject and record non-response.

Evidence to retain Reconciliation report, mandatory-gate matrix, contradictions, dissent and unresolved gaps.

Decision or scoring rule A failed mandatory gate cannot be averaged away by strengths elsewhere.

Output and template Gate and disposition rows in T04.

Acceptance gate DECISION-FIT, VALIDATE, RETURN or STOP.

Leadership checkpoint CIO/CTO reviews failed gates before rankings or recommendations.

Human control point Each qualified authority confirms only its evidence and disposition.

Failure modes and safeguards Reject weighted totals that conceal veto conditions or treat missing evidence as a neutral score.

Change, stop or escalation condition Validate or stop where a gap could reverse appointment or expose affected people materially.

Handoff to the next step Decision-fit evidence becomes a conditional appointment recommendation.

Step 11: Decide and contract the bounded appointment

Purpose and decision served Record an accountable human disposition with enforceable conditions and limits.

Accountable owner Appointment Authority.

Delegated lead and contributors CIO/CTO, Product Sponsor, CFO, procurement, legal, risk and challenger.

Preconditions, inputs and access Decision-fit pack, commercial authority, deviations, conditions, remedies and unresolved dissent.

Actions

1. Choose one primary disposition and state why alternatives were rejected or deferred.
2. Translate every condition into owner, evidence gate, due point, remedy and stop right.
3. Record commitment ceiling, exclusions, residual exposure, dissent and expiry of appointment evidence.

Evidence to retain Signed decision, negotiated schedules, deviation approvals, conditions and authority evidence.

Decision or scoring rule Appoint only inside accepted authority and only when every mandatory condition is closed or contractually gated before exposure.

Output and template Appointment decision rows in T04.

Acceptance gate APPOINT WITHIN BOUNDARY, CONDITION, VALIDATE, CHANGE, DEFER, REJECT or STOP.

Leadership checkpoint Appointment Authority confirms the decision is not delivery or production acceptance.

Human control point Only authorised humans accept commercial, legal, security and residual-risk conditions.

Failure modes and safeguards Do not describe unsigned negotiation positions, provider promises or preferred terms as accepted controls.

Change, stop or escalation condition Stop when a negotiated change invalidates technical evidence, authority, affordability or a mandatory gate.

Handoff to the next step The bounded appointment transfers into The Product Delivery Governance Standard: From Discovery through Production Acceptance delivery governance.

Step 12: Hand over, verify mobilisation and preserve exit

Purpose and decision served Ensure appointment conditions become operating delivery controls rather than archived diligence.

Accountable owner Product Sponsor.

Delegated lead and contributors The Product Delivery Governance Standard: From Discovery through Production Acceptance delivery authority, product, technology, security, operations, procurement, finance and provider lead.

Preconditions, inputs and access Signed appointment, condition register, accounts, repositories, delivery charter and escalation routes.

Actions

1. Transfer requirements, evidence, decisions, conditions, owners, stop rights and unresolved validation into The Product Delivery Governance Standard: From Discovery through Production Acceptance.
2. Verify named team, access, organisation-controlled accounts, initial artefacts, reporting and incident routes at mobilisation.
3. Schedule condition reviews, provider-change triggers, handover demonstrations and exit-readiness evidence.

Evidence to retain Handover acceptance, mobilisation verification, condition status, repository/account evidence and review schedule.

Decision or scoring rule Mobilisation continues only while the contracted team, controls and evidence boundary match the appointment.

Output and template Handover and review rows in T04.

Acceptance gate HANDOVER ACCEPTED, CORRECT, SUSPEND or STOP.

Leadership checkpoint Sponsor confirms The Product Delivery Governance Standard: From Discovery through Production Acceptance owns delivery decisions and that exit remains executable.

Human control point Receiving owners accept actual access and artefacts, not a future delivery promise.

Failure modes and safeguards Do not allow team substitution, account drift or unresolved appointment conditions to disappear into delivery backlog.

Change, stop or escalation condition Reopen appointment when entity, key team, scope, architecture, control, price basis, IP, support or exit conditions materially change.

Handoff to the next step The Product Delivery Governance Standard: From Discovery through Production Acceptance governs delivery; material provider changes return to this appointment gate.

4. The Evidence & Measurement Checklist

Preflight and authority

• One bounded appointment and decision date are named. Evidence: signed charter. Owner: CIO/CTO.
• Appointment is separate from funding, delivery and production authority. Evidence: authority map. Owner: Product Sponsor.
• Reject and stop remain credible dispositions. Evidence: charter. Owner: Appointment Authority.
• Provider, sponsor and evaluator conflicts are disclosed. Evidence: conflict register. Owner: Procurement Lead.
• Confidential evidence access and retention are controlled. Evidence: access protocol. Owner: Security Authority.

Evidence access and quality

• Requirements use the same outcome and risk meaning for every provider. Evidence: normalised register. Owner: Product Lead.
• Provider legal entity and contracting authority are verified. Evidence: entity record. Owner: Procurement Lead.
• Proposed named roles and allocation assumptions are explicit. Evidence: team matrix. Owner: CTO.
• Material claims link to scoped evidence or authorised references. Evidence: claim ledger. Owner: Evidence Custodian.
• Missing evidence remains REQUIRES VALIDATION rather than a neutral score. Evidence: gap register. Owner: Challenger.

Method execution

• Discovery practice can falsify a preferred scope. Evidence: method demonstration. Owner: Product Sponsor.
• Architecture evidence traces requirement to operation and recovery. Evidence: technical trace. Owner: Architecture Authority.
• Secure-development and vulnerability response are inspected. Evidence: security mapping. Owner: Security Authority.
• Quality includes accessibility, security, performance and recovery. Evidence: quality strategy. Owner: Quality Authority.
• Mandatory failures cannot be offset by aggregate strength. Evidence: gate matrix. Owner: Challenger.

Governance, privacy, security and risk

• Qualified authorities retain legal, privacy, security and accessibility decisions. Evidence: referral record. Owner: CIO/CTO.
• Evidence inspection minimises unnecessary sensitive disclosure. Evidence: diligence protocol. Owner: Security Authority.
• Organisation-controlled accounts and repositories are defined. Evidence: account matrix. Owner: CTO.
• Incident notification, containment and evidence duties are enforceable. Evidence: contract schedule. Owner: Security Authority.
• Subcontractors and third-party dependencies remain visible. Evidence: dependency register. Owner: Procurement Lead.

Deliverables and acceptance

• Commercial rows state unit, scope, inclusion, exclusion and dependency. Evidence: normalised schedule. Owner: Finance Lead.
• Organisation work and scarce capacity are visible. Evidence: responsibility matrix. Owner: COO.
• Change and rework mechanisms are explicit. Evidence: change schedule. Owner: Procurement Lead.
• IP, licence and third-party component rights are decided by qualified authority. Evidence: IP schedule. Owner: Legal Authority.
• Handover, support and exit obligations have testable evidence. Evidence: operating schedule. Owner: Service Owner.

Measurement

• Proposed-team evidence coverage is reported without claiming competence. Evidence: team register. Owner: CTO.
• Mandatory diligence gates are reported separately. Evidence: gate matrix. Owner: Challenger.
• Appointment conditions have owner, due point and closure evidence. Evidence: condition register. Owner: Procurement Lead.
• Organisation dependency and provider concentration remain visible. Evidence: dependency measure. Owner: COO.
• Commercial comparison never invents missing prices or concessions. Evidence: source trace. Owner: CFO.

Decision and handover

• One primary appointment disposition is signed. Evidence: decision record. Owner: Appointment Authority.
• Rejected alternatives, dissent and limitations are retained. Evidence: decision pack. Owner: Challenger.
• Every condition maps to a contractual or pre-exposure gate. Evidence: condition schedule. Owner: Procurement Lead.
• Receiving The Product Delivery Governance Standard: From Discovery through Production Acceptance owners accept evidence and stop rights. Evidence: handover acceptance. Owner: Product Sponsor.
• Appointment evidence expiry and change triggers are recorded. Evidence: review register. Owner: CIO/CTO.

Review, change and stop controls

• Entity, key-team or subcontractor change reopens verification. Evidence: trigger record. Owner: Procurement Lead.
• Material architecture or control change returns to qualified review. Evidence: change record. Owner: CTO.
• Lost account, repository or evidence access triggers containment. Evidence: incident record. Owner: Service Owner.
• Failed handover or exit demonstration blocks dependency increase. Evidence: rehearsal. Owner: COO.
• Misrepresentation or concealed material risk bypasses routine review. Evidence: escalation record. Owner: Appointment Authority.

Measurement contracts

Measure A: Decision-critical provider evidence coverage

Measure B: Mandatory appointment-gate fitness

Measure C: Appointment-condition closure

Measure D: Handover and account-control readiness

Measure E: Provider-dependence exposure

Measure F: Diligence-to-delivery trace integrity

Evidence classifications used in this guide

• VERIFIED: an authoritative source supports a fact within its retained scope, date and limitation.
• INFERRED: a transparent interpretation follows from evidence but remains distinguishable from fact.
• PROPOSED: a requirement, control, commercial term, threshold or disposition awaits authorised human acceptance.
• REQUIRES VALIDATION: provider identity, capacity, practice, price, right, control or outcome is not yet decision-fit.

Controlled source record