System-of-Record Ownership for Core Commerce Data

Welcome back. Last lesson traced a cart update through the Integration API and Rule Engine: your commerce system submits authoritative current context, Talon.One evaluates the configured campaign logic, and returns effects that the integration must apply and reconcile.

This lesson makes the ownership boundary explicit. You will assign a system of record for four data areas—customer, cart, promotion, and fulfillment—and distinguish three things that are often mistakenly collapsed into one: the system that owns a fact, the system that makes a promotional decision from that fact, and the system that executes the resulting business action.

By the end, you should be able to defend an ownership model in which Talon.One is a decisioning and promotion-state platform, without turning it into an accidental replacement for your customer, commerce, order-management, or fulfillment systems.

---

Ownership is more than “where data is stored”

A system of record (SoR) is the system authorized to establish and change a business fact. It is the place other systems ultimately defer to when there is disagreement.

Simply copying data into Talon.One does not make Talon.One the system of record for that data. Likewise, receiving a Talon.One effect does not make Talon.One responsible for executing the downstream action.

For a sound architecture, separate four roles:

Role	Question it answers	Example
Source authority	Who establishes the underlying fact?	The commerce platform establishes cart quantities and base prices.
Decision authority	Who determines promotion eligibility and rewards?	Talon.One evaluates campaign rules and returns discount effects.
Execution authority	Who performs the business action?	The checkout service applies a discount; the warehouse ships a gift.
Audit authority	Who retains the durable record of the completed commercial transaction?	The order-management and finance systems retain the order, payment, taxes, and applied adjustments.

A single business journey involves all four roles. The architecture becomes fragile when a single system is assumed to own all of them.

For example, Talon.One may determine that a customer qualifies for a free item, but it does not reserve warehouse inventory, create a pick ticket, calculate shipping eligibility under carrier rules, or confirm delivery. Its decision must be handed to the systems that own those responsibilities.

---

The Talon.One boundary: session data is submitted context, not your commerce master

A Talon.One customer session is a finite container for a commercial interaction, such as a cart or transaction. It is deliberately identified by an integration-controlled ID, rather than an ID Talon.One creates for your business.

This has an important implication:

Talon.One owns the representation and promotion consequences of the customer session within Talon.One. Your commerce and order systems remain authoritative for the actual cart and transaction that the session represents.

For an open cart, your integration sends Talon.One the current relevant facts: items, quantities, base prices, customer association, coupon codes, channel, delivery facts, and any other attributes used in campaign rules. Talon.One evaluates that supplied context. It does not discover the cart independently, nor should it become the master copy from which a storefront reconstructs a customer’s cart.

The same principle applies to session state. The external order workflow determines that payment failed, a refund was approved, or a return was received. Your integration then updates the Talon.One session so Talon.One can apply its promotion-side consequences, such as rollback effects and budget adjustments.

---

A practical ownership model

The following is a strong default model for a Talon.One implementation. It can be adapted, but deviations should be intentional and documented.

Domain data	Recommended system of record	Talon.One’s role	Key integration rule
Customer identity, consent, contact details	Identity platform, CRM, or customer-data platform	Promotion-relevant profile copy	Synchronize only facts needed for decisioning; do not treat Talon.One as the identity master.
Cart contents, base prices, tax inputs, shipping selection	Commerce cart and pricing services	Customer-session context for evaluation	Send current, undiscounted commercial facts used by rules.
Order, payment, invoice, tax, refund	Order-management, payment, and finance systems	Promotion session state and promotional rollback processing	Persist applied effects with the order; Talon.One does not replace financial records.
Campaign definitions, rule logic, campaign budgets	Talon.One	Authoritative promotion configuration and evaluation	Do not duplicate campaign conditions in storefront or checkout code.
Coupon, referral, giveaway, loyalty transaction state, when Talon.One features are used	Talon.One	Authoritative state for that Talon.One mechanism	Use Talon.One identifiers and lifecycle effects when displaying or reconciling these mechanisms externally.
Product catalog facts and inventory	PIM, product catalog, inventory systems	Rule inputs, filters, and catalog projections where configured	Talon.One should not become the enterprise product or inventory master.
Fulfillment, shipment, returns, delivery status	OMS, WMS, logistics, or service systems	Receives rule outcomes; reacts to external lifecycle updates	Treat promotion effects as instructions or entitlements, not fulfillment confirmation.

Two details deserve emphasis.

First, base price and promotional adjustment are different records. Commerce or pricing owns the base commercial price. Talon.One decides the promotional adjustment, such as a discount amount. The commerce order should persist both, along with the campaign or effect identity needed for audit and customer-service investigation.

