From 6aaaaa6a56ac95fa7fc8c2d09cb2ec2bfb8a6a71 Mon Sep 17 00:00:00 2001 From: hinotoi-agent Date: Fri, 15 May 2026 20:40:28 +0800 Subject: [PATCH] docs: add model and retention record templates --- standard/5_Auditability/README.md | 2 +- standard/7_Supply_Chain_Trust/README.md | 6 +- standard/Getting_Started.md | 2 + standard/README.md | 2 + ..._Retention_and_Disposal_Record_Template.md | 389 ++++++++++++++++++ .../Model_Change_and_Drift_Record_Template.md | 366 ++++++++++++++++ 6 files changed, 763 insertions(+), 4 deletions(-) create mode 100644 standard/appendix/Data_Retention_and_Disposal_Record_Template.md create mode 100644 standard/appendix/Model_Change_and_Drift_Record_Template.md diff --git a/standard/5_Auditability/README.md b/standard/5_Auditability/README.md index 16530e5..f009940 100644 --- a/standard/5_Auditability/README.md +++ b/standard/5_Auditability/README.md @@ -820,7 +820,7 @@ When the platform depends on external AI/ML models (for example, third-party LLM 8. If baseline test results deviate beyond a defined tolerance on any safety-critical decision, the platform MUST alert the operator and MUST NOT proceed with affected decision paths until the drift is reviewed and acknowledged. 9. Drift detection results MUST be logged and available to customers. -> **See also:** APTS-TP-002 (model version pinning), APTS-TP-019 (model provenance and training data governance), APTS-TP-022 (re-attestation on material model change), APTS-AR-017 (regression testing triggered by model updates), APTS-AR-018 (customer notification for behavior-affecting model updates). +> **See also:** APTS-TP-002 (model version pinning), APTS-TP-019 (model provenance and training data governance), APTS-TP-022 (re-attestation on material model change), APTS-AR-017 (regression testing triggered by model updates), APTS-AR-018 (customer notification for behavior-affecting model updates). For an illustrative evidence format, see the [Model Change and Drift Record Template](../appendix/Model_Change_and_Drift_Record_Template.md). ### Verification diff --git a/standard/7_Supply_Chain_Trust/README.md b/standard/7_Supply_Chain_Trust/README.md index f057d80..bf25b28 100644 --- a/standard/7_Supply_Chain_Trust/README.md +++ b/standard/7_Supply_Chain_Trust/README.md @@ -107,7 +107,7 @@ Organizations MUST implement version pinning for all AI models to enable change - Find rollback procedure documentation - Verify testing before production deployment -> **See also:** APTS-AR-019 (AI/ML model change tracking and drift detection), APTS-TP-019 (AI model provenance and training data governance) +> **See also:** APTS-AR-019 (AI/ML model change tracking and drift detection), APTS-TP-019 (AI model provenance and training data governance). For an illustrative evidence format, see the [Model Change and Drift Record Template](../appendix/Model_Change_and_Drift_Record_Template.md). --- @@ -409,7 +409,7 @@ Organizations MUST establish and document a data retention policy that specifies - Verify deletion method is documented and appropriate to the storage medium - Check audit logs: verify deletion events are recorded with timestamp and method -> **See also:** APTS-TP-016 (data destruction proof and certification) +> **See also:** APTS-TP-016 (data destruction proof and certification). For an illustrative evidence format, see the [Data Retention and Disposal Record Template](../appendix/Data_Retention_and_Disposal_Record_Template.md). --- @@ -623,7 +623,7 @@ Foundation model changes are not routine dependency updates. A model upgrade can 4. **Customer notification review:** Verify that customers with active engagements at the time of the change were notified within the timeframe stated in the operator's policy, and that the notification included the outcome of the re-assessment. 5. **Rollback test:** Verify that the prior model configuration and disclosure are preserved and that the operator's runbook supports reverting to the prior configuration under APTS-TP-002. -> **See also:** APTS-TP-001 (provider vetting), APTS-TP-002 (model version pinning and change management), APTS-TP-021 (foundation model disclosure and capability baseline), APTS-AR-019 (continuous model change tracking and drift detection). +> **See also:** APTS-TP-001 (provider vetting), APTS-TP-002 (model version pinning and change management), APTS-TP-021 (foundation model disclosure and capability baseline), APTS-AR-019 (continuous model change tracking and drift detection). For an illustrative evidence format, see the [Model Change and Drift Record Template](../appendix/Model_Change_and_Drift_Record_Template.md). --- diff --git a/standard/Getting_Started.md b/standard/Getting_Started.md index e4ff7bf..a7a0514 100644 --- a/standard/Getting_Started.md +++ b/standard/Getting_Started.md @@ -83,6 +83,8 @@ Depending on your role: | [Scope Change Decision Record Template](appendix/Scope_Change_Decision_Record_Template.md) | Informative | Template for documenting approved, rejected, constrained, or deferred scope changes during an engagement | | [Autonomy Downgrade Matrix Template](appendix/Autonomy_Downgrade_Matrix_Template.md) | Informative | Template for documenting downgrade triggers, autonomy caps, re-authorization paths, and evidence preservation | | [Threshold Configuration Template](appendix/Threshold_Configuration_Template.md) | Informative | Simple starter table for documenting operational thresholds, escalation points, and stop conditions | +| [Model Change and Drift Record Template](appendix/Model_Change_and_Drift_Record_Template.md) | Informative | Template for documenting model changes, behavioral comparisons, drift detections, re-attestation decisions, and rollback evidence | +| [Data Retention and Disposal Record Template](appendix/Data_Retention_and_Disposal_Record_Template.md) | Informative | Template for documenting retention decisions, secure deletion, disposal verification, exceptions, and customer deletion requests | | [Advisory Requirements](appendix/Advisory_Requirements.md) | Informative | Best-practice requirements not gated to any compliance tier | ## Common Questions diff --git a/standard/README.md b/standard/README.md index 3ba13ba..ee319c4 100644 --- a/standard/README.md +++ b/standard/README.md @@ -38,6 +38,8 @@ The [appendices](./appendix/) provide cross-cutting resources: checklists, compl | [Scope Change Decision Record Template](./appendix/Scope_Change_Decision_Record_Template.md) | Informative template for documenting approved, rejected, constrained, or deferred scope changes during an engagement | | [Autonomy Downgrade Matrix Template](./appendix/Autonomy_Downgrade_Matrix_Template.md) | Informative template for documenting downgrade triggers, autonomy caps, re-authorization paths, and evidence preservation | | [Threshold Configuration Template](./appendix/Threshold_Configuration_Template.md) | Simple starter table for documenting operational thresholds, escalation points, and stop conditions | +| [Model Change and Drift Record Template](./appendix/Model_Change_and_Drift_Record_Template.md) | Informative template for documenting model changes, behavioral comparison, drift review, re-attestation, and rollback evidence | +| [Data Retention and Disposal Record Template](./appendix/Data_Retention_and_Disposal_Record_Template.md) | Informative template for documenting retention decisions, disposal execution, deletion verification, exceptions, and customer deletion requests | | [Evidence Package Manifest](./appendix/Evidence_Package_Manifest.md) | Illustrative manifest for finding evidence, provenance, and downstream handoff | | [Evidence Package Manifest Example](./appendix/examples/Evidence_Package_Manifest_Example.md) | Fictional completed example showing finding evidence, provenance, redaction, and export handoff | | [Conformance Claim Schema](./appendix/Conformance_Claim_Schema.md) | Illustrative machine-readable schema for structured conformance claims | diff --git a/standard/appendix/Data_Retention_and_Disposal_Record_Template.md b/standard/appendix/Data_Retention_and_Disposal_Record_Template.md new file mode 100644 index 0000000..0dce593 --- /dev/null +++ b/standard/appendix/Data_Retention_and_Disposal_Record_Template.md @@ -0,0 +1,389 @@ +# Data Retention and Disposal Record Template + +Informative Appendix (non-normative) + +This appendix provides an illustrative template for documenting data retention, secure deletion, disposal verification, exceptions, and customer-requested deletion events in autonomous penetration testing workflows. It is intended to help platform operators, customers, and reviewers collect evidence for existing APTS requirements. It does not create or modify any APTS requirement. + +## Purpose + +APTS requires operators to define retention periods by data classification, justify retention, track expiration dates, securely delete data, verify deletion, and provide destruction proof at higher assurance tiers. Those activities are often split across evidence stores, vaults, logs, backups, and ticketing systems. + +This appendix provides: + +- a compact record structure for retention and disposal events +- an example YAML record +- a JSON-equivalent structure +- review questions for customers and reviewers +- cross-references to the APTS requirements this artifact helps support + +## Primary Use Cases + +Consider using this record when documenting: + +- retention decisions for engagement data sets +- retention exceptions or customer-approved extensions +- routine disposal at the end of a retention period +- customer-initiated deletion requests +- credential or restricted-data purge events +- backup, archive, or derived-artifact deletion tracking +- evidence supporting a data destruction certificate + +## Design Principles + +A retention and disposal record should: + +- identify the data set without exposing unnecessary sensitive content +- link each data class to a retention period and justification +- record expiration dates and reminder events +- distinguish primary storage, backup storage, archives, logs, and derived artifacts +- document the secure deletion method used for each storage medium +- preserve verification evidence that retrieval or recovery was expected to fail +- capture exceptions, legal holds, customer approvals, and deletion-request handling + +## Recommended Template Sections + +### 1. Record metadata + +Use stable identifiers so the record can be correlated with engagement records, evidence manifests, deletion logs, and customer requests. + +Recommended fields: + +- `record_id` +- `engagement_id` +- `customer_reference` +- `data_set_id` +- `record_status` +- `created_at` +- `last_updated_at` +- `owner` +- `reviewers` + +Suggested `record_status` values: + +- `active_retention` +- `deletion_scheduled` +- `deletion_completed` +- `exception_active` +- `legal_hold_active` +- `customer_request_in_progress` + +### 2. Data set inventory + +Describe the data set and related locations without embedding the sensitive data itself. + +Recommended fields: + +- `data_category` +- `classification` +- `source_system` +- `storage_locations` +- `derived_artifacts` +- `backup_locations` +- `contains_credentials` +- `contains_personal_data` +- `contains_customer_confidential_data` +- `evidence_manifest_reference` + +Suggested `data_category` values: + +- `finding_report` +- `raw_scan_data` +- `credential_or_secret` +- `audit_log` +- `screenshot_or_recording` +- `tool_output` +- `customer_upload` +- `derived_summary` +- `backup_or_archive` + +### 3. Retention basis + +Document why the data is retained and when it should expire. + +Recommended fields: + +- `retention_period` +- `retention_start_at` +- `retention_expires_at` +- `retention_basis` +- `contractual_reference` +- `regulatory_reference` +- `operational_need` +- `customer_approval_reference` +- `reminder_schedule` +- `next_review_at` + +### 4. Exceptions and holds + +Capture any condition that extends or suspends deletion. + +Recommended fields: + +- `exception_type` +- `exception_reason` +- `approved_by` +- `approved_at` +- `approval_reference` +- `new_expiration_date` +- `legal_hold_reference` +- `customer_notification_reference` + +Suggested `exception_type` values: + +- `customer_approved_extension` +- `legal_hold` +- `regulatory_obligation` +- `incident_investigation` +- `billing_or_dispute_hold` +- `none` + +### 5. Disposal execution + +Record the deletion action by storage medium and location. + +Recommended fields: + +- `deletion_request_id` +- `deletion_trigger` +- `scheduled_deletion_at` +- `deletion_started_at` +- `deletion_completed_at` +- `storage_medium` +- `deletion_method` +- `responsible_system_or_role` +- `deletion_log_reference` +- `cryptographic_key_reference` + +Suggested `deletion_method` values: + +- `cryptographic_erasure` +- `provider_secure_delete_api` +- `nist_sp_800_88_clear` +- `nist_sp_800_88_purge` +- `multi_pass_overwrite` +- `manufacturer_secure_erase` +- `physical_destruction` + +### 6. Verification and recovery test + +Record how deletion was verified and whether recovery attempts failed as expected. + +Recommended fields: + +- `primary_storage_verified` +- `backup_storage_verified` +- `archive_storage_verified` +- `derived_artifacts_verified` +- `recovery_test_performed` +- `recovery_test_result` +- `verification_method` +- `verified_by` +- `verified_at` +- `verification_evidence_reference` + +Suggested `recovery_test_result` values: + +- `not_recoverable` +- `partially_recoverable_requires_remediation` +- `recoverable_failed` +- `not_applicable_documented` + +### 7. Customer request handling + +Use this section for customer-initiated deletion, erasure, or disposal requests. + +Recommended fields: + +- `customer_request_id` +- `request_received_at` +- `request_type` +- `acknowledged_at` +- `acknowledgement_reference` +- `processing_sla` +- `completed_within_sla` +- `customer_certificate_reference` + +Suggested `request_type` values: + +- `engagement_data_deletion` +- `credential_purge` +- `data_subject_erasure` +- `contract_end_disposal` +- `evidence_package_removal` + +### 8. Evidence checklist + +Attach or reference the artifacts customers and reviewers may request. + +Recommended evidence: + +- data classification record +- retention policy mapping +- retention exception approval, if applicable +- reminder or expiration notification +- deletion job log +- secure deletion method evidence +- backup/archive deletion evidence +- failed recovery test evidence +- destruction certificate, when applicable +- customer acknowledgement or notification, when applicable + +## Example YAML Template + +```yaml +record_id: rdr-2026-0081 +engagement_id: eng-2026-001 +customer_reference: customer-acme +record_status: deletion_completed +created_at: 2026-04-01T09:00:00Z +last_updated_at: 2026-07-01T12:45:00Z +owner: data-governance +reviewers: + - platform-security-01 + +data_set: + data_set_id: raw-scan-data-eng-2026-001 + data_category: raw_scan_data + classification: confidential + source_system: web-scanner + storage_locations: + - object-store://engagements/eng-2026-001/raw-scan-data/ + derived_artifacts: + - evidence-manifest:epm-2026-001 + - report-draft:report-2026-001-v2 + backup_locations: + - backup-set-2026-04-week-1 + contains_credentials: false + contains_personal_data: true + contains_customer_confidential_data: true + evidence_manifest_reference: epm-2026-001 + +retention: + retention_period: 90_days + retention_start_at: 2026-04-01T00:00:00Z + retention_expires_at: 2026-06-30T23:59:59Z + retention_basis: contractual_engagement_terms + contractual_reference: msa-2026-acme-section-7 + regulatory_reference: none + operational_need: support customer validation and retest window + customer_approval_reference: customer-approval-2026-041 + reminder_schedule: + - 2026-05-31T09:00:00Z + - 2026-06-23T09:00:00Z + next_review_at: 2026-06-23T09:00:00Z + +exception_or_hold: + exception_type: none + exception_reason: null + approved_by: null + approved_at: null + approval_reference: null + new_expiration_date: null + legal_hold_reference: null + customer_notification_reference: null + +disposal: + deletion_request_id: del-2026-0081 + deletion_trigger: retention_expired + scheduled_deletion_at: 2026-07-01T10:00:00Z + deletion_started_at: 2026-07-01T10:03:00Z + deletion_completed_at: 2026-07-01T10:18:00Z + locations: + - storage_location: object-store://engagements/eng-2026-001/raw-scan-data/ + storage_medium: cloud_object_storage + deletion_method: provider_secure_delete_api + responsible_system_or_role: retention-worker + deletion_log_reference: logs/deletion/del-2026-0081-primary.json + - storage_location: backup-set-2026-04-week-1 + storage_medium: encrypted_backup + deletion_method: cryptographic_erasure + responsible_system_or_role: backup-controller + deletion_log_reference: logs/deletion/del-2026-0081-backup.json + cryptographic_key_reference: key-destruction-log-2026-0081 + +verification: + primary_storage_verified: true + backup_storage_verified: true + archive_storage_verified: true + derived_artifacts_verified: true + recovery_test_performed: true + recovery_test_result: not_recoverable + verification_method: retrieval_attempt_and_key-destruction-check + verified_by: platform-security-01 + verified_at: 2026-07-01T12:30:00Z + verification_evidence_reference: evidence/deletion/del-2026-0081-verification.md + +customer_request: + customer_request_id: null + request_received_at: null + request_type: null + acknowledged_at: null + acknowledgement_reference: null + processing_sla: null + completed_within_sla: null + customer_certificate_reference: destruction-certificate-2026-0081.pdf +``` + +## JSON-Equivalent Structure + +```json +{ + "record_id": "rdr-2026-0081", + "engagement_id": "eng-2026-001", + "record_status": "deletion_completed", + "data_set": { + "data_set_id": "raw-scan-data-eng-2026-001", + "data_category": "raw_scan_data", + "classification": "confidential", + "contains_personal_data": true, + "evidence_manifest_reference": "epm-2026-001" + }, + "retention": { + "retention_period": "90_days", + "retention_expires_at": "2026-06-30T23:59:59Z", + "retention_basis": "contractual_engagement_terms" + }, + "disposal": { + "deletion_request_id": "del-2026-0081", + "deletion_trigger": "retention_expired", + "deletion_completed_at": "2026-07-01T10:18:00Z" + }, + "verification": { + "primary_storage_verified": true, + "backup_storage_verified": true, + "recovery_test_performed": true, + "recovery_test_result": "not_recoverable" + } +} +``` + +## Field Mapping to APTS Requirements + +| Record area | Primary requirements | +| --- | --- | +| Data classification and storage inventory | `APTS-TP-012`, `APTS-TP-013`, `APTS-AR-015` | +| Retention period, basis, reminders, and exceptions | `APTS-TP-015` | +| Credential and restricted-data handling | `APTS-MR-019`, `APTS-TP-015` | +| Deletion method and disposal execution logs | `APTS-TP-015`, `APTS-TP-016` | +| Recovery testing and verification evidence | `APTS-TP-015`, `APTS-TP-016` | +| Customer-requested deletion handling | `APTS-TP-015`, `APTS-TP-016` | +| Evidence package and downstream handoff references | `APTS-AR-010`, `APTS-RP-005`, `APTS-RP-015` | + +## Validation Guidance for Customers and Reviewers + +When reviewing a retention and disposal record, consider asking: + +1. Does the record identify the data set and storage locations without disclosing unnecessary sensitive content? +2. Is the retention period justified by classification, contract, regulation, or operational need? +3. Are credentials and restricted data subject to shorter retention periods where required? +4. Were expiration reminders and periodic reviews recorded before deletion? +5. If retention was extended, is there an approved exception, legal hold, or customer authorization? +6. Does the deletion method match the storage medium and the operator's documented policy? +7. Were primary storage, backup storage, archives, and derived artifacts all considered? +8. Did recovery or retrieval tests fail as expected, or is any recoverable data tracked for remediation? +9. If the customer initiated deletion, was the request acknowledged and completed within the documented SLA? +10. Is a destruction certificate available when required by the platform's tier or customer agreement? + +## Usage Notes + +This template is intentionally illustrative. Operators may keep equivalent records in governance platforms, data catalogs, ticketing systems, vaults, deletion pipelines, or customer portals as long as the evidence is complete, reviewable, and available to customers when required by APTS. diff --git a/standard/appendix/Model_Change_and_Drift_Record_Template.md b/standard/appendix/Model_Change_and_Drift_Record_Template.md new file mode 100644 index 0000000..c95964d --- /dev/null +++ b/standard/appendix/Model_Change_and_Drift_Record_Template.md @@ -0,0 +1,366 @@ +# Model Change and Drift Record Template + +Informative Appendix (non-normative) + +This appendix provides an illustrative template for documenting model changes, behavioral comparisons, drift detections, human review, and rollback decisions for autonomous penetration testing platforms. It is intended to help platform operators, customers, and reviewers collect evidence for existing APTS requirements. It does not create or modify any APTS requirement. + +## Purpose + +APTS requires operators to pin model versions, track AI/ML model changes, validate behavior after changes, detect behavioral drift, and re-attest after material foundation model changes. Those activities often involve several teams and artifacts, so customers and reviewers benefit from one compact record that connects the change-management decision to the evidence that supports it. + +This appendix provides: + +- a practical field set for model changes and drift events +- an example YAML record +- a JSON-equivalent structure +- review questions for customers and reviewers +- cross-references to the APTS requirements this artifact helps support + +## Primary Use Cases + +Consider using this record when documenting: + +- a foundation model provider change +- a model family or version update +- fine-tuning, adapter, system prompt, safety policy, or tool-use wiring changes that affect model-mediated decisions +- a fallback-provider or routing-policy change +- behavioral drift in an externally hosted model where the operator did not initiate a local code or configuration change +- rollback from a changed model configuration to a prior baseline + +## Design Principles + +A model change and drift record should: + +- identify the previous and proposed model configuration unambiguously +- separate routine model inventory updates from material changes requiring re-attestation +- connect behavioral comparisons to the safety-critical decision paths tested +- document drift detection results and affected decision paths +- capture human review before deployment when safety-critical behavior changes +- preserve rollback evidence and supersession relationships +- avoid exposing customer secrets, prompts, credentials, or restricted engagement data unnecessarily + +## Recommended Template Sections + +### 1. Record metadata + +Use stable identifiers so the record can be linked to change tickets, conformance claims, drift alerts, and customer notifications. + +Recommended fields: + +- `record_id` +- `change_ticket_id` +- `record_type` +- `status` +- `created_at` +- `last_updated_at` +- `owner` +- `reviewers` + +Suggested `record_type` values: + +- `planned_model_change` +- `emergency_model_change` +- `provider_side_drift` +- `rollback` +- `post_change_review` + +### 2. Model configuration + +Record both the prior and candidate model configurations. The exact version format may vary by provider, but the record should be specific enough for review and rollback. + +Recommended fields: + +- `provider` +- `model_family` +- `model_name` +- `model_version` +- `deployment_environment` +- `region_or_endpoint` +- `inference_route` +- `fallback_route` +- `system_policy_reference` +- `tool_policy_reference` +- `behavioral_fingerprint_reference` + +### 3. Change summary and materiality + +Explain what changed and whether the change is material under the operator's APTS-TP-022 policy. + +Recommended fields: + +- `change_type` +- `change_summary` +- `reason_for_change` +- `materiality_decision` +- `materiality_basis` +- `affected_domains` +- `requires_re_attestation` +- `customer_notification_required` + +Suggested `change_type` values: + +- `provider_change` +- `model_family_change` +- `model_version_update` +- `fine_tune_or_adapter_change` +- `system_prompt_or_policy_change` +- `tool_use_or_action_space_change` +- `fallback_provider_change` +- `routing_policy_change` +- `detected_drift_without_operator_change` + +### 4. Behavioral comparison + +Capture the comparison between the previous model behavior and the candidate or observed model behavior, especially on safety-critical decisions. + +Recommended fields: + +- `test_set_reference` +- `baseline_run_id` +- `candidate_run_id` +- `scope_decision_delta` +- `escalation_decision_delta` +- `impact_classification_delta` +- `manipulation_resistance_delta` +- `safety_control_delta` +- `summary_result` +- `evidence_references` + +### 5. Drift detection record + +Use this section when the operator detects model behavior changes that were not introduced by an operator-controlled deployment. + +Recommended fields: + +- `drift_alert_id` +- `detected_at` +- `detection_source` +- `baseline_reference` +- `observed_deviation` +- `affected_decision_paths` +- `tolerance_threshold` +- `threshold_exceeded` +- `operator_alerted_at` +- `blocked_or_limited_paths` +- `acknowledged_by` +- `acknowledged_at` + +### 6. Human review and re-attestation + +Document who reviewed the change, what evidence they inspected, and whether re-attestation or customer notification was completed. + +Recommended fields: + +- `review_required` +- `reviewer_name_or_role` +- `review_started_at` +- `review_completed_at` +- `review_decision` +- `review_notes` +- `re_attestation_scope` +- `conformance_claim_updated` +- `foundation_model_disclosure_updated` +- `customer_notification_status` + +Suggested `review_decision` values: + +- `approved_for_deployment` +- `approved_with_limits` +- `requires_more_testing` +- `rejected` +- `rollback_required` + +### 7. Rollback and supersession + +Preserve the operational path back to the prior model configuration and make superseded records traceable. + +Recommended fields: + +- `rollback_plan_reference` +- `rollback_test_run_id` +- `rollback_test_result` +- `previous_record_id` +- `supersedes_record_id` +- `superseded_by_record_id` +- `rollback_completed_at` + +### 8. Evidence checklist + +Attach or reference the artifacts customers and reviewers may request. + +Recommended evidence: + +- model registry entry +- pinned model configuration or lock file +- behavioral fingerprint +- baseline and candidate test run output +- drift alert or scheduled drift test output +- human review record +- re-attestation record, when applicable +- updated conformance claim, when applicable +- updated foundation model disclosure, when applicable +- customer notification artifact, when applicable +- rollback test evidence + +## Example YAML Template + +```yaml +record_id: mcdr-2026-0042 +change_ticket_id: change-2026-117 +record_type: planned_model_change +status: approved_for_deployment +created_at: 2026-05-01T09:00:00Z +last_updated_at: 2026-05-01T15:30:00Z +owner: platform-governance +reviewers: + - safety-reviewer-01 + - customer-assurance-01 + +previous_model: + provider: example-ai-provider + model_family: example-secure-model + model_name: example-secure-model-4 + model_version: 4.2.1 + deployment_environment: production + region_or_endpoint: us.example.provider + inference_route: primary-agent-route + fallback_route: fallback-agent-route-v1 + system_policy_reference: policy/sp-2026-03 + tool_policy_reference: tools/tp-2026-03 + behavioral_fingerprint_reference: bf-2026-03-15 + +candidate_model: + provider: example-ai-provider + model_family: example-secure-model + model_name: example-secure-model-4 + model_version: 4.3.0 + deployment_environment: production + region_or_endpoint: us.example.provider + inference_route: primary-agent-route + fallback_route: fallback-agent-route-v1 + system_policy_reference: policy/sp-2026-03 + tool_policy_reference: tools/tp-2026-03 + behavioral_fingerprint_reference: bf-2026-05-01 + +change_summary: + change_type: model_version_update + reason_for_change: provider security and reliability update + materiality_decision: not_material + materiality_basis: same provider and model family; no action-space or refusal-behavior delta observed on safety-critical tests + affected_domains: + - APTS-AR-019 + - APTS-TP-002 + requires_re_attestation: false + customer_notification_required: false + +behavioral_comparison: + test_set_reference: safety-critical-baseline-2026-04 + baseline_run_id: eval-run-2026-04-30-a + candidate_run_id: eval-run-2026-05-01-b + scope_decision_delta: none_observed + escalation_decision_delta: none_observed + impact_classification_delta: minor_non_material_wording_change + manipulation_resistance_delta: none_observed + safety_control_delta: none_observed + summary_result: passed + evidence_references: + - evidence/model-change/eval-run-2026-05-01-b.json + - evidence/model-change/reviewer-notes-2026-05-01.md + +drift_detection: + drift_alert_id: null + detected_at: null + detection_source: scheduled_pre_engagement_baseline + baseline_reference: bf-2026-03-15 + observed_deviation: no_threshold_exceedance + affected_decision_paths: [] + tolerance_threshold: no_safety_critical_decision_changes + threshold_exceeded: false + operator_alerted_at: null + blocked_or_limited_paths: [] + acknowledged_by: safety-reviewer-01 + acknowledged_at: 2026-05-01T14:20:00Z + +human_review: + review_required: true + reviewer_name_or_role: safety-reviewer-01 + review_started_at: 2026-05-01T14:00:00Z + review_completed_at: 2026-05-01T14:25:00Z + review_decision: approved_for_deployment + review_notes: Evaluation output showed no safety-critical decision changes beyond tolerance + re_attestation_scope: not_required + conformance_claim_updated: false + foundation_model_disclosure_updated: false + customer_notification_status: not_required + +rollback: + rollback_plan_reference: runbooks/model-rollback-v2.md + rollback_test_run_id: rollback-test-2026-05-01 + rollback_test_result: passed + previous_record_id: mcdr-2026-0038 + supersedes_record_id: mcdr-2026-0038 + superseded_by_record_id: null + rollback_completed_at: null +``` + +## JSON-Equivalent Structure + +```json +{ + "record_id": "mcdr-2026-0042", + "record_type": "planned_model_change", + "status": "approved_for_deployment", + "previous_model": { + "provider": "example-ai-provider", + "model_name": "example-secure-model-4", + "model_version": "4.2.1", + "behavioral_fingerprint_reference": "bf-2026-03-15" + }, + "candidate_model": { + "provider": "example-ai-provider", + "model_name": "example-secure-model-4", + "model_version": "4.3.0", + "behavioral_fingerprint_reference": "bf-2026-05-01" + }, + "change_summary": { + "change_type": "model_version_update", + "materiality_decision": "not_material", + "requires_re_attestation": false + }, + "behavioral_comparison": { + "test_set_reference": "safety-critical-baseline-2026-04", + "summary_result": "passed" + }, + "human_review": { + "review_required": true, + "review_decision": "approved_for_deployment" + } +} +``` + +## Field Mapping to APTS Requirements + +| Record area | Primary requirements | +| --- | --- | +| Pinned model identity and rollback data | `APTS-TP-002` | +| Behavioral fingerprint and comparison results | `APTS-AR-019`, `APTS-AR-017` | +| Provider-side drift detection and blocking decisions | `APTS-AR-019` | +| Foundation model disclosure updates | `APTS-TP-021`, `APTS-TP-022` | +| Re-attestation scope and customer notification | `APTS-TP-022`, `APTS-AR-018` | +| Human review of safety-critical behavior changes | `APTS-AR-019`, `APTS-MR-020` | + +## Validation Guidance for Customers and Reviewers + +When reviewing a model change and drift record, consider asking: + +1. Does the record identify the previous and candidate model configuration specifically enough to reproduce or roll back the deployment? +2. Does the behavioral comparison cover scope validation, escalation triggers, finding classification, and manipulation-resistance paths? +3. If the change was marked not material, does the materiality basis map to the operator's APTS-TP-022 policy? +4. If drift was detected, were affected decision paths blocked or limited until review and acknowledgement? +5. Do evidence references point to actual baseline runs, candidate runs, drift alerts, and review notes? +6. If re-attestation was required, were the conformance claim and foundation model disclosure updated before customer engagements used the changed configuration? +7. Is the rollback path tested and linked to a prior model configuration? + +## Usage Notes + +This template is intentionally illustrative. Operators may keep equivalent records in change-management systems, model registries, ticketing systems, or governance platforms as long as the evidence is complete, reviewable, and available to customers when required by APTS.