@fulmenhq/tsfulmen 0.2.0 → 0.2.2

package/schemas/crucible-ts/upstream/3leaps/crucible/docs/catalog/classifiers/README.md

@@ -0,0 +1,29 @@
+# Classifiers Catalog
+
+**Canonical URL**: `https://crucible.3leaps.dev/catalog/classifiers`
+
+Index of Crucible classifier dimensions and their canonical sources.
+
+## How To Use This Catalog
+
+- Use the narrative standards to decide what a value means.
+- Use the dimension definition JSON for machine validation, UI dropdowns, and automation.
+- Vendor `config/classifiers/` alongside `schemas/classifiers/` when you need offline or pinned behavior.
+
+Missing classification is a policy error. Use explicit `unknown` until classification is complete.
+
+## Dimensions
+
+| Dimension                   | Key                   | Standard                                               | Definition                                                         |
+| --------------------------- | --------------------- | ------------------------------------------------------ | ------------------------------------------------------------------ |
+| Data Sensitivity            | `sensitivity`         | `docs/standards/data-sensitivity-classification.md`    | `config/classifiers/dimensions/sensitivity.dimension.json`         |
+| Volatility & Update Cadence | `volatility`          | `docs/standards/volatility-classification.md`          | `config/classifiers/dimensions/volatility.dimension.json`          |
+| Access Tier                 | `access-tier`         | `docs/standards/access-tier-classification.md`         | `config/classifiers/dimensions/access-tier.dimension.json`         |
+| Retention & Lifecycle       | `retention-lifecycle` | `docs/standards/retention-lifecycle-classification.md` | `config/classifiers/dimensions/retention-lifecycle.dimension.json` |
+| Schema Stability            | `schema-stability`    | `docs/standards/schema-stability-classification.md`    | `config/classifiers/dimensions/schema-stability.dimension.json`    |
+| Volume Tier                 | `volume-tier`         | `docs/standards/volume-tier-classification.md`         | `config/classifiers/dimensions/volume-tier.dimension.json`         |
+| Velocity Mode               | `velocity-mode`       | `docs/standards/velocity-mode-classification.md`       | `config/classifiers/dimensions/velocity-mode.dimension.json`       |
+
+## Framework Overview
+
+See `docs/standards/classifiers-framework.md` for how the pieces fit together.

package/schemas/crucible-ts/upstream/3leaps/crucible/docs/standards/access-tier-classification.md

