Business Continuity Plan

1. Document Control

2. Purpose and Scope

This Business Continuity Plan establishes the policies, procedures, and recovery objectives for Tenable Nova LLC ("TeNova"), the organization responsible for the SWT3 Witness protocol and the Axiom Sovereign Engine platform.

2.1 Scope

This plan covers the following components:

• SWT3 Protocol Specification: The publicly versioned protocol document (SWT3-SPEC) that defines the witness anchor format, fingerprint formula, clearing levels, and cross-language test vectors.
• SDK Ecosystem: Open-source SDKs published across 11 independent package registries (npm, PyPI, crates.io, NuGet, RubyGems, Swift Package Index, and others) in 10 programming languages.
• Witness Ledger: The managed database storing SHA-256 witness anchors, verdict metadata, and daily Merkle rollups for customer tenants.
• Dashboard Platform: The web-based compliance dashboard hosted at sovereign.tenova.io, providing evidence management, reporting, and export capabilities.

2.2 Exclusions

This plan does not cover customer-side implementations of the SWT3 protocol. Organizations that self-host SWT3 SDKs are responsible for their own continuity planning. The protocol specification provides all information necessary for independent implementation.

3. Key Person Risk

TeNova acknowledges the key person risk inherent in an early-stage technology company. This section addresses the concern directly and describes the structural mitigations that reduce this risk to an acceptable level for customers and partners.

3.1 Current Team Structure

TeNova is currently a small, focused team. The founder serves as primary engineer, protocol designer, and business operator. This concentration of knowledge is a recognized risk, and the mitigations below are designed to ensure that no single point of failure can compromise customer data integrity or protocol continuity.

3.2 Structural Mitigations

3.3 Risk Assessment

In the event that TeNova ceases operations:

• Existing witness anchors remain valid. SHA-256 hashes do not expire and require no online verification service.
• Published SDKs remain available on independent registries indefinitely.
• The protocol specification enables any qualified engineering team to build a compatible implementation.
• Customer data can be exported in full prior to any service discontinuation, with a minimum 90-day notice period committed in service agreements.

4. Recovery Time Objectives

Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) are defined per component based on criticality and architectural independence.

5. Data Classification

5.1 What the Witness Ledger Stores

The SWT3 witness ledger stores cryptographic evidence metadata. It does not store source data. Specifically:

• Stored: SHA-256 fingerprints, verdict outcomes (PASS/FAIL), procedure identifiers, timestamps, tenant identifiers, and factor metadata (numeric values describing the evidence context).
• Never stored: Source code, model weights, training data, prompts, completions, personally identifiable information (PII), protected health information (PHI), or raw compliance evidence.

This design is intentional. The witness protocol records the fact that an event occurred and its compliance outcome, not the content of the event itself.

5.2 Clearing Levels

The SWT3 protocol defines four clearing levels that provide data classification at the protocol layer:

5.3 Tenant Isolation

All customer data is isolated at the database level using tenant-scoped queries with row-level security. No tenant can access another tenant's witness anchors, verdicts, or configuration. Administrative operations that cross tenant boundaries require explicit privileged access and are logged in the audit trail.

6. Backup Strategy

6.1 Infrastructure Backups

6.2 Tamper Evidence

Daily Merkle rollups compute a single cryptographic root hash over all witness anchors created within each 24-hour period, per tenant. These rollups are timestamped using RFC 3161 timestamp authorities (independent third parties) and stored alongside the ledger data.

This mechanism provides the following guarantees:

• Any modification to a historical witness anchor would invalidate the Merkle root for that day, producing detectable evidence of tampering.
• RFC 3161 timestamps prove the rollup existed at a specific point in time, independent of TeNova systems.
• Merkle proofs can be verified using standard SHA-256 libraries with no dependency on TeNova software.

6.3 Source of Truth Hierarchy

1. Git repository is the authoritative source for application code, protocol specification, and configuration.
2. Managed database is the authoritative source for customer witness data and tenant configuration.
3. Package registries are the authoritative distribution channel for SDK artifacts.
4. RFC 3161 timestamps provide independent proof of existence for daily Merkle rollups.

7. Incident Response

7.1 Severity Levels

7.2 Communication Channels

• Incident notification: Affected customers are notified via email to their registered contact address.
• Status updates: Updates are provided at a minimum of every 2 hours during P1 incidents and every 4 hours during P2 incidents.
• Engineering contact: engineering@tenovaai.com
• Support contact: support@tenovaai.com

7.3 Post-Incident Review

A post-incident review is conducted within 72 hours of resolution for all P1 and P2 incidents. The review covers:

• Root cause analysis
• Timeline of detection, response, and resolution
• Customer impact assessment
• Corrective actions and preventive measures
• Updates to this BCP if the incident exposed a gap

Post-incident review summaries are shared with affected customers upon request.

8. Succession Plan

The succession plan addresses the scenario in which key personnel are unavailable for an extended period or the organization ceases operations.

8.1 Protocol Continuity

• The SWT3-SPEC (currently v2.0.0) is publicly available and contains the complete protocol definition, including anchor format, fingerprint formula, clearing level rules, and verification procedures.
• Published test vectors (13 fingerprint, 2 signing, 5 hash) enable any engineering team to verify their implementation produces correct outputs without access to TeNova source code or personnel.
• Cross-language parity has been verified across all 10 SDK implementations. This verification is reproducible by any third party using the published test vector suite.

8.2 Customer Data Continuity

• All customer witness data can be exported via the dashboard or API at any time in standard JSON format.
• Merkle proof chains remain cryptographically valid regardless of platform availability. Any standard SHA-256 implementation can verify a Merkle proof exported from the platform.
• RFC 3161 timestamps on daily rollups provide court-admissible proof of existence that does not depend on TeNova as a witness.

8.3 Code and Artifact Preservation

• SDK source code is hosted on public GitHub under the tenova-labs organization. GitHub's terms of service preserve public repositories even if the owning organization becomes inactive.
• Published packages on npm, PyPI, crates.io, NuGet, and RubyGems are immutable once published. These registries are operated by independent organizations (npm Inc., Python Software Foundation, Mozilla, Microsoft, RubyGems.org) and are not affected by TeNova's operational status.
• The protocol specification is versioned in Git. Any fork of the repository contains the complete specification and its revision history.

8.4 Planned Growth

As TeNova grows, this plan will be updated to reflect:

• Additional engineering team members with documented runbook access
• Formal escrow arrangements for enterprise and sovereign-tier customers
• Designated succession contacts with legal authority to manage customer transitions
• Multi-region infrastructure redundancy

9. Contact and Escalation

10. Revision History