ProPharma Unified Build

Applications

Every component against the delivery lifecycle, generated from the build repo rather than typed.

READ THIS BEFORE ANY PERCENTAGE

The ERP is live as a platform and holds ZERO migrated ProPharma rows.

Every populated table is ERPNext test and demo fixtures: Account 2,126 all named _Test* and not one with an account number; Company 21 including _Test Company UAE VAT and Wind Power LLC; Item 29 including Macbook Pro and Photocopier; Supplier 10 of 10 fixtures; Customer 12 being eleven _Test plus ERPNext's demo customer Prestiga-Biz. Zero ProPharma customers, items or suppliers.

So 'the unified build is live' is TRUE of the platform and FALSE of the data. No unified-build module may claim Verified on the strength of an ERP row count, and nothing in this programme is Shadowed at all.

Row counts were read and called real. Counting cannot distinguish data from fixtures because it never looks at a value. One `select name from tabItem` settled it.

Every component in the programme against the delivery lifecycle. Generated 2026-08-26T13:29:06+00:00 from pipeline/components.py in the build repo, which is also what the standalone board reads. Nothing on this page is typed by hand, so it cannot disagree with the machine-readable copy at /api/pipeline.json.

25components

37.5%mean complete

17measured

8judged

6unsupported claims

2dual ownership

3blocked

The lifecycle, and why the scale is unflattering

0 Proposed · 0% 1 Scoped · 8% 2 Designed · 20% 3 Built · 40% 4 Verified · 60% 5 Shadowed · 85% 6 Live · 100% 7 Retired · 100%

Reaching Built earns 40%, not 50%. The remaining 60% is verification, shadowing and cutover, because a component that is built with its tests passing is precisely where this programme's defects have hidden. That is deliberate: anything built-but-unverified must not read as nearly done.

Built is not Verified

The recall matcher was written, published, and passing every one of its tests while reading the wrong field. It would never have fired on a real recall. The same night, a mapping module declared Acumatica fields that do not exist, so reconciliation keyed on empty strings and reported clean. Both were 'built, tests passing'. Neither worked. Tests encode what the author believed; verification asks reality. So Verified requires a read of real production data, with a date and a source system.

Verified is not Shadowed

The connector shadow ran every six hours, compared 151 SKUs out of 5,650, and reported healthy. Parallel running that nobody diffs is not a shadow, it is a second expensive job. So a Shadowed claim requires three things: a stored diff, its denominator, and a demonstrated failure mode. A check that cannot fail is not evidence.

Live is not Retired

'Live' and 'the incumbent is switched off' are different states, and the gap between them is where two systems believe they own the same fact. Our pricing engine writes BigCommerce prices while the incumbent's price procedure still exists; the vendor connector still syncs while ours runs. Collapsing that into one stage hides the most expensive risk in the programme, so it gets its own column and its own flag.

Evidence a stage claim must point at

Stage	Required evidence
1 Scoped	decisions recorded in a document under version control
2 Designed	a data model or interface committed, reviewable
3 Built	a test count from an actual run, not a claim
4 Verified	a read of real production data, with a date and a source system
5 Shadowed	a stored diff, its denominator, and a demonstrated failure mode
6 Live	the component observably carrying real workload
7 Retired	the incumbent confirmed off

Components

Connector

Pricing flow

6 Live · measured

100.0%

Our engine owns price; DCAA's dcaa_UpdateEffectivePriceCost still exists. Live but not retired -- dual ownership. · STAGE CLAIM UNSUPPORTED: claims Shadowed with no stored diff; claims Shadowed with no denominator -- 151 of 5,650 read as healthy once; claims Shadowed with no demonstrated failure mode · DUAL OWNERSHIP: live, and the incumbent is still running

Products flow

6 Live · measured · owner: vendor

100.0%

The VENDOR connector is live and owns this. We observe it; we never shadowed it, so no shadow evidence is owed.

Orders flow

4 Verified · measured

52.0%

Orders land as EO/EC SalesOrders. The gap is release, not intake: 18 On-Hold orders worth [figure withheld].

Connector shadow comparison

3 Built · measured

36.0%

Runs every 6h but compared 151 SKUs of 5,650 and reported healthy. A shadow whose sample is frozen and whose check cannot fail is not a shadow.

Customers flow

1 Scoped · judged

3.2%

CRM entities are 403 to ROAPI, so the flow cannot even be measured. · BLOCKED: Contact, Lead, Opportunity, BusinessAccount all HTTP 403 -- needs an Acumatica role grant

Customer onboarding

Customer onboarding and licence verification

1 Scoped · judged

4.0%

Licence-check state rules and facility M2M model specified. facility_license and licensed_facility DocTypes exist.

DSCSA

Lot / serial model

2 Designed · measured

20.0%

Acumatica overloads one field, LotSerialNbr, on all five endpoints checked. Model keeps lot and serial distinct and refuses to guess.

EPCIS 2.0 / ePedigree

1 Scoped · judged

5.6%

Event templates specified in the local snapshot. epcis_event DocType exists. Nothing connected.

EDI

Supplier EDI / AS2 transport

3 Built · judged

28.0%

ppd_edi covers parsing and intake. Transport needs certificates and SFTP keys, which is a different problem from user SSO. The EdiFabric licence concern is closed -- we are not reusing .NET code.

Migration tooling

Usage layer -- what is used vs merely built

3 Built · measured

27.0%

