CER Record Management

CER bundles are immutable protocol artifacts. Record management defines how organizations store, surface, and govern CER records over time.

This page defines management-layer behavior only. It does not modify the CER protocol schema, certificateHash computation, or verification semantics.

CER Lifecycle Model

This section defines the operational lifecycle of a Certified Execution Record as a managed record inside the NexArt system.

Lifecycle states describe how records are managed, stored, or presented. They do not describe how the CER bundle itself behaves cryptographically.

CER bundles are immutable protocol artifacts. Lifecycle states apply to record management systems such as dashboards, storage layers, and audit workflows.

Lifecycle States

Active

The CER is stored and available for normal operations. It can be resolved by execution ID or certificate hash and may appear in dashboard queries and exports.

Exported

Exported indicates that a CER has been included in one or more evidence exports. Export does not modify the CER or change its verification status. Exported is an event marker, not a storage state. A CER may be exported while remaining Active, Archived, or in any other lifecycle state.

Archived

The CER has been moved to long-term storage for retention purposes. Archived records remain cryptographically verifiable and may still be resolved through the verification system. Archived records may be excluded from normal dashboard queries but remain accessible through audit workflows.

Hidden

The CER remains stored and verifiable but is no longer publicly resolvable through public endpoints. Hidden records remain accessible to authorized organizational users and retain full verification capability.

Deleted (storage-level deletion)

The stored bundle may be removed from the NexArt storage layer according to retention policies. However, deletion does not invalidate the underlying cryptographic provenance of the CER. Any previously exported bundles or receipts remain independently verifiable.

Lifecycle Transitions

Lifecycle states may transition through operational actions:

• Active → Archived
• Active → Hidden
• Archived → Active (restore)
• Active → Deleted (storage-level removal)

Transitions affect storage and visibility behavior, not the CER bundle contents.

Audit Visibility

Lifecycle states influence how records appear in operational interfaces but must not alter their verification integrity.

Verification tools must evaluate CER bundles independently of lifecycle state. Audit workflows must preserve historical visibility of lifecycle actions.

Interaction with Protocol Immutability

Lifecycle management never modifies the CER bundle, certificateHash, or attestation receipt. All lifecycle operations occur at the record management layer and do not affect the cryptographic validity of the record.

Record Action Semantics

This section defines the management actions that may apply to stored CER records.

These actions operate at the storage, visibility, and governance layer. They do not modify the CER bundle, certificateHash, or signed receipt.

Hide

A hidden record remains stored and cryptographically verifiable but is no longer publicly resolvable through public verification endpoints. Hidden records remain accessible to authorized organizational users and retain full verification capability.

Delete (storage-level deletion)

Deletion removes the stored bundle from the NexArt-managed storage layer according to retention or governance rules. Deletion does not invalidate the underlying cryptographic provenance of the record. Previously exported bundles, receipts, and verification artifacts remain independently verifiable.

Deletion is a governance-sensitive action. Organizations may restrict deletion to authorized governance review processes rather than exposing it as a normal self-service operation.

Revoke

Revocation does not alter or delete the original CER. Instead, revocation is a governance action indicating that the original record should no longer be treated as operationally valid for current workflows. A revocation must preserve the historical audit trace of the original CER.

Revocation is a governance-sensitive action. Organizations may choose not to expose revocation as a direct user-facing action, instead handling it through governance review workflows.

Export

Export creates an external evidence package or bundle copy for audit or archival use. Export does not modify the CER or change its verification status.

Revocation Semantics

Revocation must not mutate the original CER. The original record remains historically valid as evidence of what was certified at the time.

Revocation affects operational reliance, not historical existence or cryptographic validity. A revoked CER still proves that a specific execution was certified. It simply indicates that the record should no longer be relied upon for current operational purposes.

Future protocol revisions may represent revocation as a separate linked artifact. This documentation defines revocation semantics without extending the current schema.

Deletion Semantics

Deletion refers only to removal from managed storage layers. Deletion does not erase:

• Prior exports
• Independently held CER bundles
• Signed receipts
• Historical evidence that a record once existed

Deletion therefore affects availability, not cryptographic history.

Public Visibility Semantics

A hidden record may no longer resolve through public verification URLs or public certificate-hash lookup. However, hiding does not change the CER itself, its certificateHash, or its signed receipt.

Organizationally authorized users may still access hidden records through internal control surfaces, subject to permissions and policy.

Audit Trace Preservation

All hide, revoke, delete, and export actions must preserve an audit trail at the management layer.

Management actions must remain visible to authorized audit workflows even when the underlying record is hidden or removed from primary storage. Historical accountability is preserved even when operational visibility changes.

Interaction with Lifecycle Model

