# cbb-sign — Acquisition Brief
# Cold Bore Ballistics LLC — Internal Reference
# Classification: Confidential
# Last Updated: 2026-06-12

This brief summarizes the cbb-sign internal document-signing platform for a buyer's technical due-diligence review.

> **Status: planned / pre-provisioning as of 2026-06-12.** The SPEC and infrastructure design are complete; the system is not yet built. This brief describes the designed system and its DD posture.

---

## What It Is

cbb-sign is CBB's **internal** document-signing platform — a CBB-branded wrapper (FastAPI API + Next.js UI, Entra ID SSO) around **Engross**, a self-hosted, renamed DocuSeal fork that acts as the signing engine. Internal staff send NDAs, operating agreements, and contractor agreements for legally binding e-signature; cbb-sign files the executed PDF to OneDrive with a consistent name and an immutable audit trail. It is corporate internal tooling — **not** a ScopeDOPE feature and **not** a customer-facing product.

## Architecture Summary

Two **Azure Container Apps** (`ca-cbb-sign-api-prod`, `ca-cbb-sign-ui-prod`) in the existing VNet-injected environment `cae-cbb-prod`, fully serverless and scale-to-zero, reproduced entirely from Terraform (`cbb-infra/services/cbb/`). The signing engine is a renamed public AGPL-3.0 DocuSeal fork (also a Container App). cbb-sign reuses existing CBB infrastructure — PostgreSQL (`psql-cbb-prod`, adds a `cbb_sign` database), storage (`stcbbprod`, adds a WORM certificate container), registry (`crcbbprod`), and Key Vault (`kv-cbb-shared-prod`). No third-party SaaS signing service — CBB controls the platform and all document data.

## Cost

**Low and consumption-based.** Incremental Azure cost is **~$2–8/month** on top of the existing CBB footprint — dominated by two scale-to-zero Container Apps; the new database and certificate storage are negligible. No reserved commitments. See `CBB_Sign_Cost_Impact_Analysis.md` for the breakdown and alternatives considered. (Build effort: ~115.5h labor — see `CBB_Sign_LOE.md` — not Azure spend.)

## Data Ownership and System of Record

All data is CBB-owned and in CBB-controlled Azure + M365:
- **Executed PDFs:** OneDrive `CBB_Corporate/03_-_Confidential/Legal_and_Trademarks/Signed_Agreements/`.
- **Legal audit trail:** append-only `cbb_sign` PostgreSQL table (DB-enforced immutability — `INSERT`/`SELECT` only, no `UPDATE`/`DELETE`) **+** Azure Blob **WORM** completion certificates (time-based retention).
- **cbb-sign is the legal system of record** — it mirrors the engine's signing events via webhook into its own immutable store, so the record survives replacement of the signing engine entirely.

No document or signer data is held by any third party.

## Vendor / IP Risk

**Low, with one documented item.** The signing engine is open-source (AGPL-3.0) — no vendor lock-in, no per-seat/per-envelope SaaS pricing. A buyer can keep the deployment, swap to their own enterprise e-signature stack, or migrate freely; all signed documents are already CBB-owned in OneDrive.

The one DD item: cbb-sign runs a **modified** AGPL-3.0 fork (Engross), which triggers AGPL §13 (network users may request modified source). CBB's documented position is **comply by offering source** — Engross is public in the `ColdBoreBallistics` org with an in-app source-offer link and proper modified-file attribution. This is recorded in the **CBB Risk Register (RISK-028)** with legal review recommended before go-live. The fork is **replaceable plumbing** — it holds no CBB data or IP; removing it loses nothing. (Engross is AGPL-3.0; CBB's other public repos, the bt-bridge-* set, are Apache-2.0.)

> Practical DD note: an acquirer almost certainly has an entrenched e-signature stack of their own, so cbb-sign + the fork is throwaway plumbing in their environment — a clean-up checklist item, not a valuation driver.

## Reproducibility

**Infrastructure-as-code, zero hand-built resources.** Every cbb-sign resource is defined in `cbb-infra/services/cbb/` (+ `services/dns/`, and additions to `services/scope-dope/` for the DB and certificate container). The Rebuild Guide documents full from-scratch recovery in ~1–2 hours with **no tribal knowledge** — a buyer's engineer can stand it up, operate it, and recover it from the documentation alone. Secrets live only in Key Vault (read at runtime via managed identity), so a buyer can rotate every secret without touching code, state, or config.

## Separation and Cost Attribution

cbb-sign is **corporate** (`cost_center: cbb-corp`), cleanly separated from ScopeDOPE via the existing tag scheme and Terraform service boundary. Its spend is independently visible in Azure Cost Analysis. For a ScopeDOPE-only acquisition, cbb-sign is carved out cleanly; for a whole-company acquisition, it is a small, well-documented, low-risk internal tool.

## Operational Dependencies

cbb-sign runs in `cae-cbb-prod` (independent of the VM). It reaches the private PostgreSQL server and the internal engine/Gotenberg over the VNet, with no public exposure beyond the authenticated `sign.*`/`sign-api.*` endpoints and the engine's signer-facing `esign.*`. The post-sign filing is owned by cbb-sign's own webhook handler (the prior DocuSeal→OneDrive Logic App is retired), so there is exactly one filing path and one Graph identity to account for.

## Open Items a Buyer Should Know

- **AGPL position (RISK-028, OI-B): legal confirmation pending before go-live.** Strategy is "comply by offering source" — the engine fork (Engross) is public in the `ColdBoreBallistics` GitHub org under AGPL-3.0, with modified-file marking per §5a and an in-app source link satisfying §13. Risk is *mitigating* (compliance posture defined; legal sign-off pending).
- **WORM retention (RISK-029 framing, OI-C): legal confirmation pending.** Initial policy is **1 year** time-based immutability on the cert container, applied only after legal confirms the period is defensible for our document classes. Retention can always be lengthened later; the irreversible operation is policy application, so the gate is intentional. (Note: this OI is tracked in the SPEC as OI-C; legal-confirm is the prerequisite for `terraform apply` on the WORM container.)
- **Wet-signature sufficiency (RISK-029): accepted risk.** Internal counter-signatures and other low-risk paths may use the `wet_signature_required` flag to bypass cryptographic capture; the on-paper signature is held as the legal record. Reserved for internal/low-risk counter-signing only; not used for external counter-parties or material legal instruments.
- **Single-filer governance (RISK-030): mitigated, not accepted.** Engross is modified so filers cannot be added as signers (Option B); the engine admin path is sealed under a break-glass procedure (Runbook §10). A buyer evaluating the engine will find the modification documented and the break-glass procedure in the Operating Runbook.
- **Fork naming and IP posture (OI-A): RESOLVED.** Engine fork is named **Engross**,