Scenarios, capabilities, and boundaries

Scenarios

Golden is most useful when several systems describe the same business subject and an organization needs a controlled, reusable view of that subject.

Customer master data

Bring customer records from operational systems into a common schema, identify potential duplicates, review uncertain matches, and deliver mastered customer records to downstream applications.

Use this scenario when duplicate identities affect service, reporting, compliance, or communication. Golden complements source systems; it does not replace every system that owns a customer process.

Product or reference data

Create a searchable, governed collection for products, suppliers, locations, or another reference domain. This may begin as storage and search, then add resolution when duplicate or conflicting records become material.

Use this scenario when consumers need one consistent lookup surface or shared identifiers across applications.

Batch data integration

Load records from configured sources, apply transformations, run Golden work as an asynchronous task, and export the resulting data to a destination.

Use this scenario for scheduled exchanges or larger data sets where callers must follow task completion rather than wait for one synchronous request.

Real-time lookup and upsert

Applications use the REST API to search an entity or insert and update records. The entity configuration determines how those records become searchable and participate in duplicate resolution.

Use this scenario when an application needs Golden during an interactive or service workflow. The integration must handle authorization, validation, conflicts, and asynchronous indexing behavior where applicable.

Manual duplicate stewardship

Data stewards inspect groups of potential duplicates, compare evidence, and merge, disconnect, or defer a decision. Human review provides control where a policy should not decide automatically.

Use this scenario when false merges carry meaningful business risk or when an organization is still learning which resolution policy fits its data.

The capability map below summarizes Golden and customer responsibilities. Use Golden concepts when the domain vocabulary is not yet familiar.

Capabilities and boundaries

Golden creates a managed context for records about a business subject. An architecture should use its public capabilities deliberately and keep business authority explicit in connected systems and governance processes.

Capability map

What Golden does not decide

Golden cannot infer the organization’s governance model from data alone. In particular, it does not decide:

• which source is authoritative for each field;
• whether two similar records may safely be merged;
• whether a quality warning blocks a business process;
• whether a downstream consumer may tolerate delayed or repeated delivery;
• who may see a data population; or
• how long customer data must be retained.

Those decisions belong in an approved architecture and stewardship policy, then become configuration, access assignments, and operating procedures.

Product boundaries

Golden is not intended to replace:

• the operational workflow in CRM, ERP, commerce, service, or supplier systems;
• an enterprise integration platform for unrelated application orchestration;
• a data warehouse or analytics model;
• a customer identity provider;
• source-system controls that prevent invalid data at entry; or
• customer governance and legal retention decisions.

Golden may become the authoritative mastered view for a defined subject, but that does not make it the authoring system for every contributing fact.

Managed SaaS responsibility boundary

Trazadera operates the Golden service and its internal platform. The customer remains responsible for customer-controlled data, configuration, identities, integration credentials, policy decisions, and use of delivered records.

Architecturally, treat the public web application, REST API, configured data flows, tasks, events, and support interface as the service boundary. Do not couple customer integrations to internal engines, stores, network topology, or undocumented operational behavior.

See the Golden SaaS service model for the customer-facing responsibility split and the supported integration policy for the public compatibility boundary.

Data and access boundary

Golden combines global roles with explicit data grants. A role controls which operations an identity may perform; entity grants determine which entity data it can access. Row grants restrict records through a configured scope column. Naming and navigation are not access controls.

Use roles and permissions to design and test both dimensions. In particular, whole-entity access uses values:null, not an empty list. Quality snapshots remain table-wide aggregates rather than row-filtered metrics. If that aggregate visibility or another service boundary does not meet your isolation requirements, agree a suitable environment design with Trazadera.

For each data flow, record:

• the sending and receiving systems;
• the fields and metadata that cross the boundary;
• the Golden user or token and minimum role;
• encryption and credential-handling requirements;
• task or delivery evidence used to verify completion; and
• the owner of failed, delayed, ambiguous, or repeated work.

Architecture test

A design has a clear Golden boundary when a reviewer can answer all of these without reading implementation code:

1. Which system may originate each kind of change?
2. Which Golden capability processes it?
3. Which interface and identity cross the boundary?
4. When is the result considered complete?
5. Which system receives the mastered result?
6. Who reconciles a conflict or uncertain outcome?

Continue with the logical component model.