XJDF Master Data Model

NowToPrint keeps master data as the single source of truth and exposes it through XJDF-native contracts. The platform does not treat XJDF as a loose export format. It uses XJDF 2.2 semantics to define how media, devices, sourcing and job snapshots are structured end to end.

---

The five-layer model

Every major master-data family follows the same layered model:

Layer	Purpose	Example
generic class	Neutral technical definition	70x100 4-color sheetfed offset
branded product	Market-facing product identity	Sappi Magno Satin 130 gsm 70x100
supplier/source	Commercial and supply truth	supplier, MOQ, lead time, validity window
organization override / installed asset	Tenant-specific reality	local machine options, local media price, local constraints
job snapshot	Immutable execution truth	exact source, unit, compatibility decision and assumptions used for the quote/order

This model is what lets /admin publish canonical truth and /dashboard apply controlled overrides without forking the shared taxonomy.

---

Supplier intake and approval gate

Supplier- or partner-originated catalog data never writes directly into canonical master data.

• POST /api/b2b/suppliers/catalog stages the submission in supplier_catalog_intake with a pending_review status
• a platform admin or data steward reviews staged submissions through GET /api/admin/master-data/supplier-catalog-intake
• the admin review queue can switch across pending_review, approved, rejected and all statuses without leaving the master-data surface
• the same queue supports steward-side text search across supplier identity, SKU data and recent review notes
• the admin review panel can prefill low-risk generic media suggestions from branded paper names to speed up stewardship
• suggested generic mappings now expose a lightweight confidence signal so stewards can distinguish safer autofill cases from manual review cases
• pending submissions are now enriched server-side with duplicate candidates from the canonical supplier_catalogs projection and active branded media master data, plus a duplicateSummary risk signal that highlights blocking canonical matches and total candidate count before publishing
• the same intake list response now returns a lightweight queue summary so the review panel header can highlight high-risk pending, duplicate-reviewed approval, and duplicate reject counts at a glance
• the review queue now also supports a Duplicate risk filter backed by GET /api/admin/master-data/supplier-catalog-intake?duplicateRisk=high|review_needed, so stewards can jump straight to the riskiest pending duplicate cases
• the same queue now also supports an SLA status filter backed by GET /api/admin/master-data/supplier-catalog-intake?sla=breached, so overdue pending reviews can be isolated without leaving the master-data surface
• GET /api/admin/master-data/supplier-catalog-intake/analytics now exposes a separate stewardship analytics snapshot with duplicate review outcome counts and structured rejection reason counts
• the admin master-data surface now includes a dedicated supplier stewardship analytics card so teams can monitor publish/reject patterns outside the live queue
• the stewardship analytics route and card now support an Activity window filter (All time, Last 30 days, Last 7 days) driven by the latest submission activity timestamp
• the same stewardship analytics snapshot now highlights pending queue aging buckets plus SLA breached and high-risk SLA breach signals for overdue review work
• the analytics card now also surfaces Pending ownership and Steward activity sections, using assignment metadata and reviewDecision.reviewedBy to show unassigned backlog and recent reviewer workload
• the same analytics snapshot now also computes leading pattern summaries for duplicate review resolutions and rejection reasons, and the card surfaces those leaders as percentage chips for faster steward pattern recognition
• the analytics card now also includes a Focus high-risk queue action that pushes an in-page focus signal back into the live review queue, so stewards can jump straight into the blocking duplicate backlog
• the same analytics action bar now also exposes Focus overdue high-risk, combining duplicate-risk and SLA-breach signals into a single overdue triage shortcut
• the same analytics action bar now also exposes Focus duplicate: ... and Focus rejection: ... shortcuts, which open approved or rejected review history with the matching decision pattern prefilled into the queue search
• the Pending ownership section now also exposes Focus pending: ... shortcuts so stewards can jump from workload counts straight into the matching assigned or unassigned queue slice
• the same Pending ownership breakdown now also computes steward-level overdue high-risk intersections and exposes Focus overdue: ... shortcuts for the matching owner or unassigned backlog
• once the review queue is focused to unassigned + high-risk + overdue, the panel now also exposes a one-click Claim shown overdue high-risk action that assigns the visible backlog to the current steward through the existing bulk-assignment route
• the same overdue triage strip now also works with the Bulk steward selector; Assign shown overdue high-risk can redirect the visible backlog to a chosen steward without manually selecting each submission
• the stewardship analytics snapshot now also emits both Suggested overdue steward and Fallback overdue steward signals; each suggestion carries a window-aware confidence level, a short rationale summary, compact recommendationSignals such as Lowest overdue load or High recent review throughput, a windowTrend summary comparing the selected window against the previous equal window, and an assignmentRecommendation layer (Safe to auto-assign, Prefer manual check, Escalation needed) with concise reasons so the card can explain not just who is recommended, but how safely the backlog should be routed right now
• when the analytics card prepares an overdue assignment target, the review queue now consumes that recommendation payload directly: it prefills the Bulk steward, shows a queue-side guidance alert, and if the recommendation is Escalation needed, it blocks overdue bulk assignment until a steward explicitly acknowledges the escalation reasons
• the same recommendation contract is now enforced server-side in both POST /api/admin/master-data/supplier-catalog-intake/assign and POST /api/admin/master-data/supplier-catalog-intake/bulk-assign: the selected steward must match the recommended steward, escalation_needed assignments require escalationAcknowledged, and accepted actions persist an assignmentRecommendationDecision audit object
• the stewardship analytics route now also rolls up that audit trail into assignmentRecommendationCounts, source breakdowns, acknowledged-escalation totals, and Leading assignment: ... patterns; the analytics card surfaces those outcome signals and can focus the queue by assignment recommendation label
• the review queue now renders the same audit object back on each submission as Assignment guidance, Assignment reasons, Assigned by ... at ..., and when present Escalation acknowledged at ..., so recommendation-driven assignment context stays visible in both pending and history views
• the Steward activity section now also exposes Focus activity: ... shortcuts, opening review history with the selected reviewer id prefilled into queue search
• the review queue now supports Assign to me and Unassign actions through POST /api/admin/master-data/supplier-catalog-intake/assign, keeping assignment state in the same master-data review model
• the same assignment route now also supports steward-to-steward reassignment with assignedToUserId, and the review panel can target another active admin steward from the platform user directory
• the admin review panel now also supports bulk triage through POST /api/admin/master-data/supplier-catalog-intake/bulk-assign, including Bulk assign to me, steward-targeted bulk assignment, and Bulk unassign selected
• the same queue now supports an Assignment filter powered by GET /api/admin/master-data/supplier-catalog-intake?assignment=mine|unassigned|assigned, so stewards can jump between personal, unassigned, and already-owned backlog views
• high-risk duplicate matches now require an explicit steward duplicate review decision and note before POST /api/admin/master-data/supplier-catalog-intake/approve can publish the submission
• the canonical publish boundary now runs canPublishCanonicalMasterData() before any transaction starts; roles outside full platform admin, master_data_steward, or standards_steward receive MASTER_DATA_PUBLISH_FORBIDDEN
• critical Master Data categories outside supplier catalog now share the master_data_publication_history contract; generic media, branded variants, generic-branded mappings, standards registry and standard mappings can use the same immutable history language
• the review panel now offers quick actions such as Mark as supplier-specific and Reject as duplicate so stewards can prefill the most common duplicate review outcomes
• when multiple high-risk duplicate submissions are selected, the same panel now also offers Bulk mark supplier-specific and Bulk reject as duplicate templates so duplicate-heavy backlog can be triaged without repeating the same draft text per item
• the same bulk triage bar now includes Select shown high-risk duplicates, letting stewards target only the visible blocking duplicate cases before applying duplicate templates
• if a steward wants to undo those draft presets before final review, the same bulk triage bar now also exposes Clear selected duplicate templates for the selected high-risk duplicate records
• approved and rejected history cards now surface the duplicate review resolution or structured rejection reason so recent steward decisions stay legible in the same queue
• stewards can attach an optional publish note during approval so the canonical publication keeps an audit trail
• every Paper item must be linked to a canonical generic media class during review
• only submissions with completed mappings are published into the canonical supplier_catalogs projection through POST /api/admin/master-data/supplier-catalog-intake/approve
• the same approval now also writes an immutable snapshot into supplier_catalog_publications, so canonical supplier publish lineage survives future overwrites of the mutable projection
• the admin master-data surface now includes a dedicated Canonical supplier publication history card backed by GET /api/admin/master-data/supplier-catalog-publications, exposing recent publish snapshots with version, source intake id, mapping status and duplicate review context
• the same publication history route now also enriches each visible snapshot with a previousPublication pointer and diffSummary fields such as addedSkuCount, removedSkuCount, mappingStatusChanged, and duplicateRiskChanged
• the publication history card renders that delta directly, so stewards can see how the latest canonical publish differs from the previous supplier snapshot without leaving admin master-data
• the same publication history response now also includes skuDiff.addedSkus, skuDiff.removedSkus, and stateDiff before/after values for mapping status and duplicate risk; the history card exposes those exact deltas behind an expandable Show SKU diff control
• the same route now also emits a rollbackReadiness signal with ready, manual_review_required, or not_available semantics plus short reasons, so the history card can explain whether restoring the previous canonical snapshot is low-risk or needs steward review first
• the publication history card now also exposes rollback-focused filters backed by GET /api/admin/master-data/supplier-catalog-publications?rollback=..., so stewards can isolate only Manual review required, Ready, or No rollback base snapshots without leaving admin master-data
• the same publication history response now also includes summary.totalItems and summary.rollbackCounts, and the card uses those counters to label each rollback filter while also supporting Search supplier or SKU via the q= query contract
• the same summary payload now also includes summary.supplierCounts, and the card turns that into Quick supplier focus actions that keep the visible search text but apply an exact supplierId filter under the hood
• the publication history route now also accepts latestOnly=true, and the card exposes that as a Latest per supplier toggle so stewards can switch between full lineage and one-current-snapshot-per-supplier overview
• the same route now also supports windowDays=7|30|90, and the card exposes those moving recency windows as All time, Last 7 days, Last 30 days, and Last 90 days filters
• the publication history route now also supports changedOnly=true, and the card exposes that as a Changed only toggle fed by summary.changeCounts.changed so stewards can isolate only materially changed publishes
• the same publication history route now also supports attentionOnly=true, and the card exposes that as a Needs attention toggle fed by summary.attentionCounts.needsAttention so stewards can isolate only changed publishes that still require manual rollback review
• the same summary payload now also includes summary.attentionSupplierCounts, and the card turns that into Quick attention focus actions that apply the supplier's exact supplierId plus attentionOnly=true so risky changed publishes stay scoped to the intended supplier
• rejected submissions must include both a structured rejectionReasonCode and a steward note through POST /api/admin/master-data/supplier-catalog-intake/reject
• each approval or rejection now records a reviewDecision audit object with actor, timestamp and note
• approved or rejected submissions can be revisited in the same queue so stewards can inspect recent audit decisions
• procurement and other consumer-facing surfaces continue to read only the approved canonical projection