@@ -0,0 +1,163 @@
+---
+title: "Access Tier Classification"
+description: "Distribution and access control classification standard"
+category: "standards"
+status: "stable"
+version: "1.0.0"
+lastUpdated: "2026-01-22"
+maintainer: "3leaps-core"
+reviewers: ["security", "compliance"]
+approvers: ["3leapsdave"]
+tags: ["classification", "access-control", "distribution", "acl"]
+content_license: "CC0"
+relatedDocs:
+  - "docs/standards/data-sensitivity-classification.md"
+  - "config/classifiers/dimensions/access-tier.dimension.json"
+audience: "all"
+---
+
+# Access Tier Classification
+
+This standard defines access tier levels for distribution and access control across all 3leaps ecosystems. Access tier is often derived from sensitivity but can be overridden to further restrict distribution.
+
+## Relationship to Sensitivity
+
+Access tier complements sensitivity classification:
+
+- **Sensitivity** determines _what the data is_ (how sensitive)
+- **Access tier** determines _who can access it_ (distribution scope)
+
+Common pattern: Access tier ≥ Sensitivity level (you can restrict further but not loosen)
+
+| Sensitivity Level     | Minimum Access Tier |
+| --------------------- | ------------------- |
+| 0-Public              | public              |
+| 1-Confidential        | internal            |
+| 2-Blinded             | internal            |
+| 3-Proprietary         | restricted          |
+| 4-Personal/Secret     | privileged          |
+| 5-Privileged/Sysadmin | privileged          |
+| 6-Eyes Only           | eyes-only           |
+
+---
+
+## Access Tiers
+
+### Unknown
+
+**Access tier not yet classified; must be classified before sharing or distribution.**
+
+| Aspect           | Requirement                                |
+| ---------------- | ------------------------------------------ |
+| **Access**       | Restricted to classification pipeline only |
+| **Distribution** | Prohibited until classified                |
+| **Audit**        | All access logged                          |
+| **Use Cases**    | Newly uploaded content, unreviewed imports |
+
+**Operational Notes**: Gate all sharing and distribution operations on explicit classification. Systems should reject requests to share `unknown` tier content.
+
+---
+
+### Public
+
+**Unrestricted access; suitable for public distribution.**
+
+| Aspect           | Requirement                             |
+| ---------------- | --------------------------------------- |
+| **Access**       | No authentication required              |
+| **Distribution** | CDN, public repos, external APIs        |
+| **Audit**        | Optional                                |
+| **Use Cases**    | Open source, public docs, public status |
+
+---
+
+### Internal
+
+**Organization-wide access; authentication required.**
+
+| Aspect           | Requirement                             |
+| ---------------- | --------------------------------------- |
+| **Access**       | Authenticated org members               |
+| **Distribution** | Internal repos, intranet, VPN-protected |
+| **Audit**        | Access logging recommended              |
+| **Use Cases**    | Internal docs, runbooks, dev resources  |
+
+---
+
+### Restricted
+
+**Team or project-level access; explicit authorization required.**
+
+| Aspect           | Requirement                                |
+| ---------------- | ------------------------------------------ |
+| **Access**       | Explicitly authorized team members         |
+| **Distribution** | Access-controlled repos, gated APIs        |
+| **Audit**        | Access logging required                    |
+| **Use Cases**    | Project roadmaps, team configs, pilot data |
+
+---
+
+### Privileged
+
+**Named individuals only; documented business need.**
+
+| Aspect           | Requirement                                    |
+| ---------------- | ---------------------------------------------- |
+| **Access**       | Named individuals with documented need         |
+| **Distribution** | Direct share only, no group access             |
+| **Audit**        | Comprehensive logging, periodic review         |
+| **Use Cases**    | Security findings, exec comms, sensitive plans |
+
+---
+
+### Eyes Only
+
+**Executive/legal authorization required; immutable audit trail.**
+
+| Aspect           | Requirement                                           |
+| ---------------- | ----------------------------------------------------- |
+| **Access**       | Executive or legal authorization                      |
+| **Distribution** | Controlled handoff with chain of custody              |
+| **Audit**        | Immutable audit trail, legal compliance               |
+| **Use Cases**    | Legal discovery, breach evidence, regulatory response |
+
+---
+
+## Decision Guide
+
+```
+Who needs access to this?
+
+├── Anyone (public internet) → public
+├── Anyone in the organization → internal
+├── Specific teams/projects → restricted
+├── Named individuals with documented need → privileged
+└── Executive/legal approval required → eyes-only
+```
+
+---
+
+## Handling Matrix
+
+| Access Tier    | Storage              | Sharing           | Audit Level   | Review Cycle |
+| -------------- | -------------------- | ----------------- | ------------- | ------------ |
+| **public**     | Any                  | Unrestricted      | Optional      | None         |
+| **internal**   | Private repos        | Org-wide          | Recommended   | Annual       |
+| **restricted** | Access-controlled    | Explicit grants   | Required      | Quarterly    |
+| **privileged** | Isolated             | Named individuals | Comprehensive | Monthly      |
+| **eyes-only**  | Legal-grade controls | Executive handoff | Immutable     | Per-access   |
+
+---
+
+## Machine-Readable Definition
+
+- **Dimension Config**: `config/classifiers/dimensions/access-tier.dimension.json`
+- **Schema**: `schemas/classifiers/v0/dimension-definition.schema.json`
+
+---
+
+## Attribution
+
+This standard is the canonical reference for access tier classification across 3leaps ecosystems. Downstream consumers should reference or vendor this standard rather than maintaining independent copies.
+
+**Review Cycle**: Quarterly with security and compliance teams.

package/schemas/crucible-ts/upstream/3leaps/crucible/docs/standards/classifiers-framework.md