Second, an ownership model does not mean that one system never stores another system’s information. Talon.One can store a customer profile, cart items, and session data. An OMS can store campaign labels and discounts. The question is: which system is allowed to decide that the value is true and change it?

---

Customer ownership: identity master versus promotion profile

The customer domain is usually the first area where accidental dual ownership appears.

A customer profile in Talon.One supports promotion evaluation. It can include facts such as market, enrollment status, customer tenure, tier, preferred store, or an externally calculated segment. But the authoritative customer identity generally remains elsewhere:

• An identity provider owns authentication credentials and login identity.
• A CRM or customer-data platform commonly owns contact information, consent, and customer-master attributes.
• An ERP or commerce account service may own account status, tax classification, and business-account relationships.
• Talon.One owns the promotion-relevant profile state that it creates and manages, including Talon.One-managed audiences, loyalty balances, and campaign-driven promotion entities where those features are enabled.

Use a stable external customer ID as Talon.One’s profile integration ID. The integration ID should identify the same customer across systems; it should not be an email address, mutable username, or presentation-layer identifier.

Attribute ownership must be explicit

For every profile field used in a campaign, classify it before creating it:

Attribute	Likely owner	How Talon.One receives or changes it
market	Customer master or commerce account service	Backend sync or session/profile update
consentForMarketing	Consent-management system	Controlled sync; never campaign-side overwrite
membershipTier	Depends on program design	Talon.One if tiers are Talon.One loyalty tiers; otherwise external sync
lifetimeSpend	Finance or customer analytics platform	External calculated value, unless deliberately modeled through Talon.One loyalty mechanisms
firstPurchaseDate	OMS or customer analytics	External sync
promotionPreference	Product decision	Explicitly designate one owner before allowing updates

Avoid a vague label such as “jointly owned.” In practice, that often means two systems can overwrite each other with no conflict rule. If a value must exist in both places, define:

1. the authoritative writer;
2. the synchronization direction;
3. update triggers and latency expectations;
4. behavior for unavailable or stale data; and
5. whether Talon.One rule effects are allowed to request a change in the external system.

For instance, an updateAttribute effect can tell an integration that a Talon.One rule changed an attribute. That does not automatically authorize the integration to overwrite the enterprise customer master. If you want a campaign to change a CRM field, treat it as a deliberate domain integration with validation, authorization, audit records, and idempotent processing.

---

Cart and order ownership: Talon.One evaluates; commerce commits

The cart is normally authoritative in a commerce backend. It owns:

• product SKU and variant;
• quantity;
• base unit price;
• currency;
• item-level commercial metadata;
• shipping selection and delivery address;
• tax inputs;
• customer-visible cart total; and
• the durable conversion of the cart into an order.

Talon.One receives a promotion-relevant projection of that cart in a customer session. It returns a decision that may include setDiscount, setDiscountPerItem, addFreeItem, coupon acceptance, or a notification.

Suppose Talon.One returns:

{
  "effectType": "setDiscountPerItem",
  "props": {
    "name": "Welcome offer#0",
    "value": 24.0,
    "position": 0,
    "scope": "price"
  }
}

This says that the Rule Engine has decided a USD 24.00 adjustment should apply to a particular submitted cart item. The commerce service must still:

1. map the returned position and, where present, subPosition to its own cart line and item unit;
2. verify that the effect can be applied to the current cart revision;
3. calculate and display the resulting total according to its agreed pricing model;
4. persist the applied adjustment, its label, and Talon.One correlation data with the final order; and
5. send the authoritative transaction outcome back through the customer-session lifecycle.

The applied order discount is therefore a commerce-side financial and audit record, even though Talon.One was the decision authority that calculated it.

Preserve the original commercial values

Do not overwrite the original line price with the discounted price. At minimum, retain:

Value	Owner	Example
Base unit price	Commerce pricing service	USD 120.00
Promotion adjustment	Talon.One decision, applied by commerce	USD 24.00
Effective selling price	Commerce order calculation	USD 96.00

This separation supports recalculation, tax handling, customer-service explanations, cancellations, and partial returns. It also prevents a later cart update from being incorrectly evaluated against an already discounted price.

Position is not a durable line identity

Talon.One item effects refer to the submitted cart structure through position and, if quantity is greater than one, subPosition. This makes the ordering and structure of cart items in the submitted payload part of the integration contract.

Your commerce platform should keep its own stable line-item identifier. The promotion adapter should create a deterministic mapping between that internal line ID and the order of cartItems sent to Talon.One for the relevant request. Do not persist a Talon.One array position as the permanent identifier of an order line.

---

Promotion ownership: configuration, decision, and realized value

“Promotion data” is not one thing. It contains at least four different types of information, with distinct owners.