This review gate prevents supplier-side or tenant-side submissions from bypassing platform governance and mutating branded product or source truth directly.

---

Core master-data families

Media

Media records are not stored as a flat paper list anymore. A complete media chain contains:

• generic media type
• branded media
• supplier/source validity
• organization override
• job-time resolved snapshot

Important attributes include:

• dimensions and available stock sizes
• weight and coating
• XJDF product identifiers
• reference price and raw price unit
• supplier availability, MOQ and lead time

Devices

Device truth is split between:

• generic device capability
• installed machine truth for each organization
• routing and costing snapshots at job time

Installed asset truth is now part of production decisions. Routing and costing are expected to look at the same real machine, not just the same machine family.

Finishing and consumables

Bindings, lamination, varnish, plates, labor and utilities follow the same canonical direction:

• canonical taxonomy in admin
• organization override where business reality differs
• immutable snapshot in quote/order/production

Operation intent split

Cutting and hole making are separate Platform Master Data truths. Cutting records are published to master_data_cuttings and describe cutting intent semantics. Hole punching, drilling, perforation, and similar delgi processes are published to master_data_hole_makings and carry HoleMakingIntent. Do not model hole making as a cutting subtype in RFQ, admin, catalog projection, XJDF export, or production planning.

---

Compatibility matrix