@@ -0,0 +1,157 @@
+---
+title: "Classifiers Framework"
+description: "How 3leaps defines and uses orthogonal classification dimensions (docs + config + schemas)"
+category: "standards"
+status: "stable"
+version: "1.0.0"
+lastUpdated: "2026-01-22"
+maintainer: "3leaps-core"
+reviewers: ["platform", "security", "data-engineering"]
+approvers: ["3leapsdave"]
+tags: ["classification", "classifiers", "metadata", "governance", "schemas"]
+content_license: "CC0"
+relatedDocs:
+  - "schemas/classifiers/v0/dimension-definition.schema.json"
+  - "docs/standards/data-sensitivity-classification.md"
+  - "docs/standards/volatility-classification.md"
+  - "docs/standards/access-tier-classification.md"
+  - "docs/standards/retention-lifecycle-classification.md"
+  - "docs/standards/schema-stability-classification.md"
+  - "docs/standards/volume-tier-classification.md"
+  - "docs/standards/velocity-mode-classification.md"
+  - "docs/operations/upstream-sync-guide.md"
+audience: "all"
+---
+
+# Classifiers Framework
+
+Crucible classifiers are a lightweight framework for describing data and artifacts using **orthogonal dimensions**. The goal is to make classification:
+
+- **Consistent** across projects and ecosystems
+- **Machine-readable** for automation and policy enforcement
+- **Reference-friendly** (linkable docs, vendorable config)
+
+This framework is intentionally composable: consumers can adopt a single dimension (e.g., `sensitivity`) or a full set.
+
+---
+
+## What Lives Where
+
+Each dimension is expressed in three forms:
+
+1. **Standard (narrative)**: the human policy and examples (`docs/standards/*.md`)
+2. **Dimension definition (machine)**: a canonical list of values and metadata (`config/classifiers/dimensions/*.dimension.json`)
+3. **Meta-schema (validation)**: how dimension definitions are structured (`schemas/classifiers/v0/*.schema.json`)
+
+If you vendor anything, vendor **dimension configs + schemas together** so validation stays aligned.
+
+---
+
+## Current Dimension Set
+
+| Dimension Key         | Tier | Narrative Standard                                     | Machine Definition                                                 |
+| --------------------- | ---- | ------------------------------------------------------ | ------------------------------------------------------------------ |
+| `sensitivity`         | 1    | `docs/standards/data-sensitivity-classification.md`    | `config/classifiers/dimensions/sensitivity.dimension.json`         |
+| `volatility`          | 1    | `docs/standards/volatility-classification.md`          | `config/classifiers/dimensions/volatility.dimension.json`          |
+| `access-tier`         | 1    | `docs/standards/access-tier-classification.md`         | `config/classifiers/dimensions/access-tier.dimension.json`         |
+| `retention-lifecycle` | 1    | `docs/standards/retention-lifecycle-classification.md` | `config/classifiers/dimensions/retention-lifecycle.dimension.json` |
+| `schema-stability`    | 1    | `docs/standards/schema-stability-classification.md`    | `config/classifiers/dimensions/schema-stability.dimension.json`    |
+| `volume-tier`         | 2    | `docs/standards/volume-tier-classification.md`         | `config/classifiers/dimensions/volume-tier.dimension.json`         |
+| `velocity-mode`       | 2    | `docs/standards/velocity-mode-classification.md`       | `config/classifiers/dimensions/velocity-mode.dimension.json`       |
+
+Tier meaning:
+
+- **Tier 1**: universal infrastructure dimensions (applies almost everywhere)
+- **Tier 2**: data platform fundamentals (useful for pipelines and systems design)
+
+---
+
+## Minimal Data Model
+
+Crucible does not currently impose a single universal “classification object” schema. A common, portable pattern is:
+
+```json
+{
+  "classifiers": {
+    "sensitivity": "3-proprietary",
+    "access-tier": "restricted",
+    "retention-lifecycle": "standard",
+    "volatility": "daily",
+    "volume-tier": "medium",
+    "velocity-mode": "batch",
+    "schema-stability": "stable"
+  }
+}
+```
+
+Guidance:
+
+- Use **dimension keys** exactly as declared in the dimension definition JSON (`key`).
+- Treat classifier values as **opaque identifiers** (compare as strings, don’t parse them).
+- Do not rely on numeric ordinals or level numbers in docs; they may shift when new values (like `unknown`) are introduced.
+- Prefer **single source of truth** per artifact (don’t duplicate the same classification in multiple places).
+
+---
+
+## UNKNOWN and Missing Values
+
+Classification is safe-by-default—**missing classification is a policy error**.
+
+All dimensions include an explicit `unknown` value:
+
+| Dimension             | Unknown Meaning                                                      |
+| --------------------- | -------------------------------------------------------------------- |
+| `sensitivity`         | Unclassified; isolate until classified within 24h                    |
+| `volatility`          | Not yet classified; must classify before operational use             |
+| `access-tier`         | Not yet classified; must classify before sharing                     |
+| `retention-lifecycle` | Not yet classified; must classify before storage provisioning        |
+| `schema-stability`    | Not yet classified; must classify before consumers adopt             |
+| `volume-tier`         | Not yet classified; must classify before infrastructure provisioning |
+| `velocity-mode`       | Not yet classified; must classify before pipeline design             |
+
+For categorical dimensions, configs set `index_strategy.missing_handling: "error"` to enforce explicit classification. For sortable dimensions, treat missing values as invalid by policy—require explicit `unknown` or a concrete value.
+
+## Indexing Metadata (Non-Policy)
+
+Dimension configs include metadata intended for indexing and user interfaces:
+
+- `ordinal_mapping` and `default_order`: sorting and ordering hints
+- `sentinel`: an ordering/indexing placeholder (often `0` for `unknown`)
+- `is_none`: UI hint for a commonly selected “baseline” value (not a permission to omit classification)
+
+These fields MUST NOT be interpreted as policy defaults. Classification remains required even when a value is marked `is_none: true`.
+
+**Pattern**: When ingesting unclassified data, explicitly set `unknown` and gate downstream operations on classification completion.
+
+---
+
+## Volatility vs Velocity
+
+These dimensions are intentionally separate:
+
+- **Volatility**: how often the underlying data changes (freshness / cadence)
+- **Velocity mode**: how you process the data (batch / micro-batch / streaming / hybrid)
+
+See `docs/standards/velocity-mode-classification.md` for the relationship table and common pairings.
+
+---
+
+## Stability and Versioning
+
+During Crucible’s alpha phase:
+
+- Dimension definitions and docs may be marked `status: stable` to indicate the team’s intent that the meaning is not expected to churn.
+- Schemas live under `schemas/**/v0/` which signals the interface may still change.
+
+If you need strong stability guarantees, pin to a specific Crucible git commit (and document provenance) rather than relying on a moving `v0` URL.
+
+---
+
+## Extending the Framework
+
+When adding a new dimension:
+
+1. Add a narrative standard in `docs/standards/`
+2. Add a machine definition in `config/classifiers/dimensions/` validated by `schemas/classifiers/v0/dimension-definition.schema.json`
+3. Add examples and governance metadata (owner, reviewers, review cycle)
+4. Ensure the dimension is **orthogonal** (avoid overlapping meanings with existing dimensions)