Record actions interact with lifecycle states defined in the CER Lifecycle Model. Hide may move a record into the Hidden state. Delete may move a record into Deleted (storage-level deletion). Export may record an Exported lifecycle event. Revoke may affect operational validity without mutating the CER or its lifecycle state.

Archival Behavior Model

This section defines what it means for a Certified Execution Record to be archived inside the NexArt system.

Archival is a record-management behavior, not a change to the CER bundle itself. Archiving must not modify the CER, certificateHash, attestation receipt, or verification semantics.

Storage Behavior

An archived CER is moved from active operational storage into long-term managed storage.

Archived records may be excluded from normal dashboard lists, high-frequency operational queries, or default application views.

However, archival must preserve the ability to retrieve the record for audit, restore, or verification purposes according to organizational policy.

Public Resolvability

Archival does not automatically remove a record from public verification surfaces unless separate visibility rules (such as Hidden) apply.

An archived record may remain publicly resolvable by execution ID or certificate hash if public visibility is still allowed by policy.

If a record is both archived and hidden, public resolution may be disabled while internal audit access remains preserved.

Verification Persistence

Archived records remain cryptographically verifiable. Archival does not affect:

• certificateHash validity
• Signed receipt validity
• Independent verification of previously exported bundles
• Verifier interpretation of the record

Verification depends on the CER artifact and receipt, not on whether the record is active or archived.

Searchable Metadata

Archived records may be excluded from default operational search results.

However, core metadata may remain searchable for authorized users, such as:

• executionId
• certificateHash
• bundleType
• createdAt
• Project and app identifiers where applicable

This allows organizations to locate archived records without restoring them to active state.

Restore Behavior

Archived records may be restored to the Active state through management-layer actions.

Restoration affects storage and operational visibility only. It does not modify the CER bundle, certificateHash, or signed receipt.

Archived → Active is a lifecycle management transition, not a new certification event.

Interaction with Protocol Immutability

Archival never mutates the CER bundle or its cryptographic evidence. The same CER must remain verifiable before, during, and after archival.

Archival changes how the record is stored and surfaced, not what the record is.

Relationship to Lifecycle and Actions

Archival is one lifecycle state within the CER Lifecycle Model. It is distinct from Hide (which affects public resolvability) and Delete (which removes the stored bundle). Archival preserves audit trace and verification continuity as defined in the Record Action Semantics.

Retention Policy Model

Retention policies define how long CER records remain stored and accessible inside NexArt-managed systems.

Retention policies affect storage behavior but never modify CER artifacts, certificateHash, or verification semantics.

Retention Classes

Organizations may define retention classes to categorize how long records are kept:

Short-term

Used for temporary operational logs or transient execution records that do not require long-term preservation.

Standard

The default retention period for most CER records. Suitable for general operational use.

Long-term

Used for regulated workflows or compliance-sensitive systems where extended retention is required.

Permanent

Records intended to remain stored indefinitely. Suitable for critical audit evidence or records subject to permanent regulatory requirements.

Retention class definitions may vary by organization. The classes listed here are examples. Organizations may define custom classes aligned with their governance requirements.

Policy Scope

Retention policies may apply at multiple levels:

• Organization: default retention for all records
• Project: override for a specific project
• Application: override for a specific app within a project
• Execution surface: override based on bundle type (e.g. AI execution vs. Code Mode)

Lower-level scopes may override higher-level defaults. For example, an organization default of 5 years may be overridden by a project-level policy of 1 year.

Expiry Behavior

When a retention period expires, the system may take one or more of the following actions:

• Archive the record
• Delete the stored bundle
• Require manual review before deletion
• Trigger an export before deletion

Retention expiry must not invalidate cryptographic evidence. Previously exported bundles and signed receipts remain independently verifiable regardless of whether the stored record has been removed.

Legal Hold and Audit Hold

Retention policies must support suspension of scheduled deletion when records are subject to:

• Legal investigation
• Regulatory review
• Internal audit

When a record is under hold, deletion must be blocked. Archival may still occur during a hold period, but storage-level removal must be prevented until the hold is released.

Interaction with Lifecycle States

Retention policies influence lifecycle transitions such as:

• Active → Archived (when a retention period triggers archival)
• Archived → Deleted (when a retention period expires for archived records)

Retention policies never mutate the CER bundle, certificateHash, or attestation receipt. They govern when lifecycle transitions occur, not what happens to the CER artifact itself.

Interaction with Record Actions

Retention policies interact with record actions including hide, delete, archive, and export. For example, a policy may trigger an automatic export before a scheduled deletion.

However, retention rules must not remove historical audit traces. All retention-driven actions must be logged and remain visible to authorized audit workflows.

Evidence and Auditability Guarantees

Certified Execution Records are designed to function as durable execution evidence.