The media-device compatibility matrix is a first-class part of the model.

It answers questions such as:

• can this substrate run on this specific press?
• is the match native, conditional or unsupported?
• which rule and notes justify the decision?

Compatibility is no longer a hidden advisory hint. It feeds:

• quote confidence
• routing decisions
• manual review gates
• operator review queue items

---

Supplier validity and inventory truth

Supplier/source records are used to decide whether a media option is commercially usable right now.

The platform tracks sourcing truth such as:

• available stock
• required quantity
• minimum order quantity
• lead time
• price validity window
• source status such as active, discontinued or not-yet-valid

If the system cannot prove that the source is usable, it must downgrade confidence or require manual review instead of pretending the quote is final. Generic-only sources, zero/reference prices, expired prices, and quality holds cannot advance into ERP posting or production-ready status. When the inventory lot lacks reservation and ERP movement evidence, the row stays source-ready and the steward action is attach_inventory_lot.

---

Job snapshot discipline

Quotes and orders must carry the truth that was used at the time of calculation.

At snapshot time the platform preserves:

• resolved media and brand ids
• resolved supplier/source ids
• resolved machine or installed asset ids
• raw price unit and normalized price unit
• compatibility decision and notes
• manual review reasons
• imposition assumptions and waste plan
• costing resolver sources (source, sourceId, name)
• resolvedMasterDataSnapshot.hash and resolutionTrace
• the resolvedMasterDataSnapshot reference in XJDF export metadata
• the ResolvedMasterDataSnapshot reference in the PrintTalk Header
• the GatewayMessage.metadata.resolvedMasterDataSnapshot reference in ERP/MIS gateway messages