package/schemas/crucible-ts/upstream/3leaps/crucible/docs/standards/data-sensitivity-classification.md

@@ -0,0 +1,259 @@
+---
+title: "Data Sensitivity Classification Standard"
+description: "Comprehensive data sensitivity levels for all 3leaps ecosystems"
+category: "standards"
+status: "stable"
+version: "1.0.0"
+lastUpdated: "2026-01-22"
+maintainer: "3leaps-core"
+reviewers: ["security", "compliance"]
+approvers: ["3leapsdave"]
+tags: ["classification", "sensitivity", "security", "data-handling"]
+content_license: "CC0"
+relatedDocs:
+  - "schemas/classifiers/v0/sensitivity-level.schema.json"
+  - "config/classifiers/dimensions/sensitivity.dimension.json"
+audience: "all"
+---
+
+# Data Sensitivity Classification Standard
+
+This standard defines sensitivity levels for data across all 3leaps ecosystems. It provides a consistent framework for:
+
+- **Automated Security Controls** - Classification-driven access and audit requirements
+- **Risk Assessment** - Clear understanding of data handling implications
+- **Compliance Management** - Structured approach to regulatory requirements
+- **Operational Safety** - Appropriate handling procedures by sensitivity level
+
+Missing classification is a policy error. At ingestion boundaries, explicitly set `unknown` until classification is complete.
+
+## Sensitivity Levels
+
+### UNKNOWN - Unclassified
+
+**Data classification unknown; must be isolated until classified.**
+
+| Aspect         | Requirement                                              |
+| -------------- | -------------------------------------------------------- |
+| **Handling**   | Isolate at data ingestion boundaries                     |
+| **Processing** | Use classification functions before storage/transmission |
+| **Access**     | Restricted to classification pipeline components only    |
+| **Audit**      | All handling logged until proper classification assigned |
+| **Timeline**   | Reclassify within 24 hours                               |
+
+**Examples**: Secrets discovered during scanning without context, config files from external sources, API keys without classification, logs that may contain credentials or PII.
+
+---
+
+### Level 0 - Public
+
+**Information known or intended to be in the public domain.**
+
+| Aspect              | Requirement   |
+| ------------------- | ------------- |
+| **Access Controls** | None required |
+| **Audit**           | None required |
+| **Retention**       | Unlimited     |
+
+**Examples**: Open source dependencies, public API documentation, published config templates, public status pages.
+
+**Permitted Operations**: Public repository storage, unrestricted sharing, external integration without controls, logging without redaction.
+
+---
+
+### Level 1 - Confidential
+
+**Information not available unrestricted; NDA or confidential marking required.**
+
+| Aspect              | Requirement                                |
+| ------------------- | ------------------------------------------ |
+| **Access Controls** | Authentication required, role-based access |
+| **Audit**           | Access logging recommended                 |
+| **Retention**       | Follow organizational retention policies   |
+
+**Examples**: Internal documentation and runbooks, non-production configs, development procedures, internal correspondence, business logic details.
+
+**Security Requirements**: Private repositories with access controls, encrypted storage at rest, VPN/secure network for remote access, team-based access with regular review.
+
+---
+
+### Level 2 - Blinded
+
+**Information obfuscated to protect identity of persons and enterprises.**
+
+| Aspect              | Requirement                                            |
+| ------------------- | ------------------------------------------------------ |
+| **Access Controls** | Authenticated access with blinding verification        |
+| **Audit**           | Audit blinding processes and access attempts           |
+| **Retention**       | Verify blinding effectiveness before long-term storage |
+
+**Examples**: Anonymized telemetry, sanitized logs with PII redaction, test data with real structure but fake identities, debugging info with customer data obfuscated.
+
+**Processing Requirements**:
+
+1. Use consistent, auditable obfuscation processes
+2. Regularly validate blinding effectiveness
+3. Document blinding methods used
+4. Ensure blinding cannot be easily reversed
+
+---
+
+### Level 3 - Proprietary
+
+**Enterprise information including MNPI, trade secrets, financial data.**
+
+| Aspect              | Requirement                                        |
+| ------------------- | -------------------------------------------------- |
+| **Access Controls** | Firewall-protected regions, need-to-know basis     |
+| **Audit**           | All access attempts logged and reviewed            |
+| **Retention**       | Business retention with secure deletion procedures |
+
+**Examples**: Production configs with business logic, database schemas with proprietary structures, enterprise client integration details, financial/performance data, strategic roadmaps.
+
+**Security Requirements**: Dedicated secure environments, multi-factor authentication, encrypted storage and transmission, regular access reviews, incident response procedures.
+
+---
+
+### Level 4 - Personal/Secret
+
+**Information containing NPPII or requiring specialized access controls.**
+
+| Aspect              | Requirement                                             |
+| ------------------- | ------------------------------------------------------- |
+| **Access Controls** | Specialized auditing, limited authorized personnel only |
+| **Audit**           | All access logged, success/failure monitoring           |
+| **Retention**       | Minimum retention, secure deletion with verification    |
+
+**Examples**: Production database credentials, encryption/signing keys, service account tokens with admin access, OAuth client secrets, personal information (emails, names, addresses), authentication tokens, password hashes.
+
+**Critical Security Requirements**:
+
+1. **Secrets Management**: Never store in code repositories or logs
+2. **Access Auditing**: Real-time monitoring of all access attempts
+3. **Rotation Policies**: Regular credential rotation with automation
+4. **Breach Response**: Immediate revocation and rotation if compromised
+5. **Environmental Isolation**: Separate from lower-sensitivity data
+
+---
+
+### Level 5 - Privileged/Sysadmin
+
+**Information pertaining to platform operations with attack potential.**
+
+| Aspect              | Requirement                                              |
+| ------------------- | -------------------------------------------------------- |
+| **Access Controls** | Information security team only, documented business need |
+| **Audit**           | Comprehensive logging, anomaly detection                 |
+| **Retention**       | Security-driven retention, tamper-proof logging          |
+
+**Examples**: System administration credentials (root, admin), infrastructure access keys (cloud admin), security monitoring data, vulnerability assessments, penetration test reports, backup encryption keys, network security configs.
+
+**Operational Security Requirements**: Air-gapped or highly isolated storage, hardware security modules (HSM), break-glass emergency procedures, continuous security monitoring, regular security audits.
+
+---
+
+### Level 6 - Eyes Only/Legal Hold
+
+**Information with extreme access restrictions and deletion protection.**
+
+| Aspect              | Requirement                                                   |
+| ------------------- | ------------------------------------------------------------- |
+| **Access Controls** | Executive/legal authorization required, immutable audit trail |
+| **Audit**           | Complete access logging, legal compliance tracking            |
+| **Retention**       | Legal hold procedures, protected against alteration/deletion  |
+
+**Examples**: Incident response data under investigation, security breach evidence, regulatory compliance data subject to discovery, executive communications on security matters, legal counsel privileged information.
+
+**Legal and Compliance Requirements**:
+
+1. **Immutable Storage**: Write-once, read-many systems
+2. **Legal Authorization**: Written approval for all access
+3. **Chain of Custody**: Complete audit trail for legal proceedings
+4. **Compliance Documentation**: Full regulatory compliance tracking
+5. **Executive Oversight**: Board/CEO level awareness and control
+
+---
+
+## Classification Decision Tree
+
+```
+Does the data contain credentials, keys, or authentication tokens?
+├── YES → Level 4+ (Personal/Secret or higher based on scope)
+└── NO → Does it contain personal or enterprise-identifying information?
+    ├── YES → Can identity be safely removed/blinded?
+    │   ├── YES → Level 2 (Blinded)
+    │   └── NO → Level 3+ (Proprietary or higher)
+    └── NO → Is it available publicly or intended for public use?
+        ├── YES → Level 0 (Public)
+        └── NO → Level 1 (Confidential)
+```
+
+---
+
+## Handling Matrix
+
+| Level                | Storage           | Transmission       | Logging           | Backup              | Sharing              |
+| -------------------- | ----------------- | ------------------ | ----------------- | ------------------- | -------------------- |
+| **UNKNOWN**          | Isolated staging  | Encrypted only     | Full audit        | Encrypted           | Prohibited           |
+| **0 - Public**       | Any location      | Any method         | Optional          | Any method          | Unrestricted         |
+| **1 - Confidential** | Private repos     | VPN/TLS            | Access logs       | Encrypted           | Team only            |
+| **2 - Blinded**      | Secure storage    | Encrypted          | Blinding audit    | Verified encryption | Authorized only      |
+| **3 - Proprietary**  | Isolated regions  | Dedicated channels | Comprehensive     | Secure deletion     | Need-to-know         |
+| **4 - Personal**     | HSM/Vault         | Zero-trust         | Real-time monitor | Immutable backup    | Authorized personnel |
+| **5 - Privileged**   | Air-gapped        | Secure channels    | Anomaly detection | Disaster recovery   | Security team only   |
+| **6 - Eyes Only**    | Immutable storage | Legal channels     | Legal compliance  | Legal hold          | Executive/legal only |
+
+---
+
+## Transitions
+
+### Downgrade Paths
+
+| From           | To             | Requirements                                                   |
+| -------------- | -------------- | -------------------------------------------------------------- |
+| 4-Personal     | 2-Blinded      | Tokenization/masking/synthetic surrogates; verification report |
+| 5-Privileged   | 3-Proprietary  | Security review and approval                                   |
+| 6-Eyes Only    | 3-Proprietary  | Legal release authorization                                    |
+| 2-Blinded      | 1-Confidential | Statistical privacy checks (k-anonymity, membership inference) |
+| 1-Confidential | 0-Public       | Publication review and approval                                |
+
+### Upgrade Triggers
+
+| Condition              | Action                                            |
+| ---------------------- | ------------------------------------------------- |
+| Secrets/PII discovered | Immediate upgrade to Level 4+                     |
+| Legal hold imposed     | Upgrade to Level 6                                |
+| Risk indicators found  | Trigger incident playbook, reclassify immediately |
+
+---
+
+## Incident Response
+
+### Level 4+ Breach Response
+
+1. **Immediate** (< 5 minutes): Revoke/rotate all potentially compromised credentials
+2. **Assessment** (< 30 minutes): Determine scope and potential impact
+3. **Notification** (< 1 hour): Inform security team and stakeholders
+4. **Remediation**: Deploy patches, update procedures, conduct post-mortem
+
+### Level 6 Breach Response
+
+1. **Executive Notification**: Immediate contact to CEO/legal counsel
+2. **Legal Assessment**: Determine regulatory and legal implications
+3. **Forensic Preservation**: Preserve evidence with chain of custody
+4. **Regulatory Compliance**: Follow notification and reporting requirements
+
+---
+
+## Machine-Readable Definitions
+
+- **Schema**: `schemas/classifiers/v0/sensitivity-level.schema.json`
+- **Dimension Config**: `config/classifiers/dimensions/sensitivity.dimension.json`
+
+---
+
+## Attribution
+
+This standard is the canonical reference for data sensitivity across 3leaps ecosystems. Downstream consumers (fulmenhq, practicingdata, etc.) should reference or vendor this standard rather than maintaining independent copies.
+
+**Review Cycle**: Quarterly with security and compliance teams.