Promotion data type	Primary owner	Why
Commercial objective and policy	Marketing and commercial governance	“Acquire first-time customers” or “increase repeat purchase” is a business decision.
Campaign configuration, rules, budgets, evaluation behavior	Talon.One	Talon.One is the configured decision engine for the mechanism.
Eligibility facts, such as SKU category, market, price, customer status	Source commerce, catalog, and customer systems	These are business facts supplied for evaluation.
Realized discount on an order	Commerce, OMS, and finance records	This is the financial outcome actually granted and charged.

The clean boundary is:

Talon.One owns the promotion decision and the Talon.One-managed promotion state. Commerce owns the actual transaction and its monetary record.

For campaigns configured in Talon.One, do not reproduce the campaign condition in the storefront. The storefront may display messages based on returned effects, but it should not independently decide that a customer qualifies for “20% off outerwear.”

Coupons, budgets, and loyalty are stateful promotion mechanisms

When you use Talon.One coupons, referrals, giveaways, campaign budgets, or loyalty programs, Talon.One is normally the source of truth for the state of those mechanisms:

• whether a Talon.One coupon is valid, reserved, redeemed, or rolled back;
• whether a campaign budget remains available;
• whether a referral code was accepted or redeemed;
• which giveaway code is awarded after finalization; and
• the point transactions and balances of a Talon.One loyalty program.

Your customer-facing systems can show these outcomes, and your order system should retain the relevant order-level evidence. But they should not independently mark a Talon.One coupon as redeemed or increment a Talon.One loyalty balance.

There is one important exception: some enterprises already have a corporate voucher or loyalty ledger that must remain authoritative. In that case, do not silently create competing records in Talon.One. Either:

• retain the external program as the source of truth and synchronize only the necessary eligibility facts; or
• explicitly migrate ownership to Talon.One with a controlled reconciliation plan.

A “mirror both ways and hope” approach will eventually produce duplicate redemptions, mismatched balances, or contradictory customer-service outcomes.

---

Fulfillment ownership: a reward is not a shipment

Fulfillment is owned by the system that can actually allocate inventory, create work, ship goods, issue service entitlements, and process returns. Depending on the enterprise, that may be an OMS, WMS, subscription platform, ticketing service, or digital-delivery service.

Consider an addFreeItem effect. Talon.One is saying: this session qualifies for a free item with this SKU and quantity. The commerce and fulfillment domains still determine whether that SKU is sellable, stocked, legally shippable to the destination, and successfully delivered.

A robust handling model is:

Event or record	Authority	Talon.One implication
Rule qualifies for a free gift	Talon.One	Returns addFreeItem as the promotional decision
Gift is inserted into checkout/order	Commerce or OMS	Adds a zero-priced order line and records the promotion source
Inventory is allocated	Inventory or WMS	Notifies the order process; Talon.One does not allocate stock
Gift is shipped or digitally delivered	Fulfillment system	Delivery status remains external
Order is cancelled or item returned	OMS or returns platform	Integration updates the Talon.One session so relevant promotion state can roll back

Do not close a Talon.One session merely because a gift line was proposed in an open cart. Closing is a commercial commitment that may redeem coupons, make loyalty changes persist, and apply campaign-budget impact. The order workflow must own the decision that this commitment point has been reached.

Similarly, a return begins outside Talon.One: the OMS or return service knows which physical or digital item was accepted for return. The integration communicates that authoritative return event to Talon.One, enabling it to calculate the applicable promotion and loyalty rollback effects.

---

The end-to-end ownership trace

Use this trace for a shopper who applies a coupon, receives a discount, and qualifies for a free bottle.

Business moment	System of record	Talon.One’s role
Shopper identity is established at sign-in	Identity and customer-master systems	Associated Talon.One profile is updated or attached to the current session
Shopper adds a jacket and enters a coupon	Commerce cart service	Receives the current cart and coupon as evaluation context
Coupon validity and promotion eligibility are evaluated	Talon.One	Returns acceptCoupon, discount, and possibly free-item effects
Discount and free item appear in the editable cart	Commerce cart service	Effects are interpreted and reconciled; Talon.One does not own the cart UI state
Customer confirms order and payment commitment is reached	OMS and payment workflow	Session is closed at the chosen commitment point
Coupon redemption, budget impact, and Talon.One loyalty changes finalize	Talon.One	Maintains its promotion-mechanism state
Order, payment, tax, and applied promotion adjustment are persisted	OMS, payment, finance systems	Talon.One decision metadata may be retained as evidence
Gift is allocated and shipped	OMS, WMS, fulfillment systems	No independent Talon.One fulfillment action
A partial return is accepted	OMS or returns platform	Integration updates the session; Talon.One returns relevant rollback effects

