diff --git a/CLAUDE.md b/CLAUDE.md index 742e3096..a1df1753 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -77,5 +77,7 @@ Read in `run_from_env` (`src/lib.rs`): `BIND_ADDR` (default `127.0.0.1:8080`), ` - `docs/architecture.md` — component map, security boundaries, integration roadmap. - `docs/fuzzing.md` — fuzz target table and invariants. -- `docs/commercial/20b-krw-sale-readiness.md` — formal acceptance criteria behind the commercial readiness APIs. +- `docs/commercial/2b-krw-customer-contract-readiness.md` — customer-contract readiness acceptance criteria behind the existing commercial readiness APIs. +- `docs/commercial/usd-20b-product-quality-bar.md` — separate USD 20 billion software-quality ambition; never use it as tenant contract-value authority. +- `docs/commercial/20b-krw-sale-readiness.md` — compatibility path retained for published evidence-manifest references; not numeric authority. - `docs/runbooks/operations.md`, `docs/security/threat-model.md`. diff --git a/README.md b/README.md index d1587583..ba0bc40f 100644 --- a/README.md +++ b/README.md @@ -39,7 +39,7 @@ The 2B KRW sale readiness baseline means the runtime can prove a buyer-facing pi - `GET /api/commercial/evidence-manifest` returns the buyer-verifiable runtime, document, and deployment evidence map. - `GET /api/support-bundle` returns health, KPIs, license, readiness, and evidence counts without admin secrets. -The formal acceptance criteria are in `docs/commercial/20b-krw-sale-readiness.md`. +The customer-contract acceptance criteria are in `docs/commercial/2b-krw-customer-contract-readiness.md`. The separate USD 20 billion software-quality ambition is defined in `docs/commercial/usd-20b-product-quality-bar.md`; it is not a tenant contract-value threshold. The enterprise product package evidence is tracked in: diff --git a/docs/commercial/20b-krw-sale-readiness.md b/docs/commercial/20b-krw-sale-readiness.md index 502188b4..1d9323df 100644 --- a/docs/commercial/20b-krw-sale-readiness.md +++ b/docs/commercial/20b-krw-sale-readiness.md @@ -1,56 +1,12 @@ -# 2B KRW Commercial Sale Readiness Standard +# Compatibility notice: commercial readiness authority moved -This project treats a 2B KRW sale as an enterprise due-diligence threshold, not a marketing claim. The runtime must expose evidence that an operator can verify without reading source code. +This historical path is retained only because protected-main buyer-evidence manifests and external links may still reference `docs/commercial/20b-krw-sale-readiness.md`. The filename is misleading: the runtime contract it historically described is **2B KRW**, not 20B KRW, and it is unrelated to Wardnet's USD 20 billion software-quality ambition. -## Acceptance Criteria +Canonical authorities are now separated: -1. The product exposes a tenant-aware license profile through `GET /api/commercial/license`. -2. Authorized operators can register license metadata through `POST /api/commercial/license`. -3. The license profile must support edition, status, licensee, node count, support contact, and annual contract value. -4. The annual contract value must be at least `2_000_000_000` KRW for the readiness API to report sale readiness. -5. Threat feed updates must be importable through `POST /api/threat-feeds/import`. -6. The product must expose fresh/stale threat feed evidence through `GET /api/threat-feeds/freshness`. -7. The product must expose SOC event export through `GET /api/events.ndjson`. -8. The product must retain threat feed status, imported HTTP indicators, DNSBL entries, gateway routes, and security events across restart when `WAF_IDS_STATE_PATH` is configured. -9. The readiness API must report blockers instead of returning a vague success state. -10. The support bundle API must return health, KPIs, license metadata, readiness checks, feed freshness, and evidence counts without secrets. -11. The product must expose a buyer evidence manifest through `GET /api/commercial/evidence-manifest` so evaluators can verify required runtime APIs, committed documents, and deployment assets from one contract. -12. The product must expose management write audit logs through `GET /api/audit-logs` without persisting admin tokens or request bodies. -13. Docker, Compose, and Kubernetes deployment assets must exist for buyer lab validation. -14. Security, compliance, architecture, operations, and KPI evidence must be committed with the product. -15. Reusable domain logic must be separated from HTTP/persistence code when that improves maintainability without adding release overhead. -16. Product design, Figma/FigJam, analytics, complexity-audit, and implementation-plan evidence must be committed for buyer due diligence. +- [2B KRW Customer Contract Readiness](./2b-krw-customer-contract-readiness.md) defines the existing `annual_contract_value_krw` / `target_sale_value_krw` compatibility predicate. +- [USD 20 Billion Product Quality Bar](./usd-20b-product-quality-bar.md) defines the software-quality and buyer-evidence ambition. -## Runtime Readiness API +This compatibility filename **must not be used as numeric authority** for either concept. Keeping it temporarily avoids breaking the currently published evidence-manifest document path while the runtime API still exposes that path. A later versioned API/document-manifest migration may remove this shim after consumers have a compatibility window. -`GET /api/commercial/readiness` returns: - -- `target_sale_value_krw`: always `2000000000` -- `ready_for_enterprise_sale`: true only when all checks pass -- `readiness_level`: `sale_ready` or `implementation_required` -- `blockers`: failed check identifiers -- `deployment_assets`: expected production packaging files -- `buyer_evidence`: due-diligence document paths - -`GET /api/commercial/evidence-manifest` returns the buyer validation map: - -- current readiness state and blockers -- runtime counts for routes, indicators, DNSBL entries, feeds, fresh/stale feeds, and events -- required evidence endpoints with method, path, content type, and what each endpoint proves -- management audit-log count and the `GET /api/audit-logs` endpoint for successful admin writes -- committed document paths and deployment assets that should be reviewed during procurement - -## Required Passing Checks - -- `license`: active or evaluation license metadata is present. -- `contract_value`: annual contract value is at least 2B KRW. -- `threat_feed_updates`: at least one imported threat feed is fresh within its TTL. -- `gateway_enforcement`: at least one enabled gateway route exists. -- `dnsbl_publication`: DNSBL entries are available for zone export. -- `support_evidence`: at least one security event exists for a support bundle. - -## Current Boundary - -The project is still a commercial baseline, not a complete enterprise WAF/IDS suite. Production buyers should require follow-on integration of Coraza/OWASP CRS, Suricata EVE ingest, durable database storage, SSO/RBAC, audit logs, signed release artifacts, and production SIEM mapping before internet-edge deployment. - -The current library boundary is `crates/waf-ids-core`, a local workspace crate. A submodule is not justified until an independently versioned adapter or SDK exists. +Do not infer a 20B KRW customer threshold from this filename and do not encode the USD 20 billion product-quality bar into tenant pricing, billing, license, or accounting fields. diff --git a/docs/commercial/2b-krw-customer-contract-readiness.md b/docs/commercial/2b-krw-customer-contract-readiness.md new file mode 100644 index 00000000..31568a76 --- /dev/null +++ b/docs/commercial/2b-krw-customer-contract-readiness.md @@ -0,0 +1,60 @@ +# 2B KRW Customer Contract Readiness Standard + +This document defines Wardnet's existing customer-contract readiness predicate. The `2_000_000_000` KRW threshold is tenant/customer commercial metadata used by the current readiness API. It is not product valuation, software-sale ambition, a billing ledger, or evidence that Wardnet itself is worth or should be sold for that amount. + +The separate [USD 20 billion product-quality bar](./usd-20b-product-quality-bar.md) is a software-quality ambition. It must not be represented by `annual_contract_value_krw`, `target_sale_value_krw`, tenant pricing, billing state, or accounting facts. + +## Acceptance Criteria + +1. The product exposes a tenant-aware license profile through `GET /api/commercial/license`. +2. Authorized operators can register license metadata through `POST /api/commercial/license`. +3. The license profile supports edition, status, licensee, node count, support contact, and annual contract value. +4. The existing readiness predicate treats `annual_contract_value_krw >= 2_000_000_000` as the customer-contract-value check. Changing that value requires an independent accepted product decision; it is never derived from the USD 20 billion quality ambition. +5. Threat feed updates are importable through `POST /api/threat-feeds/import`. +6. The product exposes fresh/stale threat-feed evidence through `GET /api/threat-feeds/freshness`. +7. The product exposes SOC event export through `GET /api/events.ndjson`. +8. The product retains threat-feed status, imported HTTP indicators, DNSBL entries, gateway routes, and security events across restart when the configured standalone state adapter is in use. +9. The readiness API reports concrete blocker identifiers rather than a vague success state. +10. The support-bundle API returns health, KPIs, license metadata, readiness checks, feed freshness, and evidence counts without secrets. +11. The product exposes a buyer evidence manifest through `GET /api/commercial/evidence-manifest` so evaluators can verify required runtime APIs, committed documents, and deployment assets from one contract. +12. The product exposes management write audit logs through `GET /api/audit-logs` without persisting administrator tokens or request bodies. +13. Docker, Compose, and Kubernetes deployment assets exist for buyer lab validation where the protected source advertises them. +14. Security, compliance, architecture, operations, and KPI evidence is committed with the product and must remain explicit about protected-main versus candidate maturity. +15. Reusable domain logic is separated from HTTP/persistence code when that improves maintainability without inventing a second authority. +16. Product-design, analytics, complexity-audit, and implementation-plan evidence used in due diligence remains evidence, not a substitute for executable product gates. + +## Runtime Readiness API + +`GET /api/commercial/readiness` currently returns: + +- `target_sale_value_krw`: `2000000000`; +- `ready_for_enterprise_sale`: true only when all current readiness checks pass; +- `readiness_level`: `sale_ready` or `implementation_required`; +- `blockers`: failed check identifiers; +- `deployment_assets`: expected packaging files; +- `buyer_evidence`: due-diligence document paths. + +`GET /api/commercial/evidence-manifest` returns the buyer validation map: + +- current readiness state and blockers; +- runtime counts for routes, indicators, DNSBL entries, feeds, fresh/stale feeds, and events; +- required evidence endpoints with method, path, content type, and what each endpoint proves; +- management audit-log count and the `GET /api/audit-logs` endpoint for successful administrator writes; +- committed document paths and deployment assets that should be reviewed during procurement. + +These fields are compatibility/runtime evidence. Their names do not make the customer contract threshold a product-valuation authority. + +## Required Passing Checks + +- `license`: active or evaluation license metadata is present. +- `contract_value`: annual contract value is at least 2B KRW. +- `threat_feed_updates`: at least one imported threat feed is fresh within its TTL. +- `gateway_enforcement`: at least one enabled gateway route exists. +- `dnsbl_publication`: DNSBL entries are available for zone export. +- `support_evidence`: at least one security event exists for a support bundle. + +## Current Boundary + +The readiness predicate is only one customer/commercial metadata surface. It does not establish production readiness. Protected production truth still requires the independent security, identity, durable-state, release, observability, recovery, integration, and review/control-plane gates tracked by the repository's production-readiness authority and product/technical gap baseline. + +The current 2B KRW value remains unchanged in this documentation repair. A future change to customer contract readiness must be justified on its own product authority and versioned API compatibility; it must not be inferred from the USD 20 billion software-quality ambition. diff --git a/docs/commercial/usd-20b-product-quality-bar.md b/docs/commercial/usd-20b-product-quality-bar.md new file mode 100644 index 00000000..c73e0b8b --- /dev/null +++ b/docs/commercial/usd-20b-product-quality-bar.md @@ -0,0 +1,39 @@ +# USD 20 Billion Product Quality Bar + +Wardnet uses **USD 20 billion** as a deliberately demanding software-sale quality ambition: the product, evidence, architecture, operability, security posture, and buyer experience should be developed to a standard that could withstand due diligence for a software asset of that scale. It is not a tenant price, contract-value threshold, billing rule, or accounting fact. + +This ambition therefore has no direct numeric mapping to `annual_contract_value_krw`, `target_sale_value_krw`, license metadata, revenue, ARR, or another customer field. The existing 2B KRW customer-contract readiness predicate remains a separate compatibility contract documented in [2B KRW Customer Contract Readiness](./2b-krw-customer-contract-readiness.md). + +## Authority boundary + +The USD 20 billion ambition is an engineering and commercial-quality bar. It is satisfied only through buyer-visible evidence accumulated in the bounded contexts that own the relevant truth. A number in a tenant profile cannot satisfy it. + +Wardnet owns gateway and SOC control-plane policy, Agent Artifact Admission, Wardnet security verdicts, local runtime/network enforcement evidence, and Wardnet audit/provenance. Quarantine Sandbox Runtime owns hostile execution isolation. contextual-orchestrator owns Agent/LLM provider and model orchestration. EgressWeave may provide a released outbound-policy contract. Context Graph Contracts and Enterprise Architecture Core retain their respective canonical contract and architecture-decision authority. Wardnet consumes those external capabilities only through released, versioned contracts or anti-corruption layers and does not copy their source or read their application databases. + +## Buyer-visible evidence + +Progress against this quality bar is demonstrated by concrete evidence such as: + +- fail-closed authentication, authorization, admission and outbound-destination policy with hostile-case regressions; +- production-grade durability, tenant isolation, transactionality, replay/idempotency, bounded resource use, recovery and rollback; +- proven WAF/IDS enforcement and measurable detection/false-positive behavior rather than hand-written baseline heuristics alone; +- reproducible exact-head CI, security analysis, fuzz/property coverage, 100% owned production statement/branch/edge-case coverage, rustdoc/docstring completeness, SBOM, provenance, signatures and immutable release identity; +- protected-branch governance that is satisfiable without self-approval, fabricated human review, routine bypass, stale predecessor evidence or false-green infrastructure output; +- versioned integration contracts with canonical CWL owners, provenance, schema/conformance evidence, and fail-closed behavior when an immutable compatible release is absent; +- production-shaped performance, capacity, readiness/liveness/startup, incident-response, observability, backup/restore and game-day evidence; +- code-current PRD/TRD/ADR/architecture/threat-model/test/operability/release documentation whose claims distinguish protected truth from candidate work; +- procurement-facing evidence that a buyer can independently verify without trusting a marketing statement. + +The live evidence inventory and remaining gaps belong in `docs/product-technical-gap-baseline.md` and the repository's production-readiness issue. Individual feature PRs may contribute evidence, but neither an open branch nor a readiness endpoint promotes that evidence to protected/released truth. + +## Decision rule + +A feature does not advance this bar merely because it raises a commercial number. It advances the bar when it removes a buyer-visible product, security, reliability, governance, integration, performance, or operability gap with reproducible evidence and preserves Wardnet's bounded-context ownership. + +Conversely, no deployment should be rejected solely because its `annual_contract_value_krw` does not encode the USD 20 billion ambition. Customer contract metadata and software quality/valuation are different ubiquitous-language concepts with different authorities. + +## Evidence discipline + +Claims against this quality bar must identify the exact protected source or immutable release, applicable tests and security gates, contract/provenance identity where external owners are consumed, known residual risks, and rollback/recovery behavior. Candidate PR evidence is useful for development but must not be presented as shipped capability before protected integration and release. + +This document intentionally does not create a product valuation model or forecast. If a future process needs financial valuation, pricing, billing, or accounting truth, that requires its own accepted bounded context and evidence rather than overloading Wardnet's customer readiness fields. diff --git a/tests/commercial_authority_architecture.rs b/tests/commercial_authority_architecture.rs new file mode 100644 index 00000000..9c1092f5 --- /dev/null +++ b/tests/commercial_authority_architecture.rs @@ -0,0 +1,41 @@ +use std::fs; +use std::path::Path; + +fn repo_file(path: &str) -> String { + fs::read_to_string(Path::new(env!("CARGO_MANIFEST_DIR")).join(path)) + .unwrap_or_else(|error| panic!("failed to read {path}: {error}")) +} + +#[test] +fn product_quality_ambition_is_not_a_customer_contract_threshold() { + let core = repo_file("crates/waf-ids-core/src/lib.rs"); + let customer_contract = repo_file("docs/commercial/2b-krw-customer-contract-readiness.md"); + let product_quality = repo_file("docs/commercial/usd-20b-product-quality-bar.md"); + let legacy = repo_file("docs/commercial/20b-krw-sale-readiness.md"); + + assert!( + core.contains("pub const TARGET_SALE_VALUE_KRW: u64 = 2_000_000_000;"), + "the existing customer-contract readiness threshold must remain 2B KRW unless a separate product decision changes it" + ); + assert!( + !core.contains("TARGET_SALE_VALUE_KRW: u64 = 20_000_000_000"), + "the product-quality ambition must not be encoded as tenant contract value" + ); + + assert!(customer_contract.contains("2B KRW Customer Contract Readiness")); + assert!(customer_contract.contains("annual_contract_value_krw")); + assert!(customer_contract.contains("not product valuation")); + assert!(customer_contract.contains("usd-20b-product-quality-bar.md")); + + assert!(product_quality.contains("USD 20 billion")); + assert!(product_quality.contains( + "not a tenant price, contract-value threshold, billing rule, or accounting fact" + )); + assert!(product_quality.contains("Buyer-visible evidence")); + assert!(product_quality.contains("2b-krw-customer-contract-readiness.md")); + + assert!(legacy.contains("Compatibility notice")); + assert!(legacy.contains("2b-krw-customer-contract-readiness.md")); + assert!(legacy.contains("usd-20b-product-quality-bar.md")); + assert!(legacy.contains("must not be used as numeric authority")); +}