A CER captures a verifiable record of a computation or AI execution and binds it to a deterministic certificate hash. When node attestation is present, the record also includes a signed receipt proving that the record existed at a specific point in time.

Evidence Guarantees

Immutability

CER bundles and certificate hashes cannot be modified after creation without invalidating verification. Any alteration to the bundle will produce a different hash, making tampering detectable.

Independent Verification

Verification does not require access to NexArt infrastructure. Anyone with the CER bundle and the node's public keys can verify the record independently.

Historical Verifiability

Records remain verifiable even if they are archived, hidden, or deleted from NexArt-managed storage. Verification depends on the CER artifact and receipt, not on storage state.

Audit Trace Preservation

Management-layer actions (archive, hide, revoke, delete, export) must preserve an audit trail visible to authorized workflows. No management action may silently remove evidence of prior record state.

Protocol Stability

Verification semantics are versioned and must remain compatible with earlier protocol versions. Records certified under an earlier version must remain verifiable under future verification implementations.

Scope of Evidence

CERs provide cryptographic evidence of execution records and attestations.

They do not prove that an execution result was correct, desirable, or appropriate. They prove that a specific execution artifact existed and can be verified against its certificate hash and, when present, its attestation receipt.

This distinction is important for audit clarity. A CER demonstrates what was executed and certified, not whether the outcome was good.

Operational and Sensitive Actions

Record-management actions in NexArt do not all have the same governance significance. Some actions affect normal storage and operational workflows. Other actions affect visibility, trust posture, or governance and therefore require stronger controls.

This classification operates only at the management layer. It does not modify the CER bundle, certificateHash, or signed receipt.

Operational Actions

Operational actions are normal management actions that organize, store, or surface CER records without changing their trust meaning.

Examples of operational actions include:

• Export
• Archive
• Restore from archive
• Ordinary record lookup
• Ordinary internal search
• Retention-driven archival

These actions may affect where or how a record is surfaced, but they do not alter public trust semantics or cryptographic validity.

Sensitive Actions

Sensitive actions are management actions that affect public visibility, operational trust, long-term availability, or governance posture.

Examples of sensitive actions include:

• Hide from public resolution
• Delete stored bundle
• Revoke operational validity
• Override standard retention behavior
• Apply or release legal/audit hold

These actions require stronger governance controls because they affect how records are relied upon, discovered, or preserved.

Some organizations may choose not to expose revocation or deletion as direct user-facing actions. In such cases, these actions are handled through governance review workflows rather than normal self-service UI controls.

This section defines the classification only. It does not introduce formal permissions, roles, or approval workflows.

Why the Distinction Matters

Separating operational actions from sensitive actions helps organizations apply stronger controls where record visibility, trust posture, or long-term evidence preservation may be affected.

This distinction also supports future work on:

• Permissions
• Approval workflows
• Audit review processes
• Enterprise governance controls

Interaction with Lifecycle and Retention

Operational and sensitive actions interact with lifecycle states and retention policies:

• Archive: generally operational
• Delete: sensitive
• Hide: sensitive
• Export: operational
• Retention expiry: may trigger operational or sensitive actions depending on policy

The classification helps determine how actions should later be controlled, reviewed, and audited.

Interaction with Protocol Immutability

Neither operational nor sensitive actions mutate the CER bundle or its cryptographic evidence.

The distinction concerns governance significance, not protocol behavior. The CER bundle, certificateHash, and signed receipt remain immutable regardless of how an action is classified.

Roles and Permissions Model

Organizations using NexArt may need to control who can view, manage, export, or modify the operational state of CER records.

Roles and permissions apply only to management-layer operations such as lifecycle transitions, export actions, and governance controls. Access control does not modify the CER artifact itself. Verification and cryptographic integrity remain independent of access permissions.

Common Role Categories

The following role categories represent typical organizational governance structures for CER management. Organizations may implement custom roles aligned with their own requirements.

Viewer

Read-only access to CER records and verification results. Viewers can browse record metadata and view verification outcomes but cannot modify records or trigger management actions.

Operator

Operational access for day-to-day record management tasks. Operators can perform routine lifecycle actions such as archiving, restoring, and exporting records.

Auditor

Read and export access intended for compliance and review workflows. Auditors can view records and generate evidence packs but cannot modify lifecycle state or governance controls.

Administrator

Full management access including lifecycle transitions, policy configuration, and governance controls such as hide, revoke, and delete, subject to policy constraints.

Permission Categories

The following categories define the main types of actions that may require permission controls. These permissions apply only to record management behavior.

Read Permissions

View CER metadata, verification results, and record details.

Export Permissions

Generate evidence packs or export verification artifacts.

Lifecycle Permissions

Archive, restore, or hide records.

Sensitive Permissions