This is what makes pricing disputes, audits and production parity manageable later. Production handoff APIs now make this discipline mandatory instead of optional metadata: the generic XJDF build() method remains available for document preparation, but production export must call buildProductionHandoff(). PrintTalk and ERP exports treat a missing resolved snapshot as a P0 blocking error.

---

2026 Master Data SSOT reference

The 2026 analysis clarifies that XJDF, XJMF, PrintTalk, ICC, ISO, GWG, GS1 and FSC/PEFC do not replace platform master data. They define the lower standards layer that constrains terminology, validation rules, mappings and integration contracts.

Accepted model:

• Standards Registry: external standards, versions, terms and validation rules
• Platform Master Data: generic classes, branded product lines, branded variants/SKUs, supplier/source records, devices, compatibility, color profiles, processes and catalog specs
• Tenant Overlay: organization preference, negotiated prices, installed assets, inventory and customer-specific policies
• Resolved Snapshot: immutable RFQ, quote, order, job ticket, XJDF package, PrintTalk exchange and ERP posting truth
• Catalog Projection: commercial SEO/RFQ facade; not the technical SSOT

Generic-to-branded relationships are not stored as a single genericId field. Generic media publish records use CanonicalGenericMediaSchema, and branded product line and variant publish records use the shared Master Data envelope through CanonicalBrandedMediaProductLineSchema / CanonicalBrandedMediaVariantSchema; supplier/source truth is tracked in the same history line through CanonicalSupplierSchema / CanonicalMediaSourceSchema. Variant/SKU records are linked to generic classes through the governed CanonicalGenericBrandedMappingSchema graph with confidence, mapping type, provenance, standard refs and steward approval. The M5 graph guard now emits deterministic brandedVariantRef and proof refs for every positive mapping; a generic-only edge cannot become production_ready, and incompatible negative knowledge cannot be returned as a positive resolver alternative. The M6 source bridge completes that graph with supplier price, freshness, reservation, ERP movement, and lot releasability evidence; mappings without source and lot proof are not production-ready.

Catalog projection records use the CatalogProjectionItem contract and must carry Master Data refs: masterProductRef, genericSpecRefs, allowedOptionRefs, projectionVersion, and sourceMasterDataPublishedVersion. validateCatalogProjectionItem() returns errors for missing refs and a stale signal when the current Master Data version has moved; assertCatalogProjectionPublishable() blocks publishing projections with missing refs. media-spec-registry sources are also projected through buildMediaSpecMasterDataRef() and buildMediaSpecMasterDataRefs() into master_data_generic_media source refs. On the RFQ side, resolveRfqCatalogOptionRefs() prefers published allowedOptionRefs; when projection refs are absent it converts legacy allowed media IDs into Master Data refs and rejects unknown IDs. Production calls must pass environment: 'production'; in that mode missing projection refs are blocked with MASTER_DATA_PRODUCTION_BASELINE_FALLBACK_FORBIDDEN.

On the admin cockpit side, quality-score.ts normalizes category-level Master Data quality/compliance signals into one KPI language: standards coverage, mapping coverage, supplier freshness, duplicate risk, stale projection and RFQ auto-resolve. GET /api/admin/master-data/stats returns that dashboard as stats.quality, and MasterDataQualityPanel surfaces the same signal on admin/master-data as the overall score plus the weakest categories.

Quality panel category cards now carry a visible status label next to the score. Stewards do not need to infer risk/watch/healthy state from color or icon alone.

Canonical lifecycle language is also shared through MasterDataWorkflowStage: draft, validate, match, steward_review, publish, and monitor. MASTER_DATA_WORKFLOW_TRANSITIONS plus assertMasterDataWorkflowTransition() block unsafe skips before steward review/publish, while MasterDataLifecycleSchema carries the same trace as workflowStage and lastWorkflowTransitionAt.

The publication history pattern now extends beyond supplier catalog. publication-history.ts defines source collection, publication collection, criticality and deterministic publication id generation for every critical category; supplier catalog keeps the existing supplier_catalog_publications collection, while other critical categories use the shared master_data_publication_history line.

