Review a Golden solution design

Use this checklist during architecture review and before enabling a production Golden flow. Record decisions in the customer’s normal architecture and change governance system; this page is not itself an approval record.

Outcome and scope

• The business subject and expected mastered outcome are named.
• Golden’s responsibility is separated from source applications, integration platforms, analytics, and governance processes.
• The chosen entity capability—storage, search, duplicate resolution, or automatic stewardship—matches the outcome.
• Out-of-scope subjects, sources, fields, and consumers are explicit.

Data contract and quality

• Dataset fields, types, identities, validation, and empty-value behavior have business owners.
• Error policy is defined for invalid values rather than inherited by accident.
• Transformations and pipelines are tested with representative, non-sensitive edge cases.
• Quality facts lead to a defined source-remediation or stewardship process.
• No consumer treats the quality score as a universal trust measure.

Identity, authority, and mastering

• Source identifiers are stable and distinct from Golden and business identifiers.
• Authoritative sources and survivorship intent are defined per important field.
• False-merge and missed-match risks are assessed.
• Human-review boundaries, comments, escalation, and automation thresholds are approved.
• Consumers can reconcile a merged record to its surviving identifier.

Integration behavior

• Every flow has a selected public interface and dedicated identity.
• Expected volume, latency, cadence, and data minimization are recorded.
• Synchronous callers define timeout and fail-open, fail-closed, or review behavior.
• Batch callers follow tasks instead of assuming the start request completed the work.
• Write callers reconcile ambiguous outcomes before retrying.
• Destination consumers define stable identity and safe redelivery behavior.

Security and SaaS boundary

• Users and tokens have the least built-in role required.
• Entity grants and row scopes are tested for each user and integration.
• Table-wide aggregate visibility fits the required data boundary.
• Credentials are stored, rotated, disabled, and retired through approved processes.
• Sensitive record content and credentials are excluded from ordinary logs and support requests.
• Customer and Trazadera responsibilities follow the SaaS service model.

Operations and evidence

• Owners can distinguish request acceptance, task completion, searchable state, and downstream delivery.
• Task, event, metric, audit, history, and trace evidence are used only for their documented scopes.
• Schedules have an owner and overlapping or duplicate execution is controlled.
• Alerts and reviews use supported customer-visible signals.
• The escalation package includes identifiers, time, status, and trace evidence without unnecessary customer data.

Recovery and change

• Procedures exist for failed load, failed indexing, invalid destination event, and ambiguous timeout.
• Procedures exist for incorrect merge, disconnect, ignore, and deletion.
• Configuration dependencies are reviewed before changing or removing a resource.
• The design has been tested in the approved non-production environment.
• A rollback, corrective action, or Trazadera escalation path is known before production enablement.

Review outcome

An architecture is ready to proceed when each unmet item has an owner and an explicitly accepted treatment. A successful API call or sample load is useful evidence, but it is not a substitute for authority, recovery, and operational decisions.

Continue with Administer Golden, Develop with Golden, or the Work with data guide.