Delete records, revoke operational validity, or change retention behavior. These permissions may not be exposed through standard self-service interfaces. Organizations may require governance review processes before these actions can be executed.

Policy Permissions

Modify retention policies or apply legal/audit holds.

Example Permission Matrix

The following table illustrates how roles may map to permission categories. This is an example governance model. Organizations may customize their permission structure.

Interaction with Lifecycle and Retention

Permissions determine who can trigger lifecycle transitions such as:

• Active → Archived
• Active → Hidden
• Archived → Active (restore)
• Archived → Deleted

Policy permissions may also control who can:

• Define retention classes
• Apply retention overrides
• Place records under legal or audit hold

Interaction with Audit Workflows

Auditors may require controlled export permissions to generate evidence packs. Export permissions should allow authorized users to create:

• CER evidence packs
• Verification snapshots
• Export manifests

Audit workflows must not require modification of CER bundles or attestation artifacts.

Interaction with Protocol Immutability

Access control and permissions never modify the CER bundle or its cryptographic evidence.

Permissions govern operational access and management actions only. CER bundles, certificateHash values, signed receipts, and verification rules remain independent of organizational access control.

Policy Control Layer

Organizations may require formal governance rules for how CER records are stored, surfaced, retained, exported, and controlled over time.

The policy control layer provides a way to define those rules without modifying the CER protocol itself. Policies apply only to management-layer behavior such as lifecycle transitions, archival, export, retention, visibility, and record actions.

Policies do not alter the CER artifact, certificateHash, signed receipt, or verification semantics.

Policy Categories

Organizations may apply policies across the following governance categories:

Retention Policies

Control how long records remain stored and when they transition to archival or deletion. Retention policies interact with the Retention Policy Model defined earlier on this page.

Visibility Policies

Control whether records are publicly resolvable, hidden from external access, or restricted to internal organizational users. Visibility policies may set default visibility for new records or enforce hiding based on record class.

Export Policies

Control when evidence packs should be generated, what export scope is allowed, and whether exports are required before archival or deletion. Export policies support audit readiness by ensuring evidence is preserved before lifecycle transitions.

Action Policies

Control whether specific management actions (such as delete, hide, revoke, or restore) are allowed under normal operation. Action policies may block or constrain actions that would otherwise be permitted by role-based permissions. Organizations may use action policies to ensure that revocation and deletion are only available through governance-controlled workflows rather than as routine self-service operations.

Audit Policies

Control requirements for audit trace preservation, export logging, and evidence retention. Audit policies help organizations maintain accountability and traceability across record management operations.

Sensitive Action Policies

Define additional controls around actions classified as governance-sensitive. These policies may require additional review, approval, or documentation before sensitive actions are executed.

Policy Scope

Policies may apply at multiple organizational scopes:

• Organization-wide: default governance rules for all records
• Project: override for a specific project
• Application: override for a specific app within a project
• Execution surface: override based on bundle type
• Record class or workflow type: override based on record classification

Lower-level scopes may override higher-level defaults, consistent with the retention policy scope model.

For example:

• Organization default: archive after 90 days
• Project override: retain active for 1 year

Example Policy Expressions

Policies may be represented in implementation-specific ways. The governance model typically includes:

• Policy name
• Scope
• Trigger condition
• Resulting action
• Exceptions or overrides

This section does not introduce a formal policy schema. These are conceptual examples of how governance rules may be expressed.

Example 1

Archive all AI execution CERs after 90 days and retain them for 5 years.

Example 2

Require evidence export before deleting records classified as long-term or permanent.

Interaction with Lifecycle and Record Actions

Policies may trigger lifecycle transitions such as:

• Active → Archived
• Archived → Deleted

Policies may also constrain or require management actions such as:

• Export before deletion
• Hide by default
• Prevent deletion when legal hold exists
• Prevent revoke except by authorized governance workflows

Policies govern how actions are applied, not what the CER artifact is.

Interaction with Roles and Permissions

Policies and permissions are related but not identical:

• Permissions define who is allowed to attempt an action.
• Policies define whether the action is allowed or required under governance rules.

For example, an administrator may have permission to delete a record, but policy may still require export and hold checks before deletion is allowed.

This distinction is important for enterprise governance where role-based access alone is not sufficient to enforce organizational rules.

Interaction with Audit Workflows

Policies may require that certain records:

• Remain exportable
• Preserve audit trace
• Trigger evidence pack creation
• Remain retained for a specified period

Audit workflows must continue to operate within policy constraints while preserving independent verification. Policies support audit readiness but do not override the ability to verify CER artifacts independently.

Interaction with Protocol Immutability

Policies do not mutate the CER bundle, certificateHash, signed receipt, or verification result semantics.

Policy controls only govern management-layer operations applied to stored records. The CER protocol remains stable and independently verifiable regardless of policy configuration.