Research Payload Family
Research Payload Family shared core v0.1.0
Payload candidate for carrying a named need through supplier evidence, evaluation, contract terms, acceptance, change, renewal, portability, transition, and exit rehearsal.
v0.1.1
Candidate state: this page defines the research job, lifecycle, evidence requests, outputs, and promotion test for a reusable vendor-evidence payload. A complete procurement-to-exit specimen and run receipt remain the evidence needed for executable status.
Research job
Support a named decision about selecting, accepting, renewing, changing, transitioning, or exiting an AI-enabled product or service.
The candidate treats procurement as a lifecycle:
- define the need and affected population;
- compare credible solution routes;
- request and assess evidence;
- design contract and acceptance terms;
- verify the delivered system;
- monitor service and material change;
- decide on renewal;
- rehearse portability, transition, and exit.
The result should keep supplier claims, independent evidence, local testing, contract authority, and operational experience distinct.
Why this candidate is timely
UK Guidelines for AI Procurement presents AI procurement as multidisciplinary work involving problem definition, data readiness, public benefit, risk, market engagement, and the full procurement process. The guidance also recognizes that AI capability may be embedded inside products whose headline requirement is broader than AI.
Section508.gov’s acquisition guidance connects requirements, market research, vendor conformance evidence, acceptance criteria, hands-on validation, and continuing testing across the contract lifecycle.
These are valuable source seeds. Each execution still binds the governing jurisdiction, organization, contract, sector, data, affected population, and accountable authority.
Required parameters
Parameter | Required entry |
Need | Observable problem, affected population, current practice, and desired outcome |
Decision stage | Explore, shortlist, select, contract, accept, renew, transition, or exit |
Organization and jurisdiction | Governing policy, procurement route, regulator, and authority |
Solution routes | Process change, internal build, open source, managed service, platform, specialist vendor, or hybrid |
Data and rights | Sources, owners, allowed uses, retention, deletion, transfer, and model exposure |
System boundary | Model, software, tools, integrations, hosting, subcontractors, and human work |
Consequence | Safety, privacy, access, money, identity, quality, continuity, or reversibility |
Evidence date | Retrieval cutoff, version, and review date |
Accountable receivers | Business, technical, security, privacy, accessibility, legal, procurement, finance, and domain roles as fitting |
Exit horizon | Contract end, switching trigger, portability requirement, and continuity need |
Lifecycle evidence map
Stage | Material evidence | Observable decision |
Need and alternatives | Workflow observation, affected-population input, baseline measures, credible non-vendor routes | Proceed to market, revise the need, or use another route |
Market and shortlist | Supplier landscape, deployment fit, architecture, data, accessibility, financial and concentration evidence | Shortlist with visible comparison |
Due diligence | Documentation, demonstrations, references, independent tests, incident and change history | Invite, condition, defer, or decline |
Contract design | Requirements, acceptance, change notice, audit, service, recourse, data, IP, deletion, export, transition | Establish enforceable expectations |
Acceptance | Local fixtures, integration, accessibility, security, workflow, recovery, and documentation tests | Accept, conditionally accept, remediate, or reject |
Operation | Service measures, incidents, updates, overrides, user and affected-population evidence | Continue, restrict, remediate, or escalate |
Renewal | Outcomes, total cost, material change, alternatives, dependence, unresolved gaps | Renew, renegotiate, compete, transition, or exit |
Exit | Export, schema, identity, provenance, deletion, continuity, rollback, and rehearsal | Complete a recoverable transition |
Evidence-request spine
Problem and product fit
- named outcome and affected groups;
- intended and adjacent uses;
- implementation pattern;
- customer responsibilities;
- operating assumptions;
- known exclusions;
- current alternatives.
Model and system identity
- model, version, hosting, tools, retrieval, and software components;
- update cadence;
- subcontractors and external services;
- customer controls;
- material-change definition;
- change notification and evidence refresh.
Data, privacy, and provenance
- data sources and roles;
- training, retrieval, logging, support, evaluation, and secondary-use boundaries;
- retention, deletion, export, correction, and geographic processing;
- provenance and lineage;
- incident and access evidence.
Performance and evaluation
- context of use;
- task and population;
- metrics, denominators, thresholds, confidence, and failure modes;
- subgroup and accessibility evidence;
- independent and local validation;
- drift, monitoring, and reassessment.
Security and resilience
- threat model;
- access and isolation;
- dependency and incident management;
- backup, recovery, rollback, and continuity;
- service objectives;
- evidence from exercises.
Accessibility and human use
- applicable requirements;
- Accessibility Conformance Report or equivalent claims;
- manual and automated testing;
- assistive-technology evidence;
- user workflows, error recovery, support, and recourse.
Commercial and exit
- price units and growth assumptions;
- implementation and operating costs;
- usage and data-egress costs;
- minimums, commitments, and price-change terms;
- ownership and license;
- export format and timing;
- transition support;
- deletion evidence;
- concentration and switching risk.
Claim handling
Classify every material statement as:
- supplier-reported;
- independently evidenced;
- locally observed;
- contractually committed;
- inferred with stated basis;
- open;
- contradicted.
A certification, benchmark, case study, or conformance report supports claims within its exact scope and date. Acceptance evidence connects the claim to the receiving environment.
Record each material result as passed, failed, partial, open, unavailable, expired, superseded, or inapplicable, with its evidence date and claim ceiling. Stable trace identifiers connect the requirement, claim, supplier evidence, local acceptance test, contract term, monitoring signal, and exit test.
Research demands
- Define the need and credible alternative routes.
- Establish the affected population and consequence.
- Build the supplier and evidence inventory.
- Map architecture, data, model, tool, dependency, and human-work boundaries.
- Compare claims by class and source independence.
- Design acceptance tests from material requirements.
- Define contract terms for change, evidence refresh, incidents, accessibility, data, and recourse.
- Model whole-life cost, renewal leverage, concentration, and switching.
- Rehearse export, transition, rollback, and deletion evidence.
- Return a bounded decision and next receiver.
Minimum output contract
- need and alternative-route statement;
- parameter and authority register;
- supplier evidence ledger;
- architecture and data-boundary map;
- requirements and claim-class matrix;
- evaluation and acceptance plan;
- contract-term register;
- operational monitoring and change plan;
- whole-life cost and concentration analysis;
- portability and exit rehearsal;
- bounded recommendation;
- run receipt and re-entry event.
Acceptance and exit examples
Requirement | Supplier evidence | Local acceptance test | Contract consequence | Exit evidence |
Preserve source citations in generated analysis | Product documentation and demonstration | Named fixture resolves every material claim to the correct source | Acceptance threshold and correction window | Export retains source identity and version |
Keyboard-operable workflow | Current ACR and test evidence | Hands-on keyboard and assistive-technology path | Remediation and acceptance condition | Exported records remain accessible |
Idempotent external action | Architecture statement and API contract | Duplicate request produces one durable outcome | Incident, correction, and service term | Pending actions reconcile during transition |
Customer-data deletion | Policy and contract commitment | Deletion request and evidence receipt | Time bound, audit, and escalation | Final deletion and backup-expiry evidence |
Companion instruments
- Research Payload Family — Shared Core
- Layered Investment, Value, Cash & Capital
- Evidence-Bearing Verification Annex
- Decision & Data Shape Parameter Pack
Promotion work
Executable status requires:
- one complete specimen from need through exit rehearsal;
- at least two credible solution routes;
- one supplier claim that local evidence narrows, confirms, or contradicts;
- one accessibility acceptance case;
- one data or model-change case;
- one portability or deletion rehearsal;
- one partial or unavailable evidence case;
- one run receipt;
- fitting procurement, technical, domain, accessibility, and data/privacy review.
Until those observations exist, this page remains a public-grade candidate and a usable scoping surface.
Focused refinement from dry run
The synthetic procurement-to-exit specimen and its separate run receipt exercised alternatives, supplier evidence, accessibility acceptance, material change, renewal, portability, deletion, continuity, and handback.
The run established control-flow coherence and exposed four focused improvements now carried by v0.1.1:
- stable trace fields connect each requirement, claim, supplier evidence item, local acceptance test, contract term, monitoring signal, and exit test;
- a shared result vocabulary carries evidence date and claim ceiling;
- the run receipt, stopping condition, and reopening event are required outputs;
- evidence from synthetic execution and evidence for promotion remain distinct, so an instrumented run and accountable multidisciplinary review retain their own evidence standing.
The candidate remains Blooming. The next promotion observation is a fitting instrumented run with procurement, technical, accessibility, privacy/data, and domain receivers.