The order of authority matters. Talon.One should not infer a payment failure from an absent API call, and an OMS should not infer that a coupon was redeemed merely because it appeared in an open cart. Each system must receive an explicit, reliable business event through its integration boundary.

---

Architecture rules to make ownership enforceable

An ownership diagram is useful only if it leads to operational rules.

1. Define one writer for each field

For every field in the integration contract, record:

• the business meaning;
• the system of record;
• the source event that changes it;
• whether Talon.One receives it, calculates it, or both;
• the downstream consumers; and
• retention and privacy constraints.

For example, cartItems[].price might be owned by Commerce Pricing, while setDiscountPerItem.props.value is calculated by Talon.One and applied to an order adjustment owned by the OMS.

2. Treat effects as typed commands or decisions

Your adapter should dispatch by effectType, not by array position, and should map each supported effect to a clear owner.

Effect family	Talon.One responsibility	External responsibility
Discount effects	Calculates qualifying adjustment	Applies and persists adjustment in cart/order
Coupon and referral acceptance	Validates promotion mechanism	Displays state and submits final order lifecycle
Coupon rollback	Reopens Talon.One redemption availability	Updates customer-facing and order-service records
Free item	Determines entitlement	Adds order line, allocates, fulfills, handles substitution policy
Loyalty additions and deductions	Maintains Talon.One loyalty transactions	Displays balance and records related order context
Notification	Supplies campaign-authored content	Chooses safe rendering, placement, localization policy, and accessibility behavior
Custom effect	Returns campaign-configured payload	Validates schema and invokes explicitly approved downstream behavior

3. Persist a decision snapshot at order commitment

When an order is finalized, retain enough information to reconstruct why its price was what it was. A practical snapshot includes:

• order ID and Talon.One customer-session ID;
• Talon.One Application and environment;
• a correlation ID;
• submitted cart revision or a secure hash of it;
• applied effect types, names, values, scopes, and item mappings;
• coupon or referral values where appropriate and permitted;
• the final calculated order totals; and
• the time of promotion evaluation and final session closure.

This is not a replacement for Talon.One’s campaign history. It is the commerce-side evidence of what was actually applied to the financial transaction.

4. Prevent uncontrolled feedback loops

A problematic loop might look like this:

1. Commerce sends customer tier to Talon.One.
2. A Talon.One rule updates a profile attribute.
3. An integration writes that attribute into CRM.
4. CRM synchronization writes it back to Talon.One.
5. The changed value triggers further rules.

Avoid this by documenting directionality and by distinguishing source facts from promotion-derived facts. If a campaign result must become an enterprise fact, carry it using a named integration flow with idempotency, change detection, and auditability.

5. Minimize replicated personal data

Talon.One only needs the customer information that campaign decisions require. Avoid sending unnecessary contact details, government identifiers, payment information, or full behavioral histories merely because the Integration API can carry attributes.

A promotion decision often needs a stable customer ID, market, customer status, and limited eligibility attributes. It rarely needs raw payment details or a full CRM profile.

---

Sandbox architecture activity

Use one existing sandbox campaign, ideally the coupon campaign from the previous lesson. Create a short ownership register with four rows: customer, cart/order, promotion, and fulfillment.

For each row, document:

• the designated system of record;
• data Talon.One receives;
• data Talon.One decides or manages;
• data the external system must persist or execute; and
• the event that triggers any Talon.One session update.

Then test the model against one failure path: an order closes, payment subsequently fails, and the OMS cancels the order. Verify that your register identifies the OMS or payment workflow as the authority for the failure, and Talon.One as the system that returns promotion-side rollback outcomes after being told about it.

---

Key takeaways

• A system of record is the authorized source of a business fact, not simply the system where a copy is stored.
• Customer identity, cart contents, base prices, orders, payments, and fulfillment normally remain authoritative outside Talon.One.
• Talon.One is the decision authority for configured promotion logic and, when its native mechanisms are used, for campaign budgets, coupon state, referrals, giveaways, and loyalty transactions.
• Talon.One effects are decisions or promotion-state outcomes. The integration applies external consequences and persists the resulting commercial transaction.
• A free item entitlement is not inventory allocation or shipment; a discount decision is not an invoice; coupon acceptance in an open cart is not final redemption.
• Avoid ambiguous “joint ownership.” For every field, define the authoritative writer, synchronization direction, lifecycle event, and reconciliation behavior.

Next, you will examine the operational consequence of this boundary: the risks introduced when checkout depends synchronously on promotion decisioning, and the design choices that keep a transaction flow correct when that dependency is slow or unavailable.