v1 measures Generic Inquiries. 43 of 78 are unauthorised to ROAPI, so 55% of the reporting surface is invisible. Table row counts, site-map presence and automation last-fired are all unreachable: every system entity 404s on contract REST. · STAGE CLAIM UNSUPPORTED: claims Built with no passing tests (found 0)

Pricing

Price engine and gates

6 Live · measured

100.0%

Ceiling and corroboration gates repaired 2026-08-24; 34 of 57 breaches now refuse rather than report. · STAGE CLAIM UNSUPPORTED: claims Shadowed with no stored diff; claims Shadowed with no denominator -- 151 of 5,650 read as healthy once; claims Shadowed with no demonstrated failure mode · DUAL OWNERSHIP: live, and the incumbent is still running

Elasticity optimiser

1 Scoped · measured

8.0%

Scoped and then correctly stopped: elasticity is UNIDENTIFIABLE here because cost fails the exclusion restriction. More data will not fix it. Margin dispersion and break-even replace it. Not a stall -- a closed question.

Recalls

Recall alerting and matcher

4 Verified · judged

50.0%

Alert path proven end-to-end. The matcher read the wrong field and would never have fired on a real recall -- fixed, but lot capture is still blocked, so it cannot be fully verified. · BLOCKED: DCAA lot field is on no REST endpoint ROAPI can reach, so serial-tracked lines are undetermined against a recalled lot

Supplier recall feed coverage

3 Built · measured

26.0%

1 of ~71 suppliers notifies. The path works; the coverage does not.

Training

Training LMS (training.propharmausa.com)

6 Live · measured

100.0%

Live and genuinely populated: 85 published ProPharma courses -- New Rep Sales Onboarding, Advanced Sales Mastery, Industry Deep-Dive Library, Advanced Objection Handling & Buyer Psychology, Remote Work Success. Frappe LMS, browser-confirmed. Unlike the ERP this holds real ProPharma content, which makes it the one place where clicking into a list rewards the click.

Unified build

ERPNext platform and SSO

4 Verified · measured

50.0%

PLATFORM ONLY -- this says nothing about data. ERPNext v16.31.1 on frappe_docker, 10 containers up, Caddy TLS, and Office 365 SSO proven: a Microsoft identity is linked and mark@propharmausa.com signed in 2026-08-10 08:00:54. Structure is real too -- 296 custom fields, 13 ppd_unified doctypes, 6 curated workspaces whose shortcuts all resolve. But 17 workspaces are header-only blank pages and the instance holds no ProPharma data at all.

ppd_capture -- Acumatica capture

4 Verified · measured

48.0%

Capture proven against live Acumatica read-only. 17 of 27 contract entities readable; 9 unreadable and visible as UNKNOWN. · STAGE CLAIM UNSUPPORTED: claims Built with no passing tests (found 0)

ppd_edi -- X12 850/856 and AS2

3 Built · measured

40.0%

Real implementations, no stubs. Never run against a real trading partner, so Built and not Verified.

ppd_csos -- CSOS / DEA 222

3 Built · measured

36.0%

Offline-guarded. Nothing connected to DEA.

ppd_core -- data model and DocTypes

3 Built · measured

32.0%

15 DocType implementations against 176 doctype SPECS. The 176 is the number that misleads: it counts spec files, not implementations. · STAGE CLAIM UNSUPPORTED: claims Built with no passing tests (found 0)

ppd_arcos -- ARCOS reporting

3 Built · judged

30.0%

Format, collect and exporter exist; no tests found, so the fraction is a judgement rather than a measurement. · STAGE CLAIM UNSUPPORTED: claims Built with no passing tests (found 0)

ppd_migration -- Acumatica to ERPNext migration

3 Built · measured

25.0%

Migrated ZERO ProPharma rows. The 2026-08-25 reconciliation returned 26 entities: 0 MATCH, 9 SCHEMA_INVALID, 9 EMPTY_TARGET, 8 GAP. Every populated table in the ERP is ERPNext test fixtures -- Account 2,126 all named _Test* with no account number, Item 29 including Macbook Pro and Photocopier, Supplier 10 of 10 fixtures. Row counts looked like progress; reading the rows showed otherwise. · BLOCKED: 9 of 26 field mappings name Acumatica fields that do not exist; 4 of those 9 are CRM entities that are 403 to ROAPI, so their mappings cannot even be repaired until a role grant lands

Order-request portal (BigCommerce replacement)

2 Designed · judged

15.2%

order_request and order_request_item DocTypes exist; entitlement and approval-workflow specs written. No payments by design.

CRM (HubSpot replacement)

1 Scoped · judged

2.4%

Migration and dedup mapping specified. No component chosen -- Frappe ships a native CRM. An HSIntegration Acumatica endpoint exists and is unexplored.

Architecture decision: Frappe vs bespoke FastAPI

0 Proposed · measured

TWO architectures in the repo, neither retired. main is a metadata-driven FastAPI/React ERP; unified-build/* adds the Frappe app. Only Frappe was ever stood up. Everything downstream depends on this and it is undecided.

Read this before quoting the mean

6 of 25 components carry a stage claim their evidence does not support, and they are shown above with the reason rather than rounded away. The mean of 37.5% includes them at face value, so it is an over-statement, not an under-statement. The honest reading is: this programme has a lot built and comparatively little verified.

Generated by ppd-unified-portal. Content is surfaced from its source repositories and never edited here — see For machines for the fetchable representation.