Change Control Board (CCB). CCB is full-spectrum change: engineering change, process change, IT change, facility change, and policy change. One change record that can name the Item, the AssetId, the Person, and the LegalEntityId it hits — not a CAB PowerPoint, a separate ECO, and a separate ServiceNow change.
In industry this is the union of ECO tooling, ITSM change, and facilities work-request governance (capability equals, not products we ship). You are replacing those queues with one spine on N23D. 100% Rust we write.
CCB is the single place a proposed change becomes an approved effectivity or an approved operational cutover. PLM still holds product effectivity. TIX still holds asset state. BUS still holds people and legal entities. ERP still holds one company’s books. CCB is the decision and the audit that crosses them — not a second vault that copies their data.
What CCB actually does
- Change request types: product (ECO/ECR class), process/routing, IT (infrastructure and software), OT/control, facility, and policy/compliance — one object model with typed impacts.
- Impact set must name what it touches: Item/Revision, VariantId, AssetId, Person roles, LegalEntityId, documents, and interfaces. A change that cannot name what it touches is not a change. It is a hope.
- Authority, risk, schedule, and close-out on one record. Approvers are BUS persons with roles — not a slide deck of initials.
- Product effectivity objects remain PLM’s. CCB can authorize and link them. Asset cutover plans remain TIX’s. CCB can authorize and link them.
- Command::Core remains the identity and policy plane. CCB is how policy meets a dated decision.
- Traceability: from CAPA (QMS), gate slip (PMO), incident (TIX), or design review (PLM) into one change spine — and back out to implementation evidence.
Why twelve change queues fail
Engineering keeps ECOs in PLM. IT keeps changes in an ITSM tool. Facilities keeps work requests in email. The CIO asked for one application that replaces the rest — that includes one change spine. When those queues disagree, the plant ships yesterday’s truth with tomorrow’s network and last week’s procedure.
- ECO without AssetId impact misses the cell that must be revalidated.
- IT change without Item/VariantId impact misses the software that stamps the traveler.
- Facility change without LegalEntityId misses who pays and who is liable.
- CAB theater without an auditable object is governance cosplay.
How N23D puts this in one place
Most stacks fail the day after save, when the model, the ticket, or the invoice becomes someone else’s import. N23D removes that day. This module reads the same record as the others.
- one native Rust binary: N23D. 100% Rust we write. No vendor kernel, ledger, PLC runtime, HRIS, or ITSM as the source of truth. File readers and protocol bridges are interchange.
- One identity plane: Item, VariantId, Person, and AssetId are global. Invoice, work order, inventory, quote, pay result, and NCR sit on a LegalEntityId.
- One digital thread: modules read the same record. There is no daily STEP shuffle as the workflow. Check-in is PLM save. CAM does not fork the body.
- Command::Core is the identity and policy plane. CCB is the full-spectrum change spine (not a second vault). TIX holds operational life of assets; ERP sees only the financial view.
- Materials only from MAT. CAD selects VariantId. Missing density means mass is unknown — we do not invent a number so a BOM or plot closes.
- ERP is one company’s books. BUS holds HR, org, legal entities, and group consolidation. HoldCo is not a plant. No fake Form 1120. No fake Lohnsteuer.
- CCB does not become a second vault. Assets stay in TIX. Product stays in PLM and MAT. Books stay in ERP. People stay in BUS.
- CCB binds them with authority, risk, schedule, and close-out on the thread.
What we will not fake
This is the product promise, not a claim that every solver and every pack already ships in the binary today. Industry-class names below are capability equals. They are not products we ship.
- We do not ship governance theater. A CAB that cannot see the ECO and the asset ticket is the vendor set we retire.
- CCB is not a second PLM and not a second CMDB.
- File readers are interchange. Honesty about v1 workflow packs is part of the contract.
If engineering, IT, and facilities still keep three truths about the same change, we failed. One change record.
Natively connected, not glued together
N23D runs one data model across design, make, operate, and the business. Nothing is exported as the daily path. Nothing is re-keyed. Nothing is lost in translation between vendors.
- One data model. A part, an order, a nonconformance, a ticket, and a change point at the same objects. No mapping tables, no nightly sync, no drift.
- No export/import loss. Geometry, tolerances, revisions, asset state, and history stay intact because they never leave the system as the daily path.
- Auditability by default. Every change is versioned and attributable, so traceability is a query, not a project.
- Speed. 100% Rust: native performance, small footprint, no runtime surprises.
- Sovereignty. Your data, your infrastructure, your rules. No lock-in.