Admin supplier/source create flows write to canonical collections and generate XJDF namespaces as ntp:supplier:* / ntp:media_source:*. ntp:unknown:* is not accepted for supplier/source truth, and the service test locks that namespace contract under master-data:ssot:guard.

Legacy papers and media-types category names are no longer public/admin API inputs. Canonical write endpoints reject those names with MASTER_DATA_LEGACY_CATEGORY_WRITE_FORBIDDEN and point callers to generic-media, branded-media, and media-sources. XJDF GenericPaperModel, SpecificPaperModel, GenericMachineModel, and SpecificMachineModel shallow models are marked deprecated_adapter_only; new code should use Platform Master Data plus tenant overlay boundaries.

XJDF organization-scoped paths are treated as overlay context only. The canonical read/publish target is the Platform Master Data collection; organization data represents preference, inventory, installed-device, or negotiated-rate overlay data.

The M1 layer contract guard now blocks retired root collection usage, migration-only mapping paths, typo aliases, local static truth, generic-only media, AI-generated truth, and legacy seed terminology inside XJDF/ERP consumer files through master-data:ssot:guard. The ERP gateway is not considered final business truth unless it has both resolved_snapshot and inventory_lot evidence.

New Master Data model checklist

Before adding a new canonical Master Data family, the admin/master-data surface should make these decisions explicit:

• canonical category name, collection constant and legacy alias/migration policy when needed
• MasterDataSchemaEnvelopePolicy entry in schema-adoption.ts when the category participates in critical publication history
• required shared envelope fields through createCanonicalMasterDataSchema() or defineCanonicalMasterDataSchema(): canonicalCode, schemaVersion, standardRefs, source/provenance, lifecycle, governance, quality and audit
• the first adoption examples: CanonicalGenericMediaSchema, CanonicalGenericBrandedMappingSchema, CanonicalBrandedMediaProductLineSchema, CanonicalBrandedMediaVariantSchema, CanonicalSupplierSchema, CanonicalMediaSourceSchema, and the split from legacy schemas
• how standards compliance is represented through Standards Registry refs
• where generic, branded, supplier/source and tenant overlay boundaries sit
• whether a critical category uses master_data_publication_history or category-specific immutable history
• impact on ResolvedMasterDataSnapshot for RFQ, quoting, costing, production, XJDF, PrintTalk or ERP
• CatalogProjectionItem refs and stale detection contract when the model appears in RFQ/SEO catalog flows
• which KPI represents the model in admin/master-data stats and quality-score.ts
• how publish is protected by canPublishCanonicalMasterData() and the steward workflow
• schema, category alias, write guard, publication history, snapshot/export, canonical-envelope-guard.test.ts and master-data:ssot:guard tests

Living project references:

• docs/MASTER_DATA_SSOT_2026_RAPORU.md
• docs/strategy/NOWTOPRINT_MASTER_DATA_SSOT_UYGULAMA_PLANI_2026_TR.md
• docs/help/MASTER_DATA_SSOT_REFERANS_REHBERI.md
• docs/guides/MEMBER_COMPANY_MASTER_DATA_ADOPTION_GUIDE_EN.md

---

Member company adoption

Member companies use platform master data in three modes:

1. Direct use — consume canonical data as-is (default for new members)
2. Tenant overlay — preserve canonical truth and layer company-specific pricing, stock, supplier preference or installed assets on top
3. Local capability — register equipment or materials that do not exist in the platform catalog without mutating canonical records

The overlay layer may override prices, stock signals, supplier preferences and installed assets. It may not override canonical technical specifications such as gsm, caliper or ISO grade. When an overlay goes stale or conflicts with a canonical update the tenant-overlay-conflict.ts policy triggers a warning or block depending on severity.

At quote or order finalization the platform merges canonical master data with the tenant overlay into an immutable resolved snapshot. This snapshot preserves the exact data version used at decision time and does not drift when platform data changes afterward.

For the full onboarding steps and FAQ see docs/guides/MEMBER_COMPANY_MASTER_DATA_ADOPTION_GUIDE_EN.md.

---

Where to use this guide

Use this page when you are:

• integrating XJDF master-data export/import
• designing admin or dashboard override behavior
• mapping external ERP/MIS data to NowToPrint
• reviewing snapshot and audit semantics

Use the other guides below when you need surface-specific details.

Network snapshot update

For XJDF and PrintTalk integrations, external network readiness does not change the execution rule: jobs must use immutable resolved snapshots. Catalog Projection may help discovery and RFQ context, but export payloads must preserve canonical snapshot references and must not read private supplier pricing or evidence from public DTOs.