Change one component and trace every impact downstream
PLM built for formulated products and engineered assemblies alike: the product record holds every version, its bill of materials or recipe, and the R&D behind it, so a raw-material or component change reaches every affected product without a manual audit.
Every product version, on one record
Most portfolios run on spreadsheets and slide decks that are stale the moment they are built. Status is typed in by hand, so gate reviews debate opinions, stalled projects quietly burn resources, and pipeline value and over-commitment stay invisible. Uncountable runs the portfolio on the same data as the lab, so the board is always current.
One product record, from definition to launch
Traditional systems track that a version changed. This one also holds why, because the development work and the product record are the same record.
One record, from first formula to final release
The product record is created once and stays the source of truth from development through commercialization.
One product record: Versions, specifications, documents, and the development work behind each revision all held on the same record rather than in four systems.
Requirements and targets up front: The performance targets a product has to hit are captured at the start, so every later result is evaluated against something real.
Precise about the boundary: The product record covers development through commercialization. Production batch history stays in QC and your MES, and Uncountable connects to it rather than claiming it.
Product record. Version history. Specifications. Attached documents. Development history
The bill of materials is built from the underlying formulation or engineering design, not typed in afterwards from a static file outside the system.
Formulation-driven by default, or synced from CAD/PDM: The recipe grid is native to the platform, so a formulation-based BOM reflects the recipe rather than a copy of it that drifts. For engineered assemblies, the eBOM connects to the CAD and PDM systems your engineers already use, so parts and revisions stay current with that source of record.
Multi-level, with real roll-ups: Sub-recipes such as a thickener or a defoamer, or sub-assemblies such as a bracket or a fastener kit, roll up into the parent product, and component quantities reconcile to the stated total on screen.
Bodie can build the first one for you: Hand over the bills of materials you already have and Bodie reads them, creates the records, and loads them into the database. Your own team can run this in Bodie too. Available with the Gen AI module.
Cost rolled up and checked against target: Structured unit costs roll up to a cost per kilogram (or a cost per unit for discrete parts) and are measured against the margin target, so a product reads as under or over target on the record. Your ERP syncs unit cost bidirectionally.
A cost change reprices and flags itself: When a raw-material or component cost moves, the affected products reprice and any that fall below margin are flagged, so you hear it from the system rather than from a quarterly review.
Complex supplier-driven calculations: Calculations that depend on supplier information are handled on the record, so the numbers hold up when a supplier or a grade changes. Budgeting and dedicated cost analysis stay with the tools built for them.
A prohibited or discontinued ingredient, or a part going end-of-life, is not one change. Where-used tells you how many products it really is before you commit.
Where-used, before you change anything: See every product, sub-recipe or sub-assembly, and specification an ingredient or part touches, so the scope of a substitution is known rather than discovered.
The change reaches every affected product: Change one ingredient or part and it filters down through the sub-recipes or sub-assemblies, parent products, and specifications that depend on it.
Traceable decisions: Each change carries its impact assessment and approvals, an engineering change order in discrete terms, and the development work behind the replacement is attached rather than referenced.
Where-used. Impact assessment. Change control (ECOs). Multi-level approvals. Version tree. Reprice and flag. Supply-chain propagation
A release should carry its evidence. Because development and the product record are the same record, it already does.
Organized, reviewed, traceable: Each stage of a launch enforces its reviews and holds the documentation that stage requires, so nothing advances on an undocumented decision.
Nothing gets retyped at handover: The formulation or design, results, and specifications that justified the release are already on the record. Manufacturing and quality read the same one.
Regulatory status checked before release: Each ingredient in the release carries a pass or fail status against the destination market's regulatory limits, checked on the same record, not a separate compliance spreadsheet.
Sustainability on the record being released: Recycled and bio content are screened, measured, and reported against targets on the same record you are releasing, ready to supply a Digital Product Passport.
Reformulate to hit the target: Set a recycled or bio-content target and reformulate against it, with the cost trade-off visible, since bio grades typically carry a premium.
See CAD integration in action
Watch a CAD file, part number, revision history, and all, live inside the same record as the formula it belongs to
See it in action at Behr
Behr Paint Company unified R&D and product approval workflows with Uncountable.
Connected to the systems you already run
Uncountable sits at the center as the system of record for R&D and quality data, with a comprehensive API and integration layer connecting the systems around it.
Where connected PLM shows up
A raw material gets swapped in a formula. The new bill of materials rolls up cost and quantity automatically, so every downstream recipe that depends on it updates instead of drifting out of sync with a spreadsheet nobody else opens.
A formula is ready to move to the next phase. The project can't advance past its current phase until the required reviewers have actually signed off, and that record travels with it; no hallway conversation, no email asking who approved what.
A recipe is submitted for sign-off. Every revision, comment, and approval is logged against the formula itself, so anyone opening it later sees exactly which version was approved and by whom, instead of chasing down a printed spec routed for initials.
An intermediate used across multiple products gets updated. Cost and composition roll up through every parent recipe automatically, surfacing the full blast radius before you commit to the change, rather than leaving you to manually check which finished goods depend on it.
A formula moves from R&D to process chemists. The same formula record carries forward with its full history, so the receiving team works from the source of truth instead of a re-entered spec with a decimal point that didn't survive the copy.
A formula is ready to go live. The approved recipe releases straight into production with its full formulation and approval trail attached, so what runs on the floor matches what was signed off; no re-key into ERP, no hoping nothing was mistyped.
Shared by every suite
Bodie and the Portal work across R&D, Quality, Product Lifecycle and Project Management at once, on the same structured data model.
Bodie, the AI Layer
The Uncountable Portal
.png)
Traditional PLM captures version history. We also capture how each version was developed.
Uncountable holds the development record and the version history on the same structured data model, for a recipe or an assembly alike, and that development layer is why the product record can answer why as well as what.
FAQs
Yes. The same structured, versioned bill of materials and where-used logic that connects a formulation to its raw materials works the same way for an assembled product and its parts, sub-assemblies, and specifications. Multi-level roll-ups, change propagation, and stage-gated releases behave identically whether the underlying record is a recipe or an engineering BOM.
The recipe grid is native rather than an add-on, so a formulation-based BOM is built from the formulation instead of retyped from a static file outside the system; for engineered assemblies, the eBOM connects to your CAD and PDM systems instead. Sub-recipes or sub-assemblies roll up into the parent product, quantities reconcile to the stated total, and each component stays connected to its underlying formulation, raw-material, or engineering records. Unit costs roll up to a cost per kilogram or per unit and are measured against the margin target, and a cost change reprices the affected products and flags any that fall below margin.
Sustainability and ESG sit on the same product record, with four views: profile, screening, measurement, and where-used. Recycled and bio content are modeled as a grade-level choice with a real cost trade-off, since bio grades typically cost more, and you can reformulate against a target directly on the record. Because composition, supplier information, and version history are already structured and connected, Uncountable supplies the verified product data that a Digital Product Passport, a lifecycle assessment, or a regulatory submission is built from.
Each ingredient is screened against market-specific regulatory limits on the same record as the formulation, with a pass or fail status shown at the ingredient level. Because it runs on the structured composition data already in the system, a market-compliance check doesn't require exporting the recipe to a separate tool.
No. The product record is the source of truth from development through commercialization. Production batch history lives in QC and your MES, and Uncountable connects to those systems rather than claiming to replace them.
