Deployment Evidence

Deployment Evidence is the workspace foundation for evidence-backed deployment readiness. It helps teams describe a cloud cell, on-prem installation, hybrid boundary, or customer-managed deployment, then attach sanitized references to source-owned evidence.

Use it when you need one place to show deployment posture, data-flow posture, HA/DR evidence, secure-delivery evidence, exceptions, and evidence packs without turning those statements into hardcoded product claims.

What Deployment Evidence Owns

Deployment evidence profiles for cloud, on-prem, hybrid, dedicated, or customer-managed boundaries.
Data-flow entries that reference source-owned evidence for integrations, backup/restore, key custody, storage custody, security logging, support boundaries, and secure delivery.
Exceptions for evidence gaps, policy blocks, temporary approvals, and deployment-dependent posture.
Evidence packs that collect sanitized references for buyer, audit, or readiness review.

Deployment Evidence stores profile metadata, capability states, safe source refs, and sanitized snapshots. It does not store raw provider payloads, scanner findings, vectors, prompts, document text, storage keys, credentials, or confidential source content.

Evidence packs are generated from the Deployment Evidence profile, data-flow entries, and exceptions already recorded in the workspace. The generated pack stores source-owner refs, statuses, capability states, dates, source descriptor refs, and aggregate counts. Optional operator JSON submitted during pack generation is validated for unsafe keys and recorded only as supplement key names; its values are not copied into the generated pack as evidence.

User Journey

Open Governance > Deployment Evidence.
Create a deployment profile for the environment being reviewed.
Review source-owner descriptors to see which existing Novantra modules own each evidence type.
Record data-flow entries that point to source-owned evidence.
Record exceptions when evidence is evidence-required, policy-blocked, deployment-dependent, or temporarily approved.
Generate an evidence pack for review or audit-package use.

Source Owners

Deployment Evidence references other modules instead of replacing them:

Key Management owns key custody, BYOK posture, recovery, and break-glass evidence.
Storage owners own storage binding, validation, health, and migration posture.
Enterprise Connectors own connector credentials, jobs, source refs, handoffs, and health.
SIEM Exports owns log source selection, delivery attempts, integrity snapshots, and destination health.
Resilience owns BIAs, continuity plans, recovery strategies, exercises, and restore tests.
Incident Management owns incidents, impact assessments, response cases, and post-incident reviews.
Secure Development owns threat models, reviews, and security test gates.
Audit Packages, Work Management, Activity, and Compliance Posture consume Deployment Evidence through descriptors and subscribers.

Capability States

Capability states should be literal. Use configured only when the evidence supports it. Use deployment-dependent when the answer depends on the specific cloud cell, on-prem installation, customer environment, or provider setup. Use evidence-required, reference-only, provider-not-configured, policy-blocked, fallback-only, no-AI profile, roadmap, or exception-approved when those are the accurate states.

Do not use Deployment Evidence to claim certified residency, fixed SLA, legal validity, successful penetration testing, confidential vector search, public API availability, or guaranteed AI accuracy unless another implemented and evidenced capability supports that exact statement.

Cloud And On-Prem

Cloud and on-prem deployments expose the same Deployment Evidence behavior. The difference is the source evidence: cloud profiles can refer to cloud cell and provider/operator evidence, while on-prem profiles can refer to customer-controlled installation boundaries. The product surface remains the same.