Defining Scope, Assumptions, and Quality Attributes for Talon.One Implementation

Welcome to the capstone module. The earlier modules established how Talon.One evaluates promotions, manages sessions and effects, supports loyalty, and fits into a reliable API integration. This module turns those capabilities into an architecture that can be reviewed, implemented, and defended.

An end-to-end Talon.One implementation is not “connect checkout to a promotion API.” It is a bounded change to a business and technology ecosystem: promotion configuration, customer and cart data, synchronous decisioning, fulfillment of returned effects, order reversals, operational ownership, and failure handling. This lesson establishes the first architecture artifact: a concise scope and quality baseline. It states what will be built, what must be true for it to work, and how well it must work.

---

Scope is a boundary, not a feature list

A scope statement should make two kinds of ambiguity impossible:

1. Business ambiguity: Which promotional and loyalty journeys are being enabled?
2. System ambiguity: Which systems and teams change, exchange data, or own an outcome?

A useful scope is therefore expressed across several dimensions.

Scope dimension	The decision to document	Talon.One example
Business capability	Which customer journeys are supported?	Cart promotions, unique coupons, referral rewards, loyalty earn and burn
Channels and markets	Where does the capability apply?	Web and mobile commerce in selected countries; retail POS deferred
Lifecycle states	Which transaction outcomes are handled?	Open cart, closed order, payment failure, cancellation, partial return
Integration boundary	Which systems communicate with Talon.One?	Commerce backend, customer identity service, order service, catalog source, notification service
Data boundary	Which data is exchanged and why?	Pseudonymous profile ID, cart contents, promotion code, payment method category; no unnecessary personal data
Configuration boundary	Who owns campaigns, attributes, catalog data, and release approvals?	Marketing configures approved campaigns; platform team automates controlled promotion to live
Operational boundary	Who monitors and resolves failures?	Commerce platform team owns the adapter; promotion operations owns campaign diagnosis; support owns customer remediation
Explicit exclusions	What is deliberately not being delivered?	Replacing the ERP, calculating tax, inventory allocation, native customer identity management

A strong scope statement also uses non-goals. They prevent an apparently small promotion project from quietly becoming a customer-data-platform, pricing-engine, or fulfillment-system replacement.

For example, “Talon.One is the source of truth for discounts” is too imprecise. Talon.One is authoritative for the promotion decision and its platform-managed state, while the commerce platform normally remains authoritative for the order, price presentation, payment, tax, inventory, and refund. The integration must persist what it applied to the order so that downstream systems can audit and reverse it correctly.

Before defining the boundary in detail, use a consistent visual vocabulary. The C4 approach is particularly useful in a capstone because it lets different audiences see the same architecture at different levels of abstraction: context for stakeholders, containers for engineers, and components for teams implementing the adapter.

The central discipline is simple: do not put implementation detail in a scope boundary, and do not disguise an unresolved business decision as an implementation detail.

For instance:

• “The checkout service invokes Talon.One over HTTPS” is an implementation choice.
• “The checkout must not be blocked by a temporary promotion-engine outage” is a business and quality decision.
• “Promotions are available only to authenticated customers” is a scope decision.
• “Guests receive a unique profile ID because profile-level budgets and loyalty apply to them” is an assumption with architectural consequences.

---

Establish an end-to-end baseline

To make the method concrete, use this illustrative reference implementation throughout the capstone:

RetailCo sells through web and mobile channels. It will launch cart promotions, unique coupon campaigns, and a profile-based loyalty program. The commerce platform owns orders, payment, catalog pricing, inventory, refunds, and customer-facing totals. Talon.One evaluates campaign rules and manages applicable promotion, coupon, and loyalty state. An integration adapter mediates between RetailCo’s commerce services and Talon.One.

This is not a claim that every implementation needs loyalty, unique coupons, or a dedicated adapter. It is a bounded scenario with enough complexity to expose the decisions that a production integration needs.

A first-pass scope baseline for RetailCo might look like this:

Area	In scope for launch	Deliberately out of scope
Customer journeys	Cart preview, checkout, coupon application, loyalty earn and redemption, cancellation, partial return	Store associate and point-of-sale journeys
Talon.One configuration	Applications, approved attributes, campaigns, campaign budgets, loyalty program, controlled sandbox-to-live release	Unmanaged manual production changes
Synchronous integration	Cart updates at meaningful changes and checkout decisioning	Browser-to-Talon.One calls
Effects handling	Commerce discounts, coupon messages, loyalty balance changes, fulfillment instructions, rollback processing	Rebuilding Talon.One effects logic inside the client
Data	Stable opaque customer and cart/session identifiers, qualifying cart fields, limited segmentation attributes	Full customer record replication or payment instrument data
Operations	Monitoring, alerting, reconciliation queue, credential rotation, incident runbook	Replacing enterprise reporting or customer-support tooling
Migration	Required active coupons and loyalty balances for launch	Historical order and campaign analytics migration, unless explicitly needed

Notice that “end-to-end” does not mean “every enterprise system is changed.” It means every required responsibility has an owner and every lifecycle outcome is intentional.

Talon.One’s integration checklist is a practical prompt for defining these boundaries, especially around backend-only API calls, campaign and attribute preparation, customer-session state, and guest-profile trade-offs.

The ownership test

For each capability in scope, assign one authoritative owner. A compact ownership model for RetailCo could be:

Business data or action	Primary system of record	Talon.One’s role	Integration responsibility
Customer identity and consent	Identity service or CRM	Holds a stable integration ID and permitted promotional attributes	Send only the minimum data needed for evaluation
Cart, prices, taxes, payment, and order	Commerce and order services	Evaluates eligibility and returns effects	Apply valid effects to the current cart or order and persist the result
Campaign definitions and evaluation	Talon.One	Stores campaign configuration and evaluates rules	Promote approved configuration and consume evaluation responses
Coupons and loyalty balances	Decide explicitly per program	Can manage issuance, redemption, balances, and related effects	Reflect customer-facing status and reconcile effects after reversals
Fulfillment	OMS, warehouse, digital-entitlement, or notification service	May return a fulfillment-relevant effect	Dispatch the effect to the owning fulfillment system and record the outcome

The key phrase is primary system of record, not “the only system that stores a copy.” Commerce may store the discount it applied; it does not need to independently recreate campaign qualification. Talon.One may have a customer profile; that does not make it the enterprise identity or consent authority.

---

Assumptions turn unknowns into decisions

An assumption is something the architecture relies on but does not control or prove at the time of design. A constraint is a condition the design must obey. A risk is the possible consequence if an assumption turns out to be false.

These terms should not be mixed.

Type	Example	Design response
Assumption	Commerce can supply a stable immutable cart ID before checkout.	Validate early; define a fallback or block the affected journey.
Constraint	Integration API credentials must never reach browsers or mobile clients.	Call Talon.One only from a controlled backend.
Risk	Parallel cart or profile updates could produce conflicts or duplicated processing.	Serialize writes and use idempotency where supported.
Decision	Guests participating in loyalty receive an individual pseudonymous profile ID.	Define retention, merge, privacy, and identity-linking behavior.

A principal architect should maintain an assumption register with an owner, validation date, and impact. “We assume it works” is not an assumption worth recording. “We assume the order service produces a durable cancellation event within five minutes of a payment reversal” is.

For RetailCo, the core assumptions should include the following.

Identity and session assumptions

• Every known customer has a stable, opaque integration ID. Email addresses and phone numbers are mutable personal data, not durable technical identifiers.
• Every cart or order has an immutable session integration ID.
• A guest strategy is explicit. If profile-level budgets, loyalty, or customer-level targeting are in scope, RetailCo uses a distinct guest profile ID and defines its retention policy. If these are not required, RetailCo can omit a guest profile ID instead of creating shared state.
• Updates for a given customer session and profile are sequenced. Parallel actions, such as a coupon application and a cart update, must not race through separate uncoordinated requests.

Transaction and lifecycle assumptions

• The commerce platform can send the complete current cart state whenever it requests evaluation. This is necessary for rules based on bundles, quantity thresholds, and relationships across items.
• The business defines a commitment point for the order. A common choice is to close the Talon.One session after the final cart decision and immediately before the customer moves into payment processing.
• Payment failure, full cancellation, and partial return are reliable business events that can reach the adapter. They are not inferred from a missing browser session.
• The integration stores the effect set applied to an order, along with the Talon.One session ID and an internal correlation ID. This is essential for reconciliation and support.

Platform and operating assumptions

• Campaigns, required attributes, and catalog data are deployed and validated in sandbox before live activation.
• Cluster URLs are externalized configuration because an API URL can change, including during a cluster move.
• The platform team can store and rotate environment-specific secrets in an approved secret-management system.
• Talon.One data retention does not substitute for enterprise reporting, financial audit, or customer-support records. Those records need an explicit extraction or persistence strategy.

The following practices from Talon.One’s documentation should become stated assumptions or constraints in the architecture rather than being left as informal engineering conventions.

---

Quality attributes make “production-ready” testable

Functional requirements tell you what the system does: “apply a ten-percent discount when conditions match.”

Quality attributes state the required character of that behavior: “apply the discount exactly once under retry,” “return a decision within the checkout latency budget,” or “continue checkout safely during a temporary promotion-service outage.”

A useful quality requirement is expressed as a scenario:

Part	Question
Source	Who or what causes the stimulus?
Stimulus	What happens?
Environment	Under what operating condition?
Artifact	Which part of the architecture must respond?
Response	What must it do?
Measure	How will success be objectively verified?

For example:

During peak checkout traffic, when the commerce backend submits a final cart to Talon.One, the promotion adapter returns a validated effect decision within its allocated latency budget for at least the agreed percentile of requests; it records the correlation ID, timing, status, and effect summary without logging credentials or unnecessary personal data.

This is stronger than “the integration must be fast.” The final targets belong to RetailCo’s service-level objectives and contractual commitments; do not invent them from a vendor API reference. The architecture team proposes measurable targets, and business, security, and operations stakeholders approve them.

The quality attributes that matter most

Quality attribute	Talon.One-specific scenario	Architectural response
Promotion integrity	A network failure causes the checkout request to be retried.	Use idempotency where the endpoint supports it; keep an internal order-to-session record; never apply the same commercial benefit twice.
Availability	Talon.One times out during a cart preview or checkout.	Use tight timeouts, bounded retries, a circuit breaker, and an explicitly approved fallback. Do not let requests queue indefinitely.
Performance	A customer adds an item to a cart during busy traffic.	Evaluate only at meaningful cart changes, send complete cart state, use response customization when related data is needed, and cache only where its semantics are safe.
Concurrency safety	Coupon application and cart update occur almost simultaneously for one customer.	Serialize updates per session and profile; deduplicate customer action events; handle conflict responses deliberately.
Security	An attacker inspects the web or mobile client.	Keep API keys server-side, use separate keys per environment, rotate keys, enforce least privilege, and optionally restrict allowed IP addresses.
Privacy	A data-subject deletion request is received.	Minimize profile and session data, use pseudonymous IDs, avoid personal data in logs, and define deletion and retention responsibilities.
Auditability	Customer support disputes a missing reward or discount.	Persist the commerce decision, relevant effect summaries, session/order IDs, campaign reference where appropriate, timestamps, and processing outcomes.
Operability	A campaign revision unexpectedly reduces conversion or yields failures.	Monitor latency, error classes, effect types, rule failures, circuit state, and reconciliation backlog; maintain a release and rollback process.
Scalability	Marketing launches a high-traffic campaign.	Load-test representative cart payloads and peak concurrency; avoid per-keystroke evaluation; isolate asynchronous work from checkout-critical calls.
Recoverability	A payment authorization fails after a session was closed.	Send the appropriate reopen or cancellation lifecycle update and process returned rollback effects against the commerce record.

Two observations matter.

First, availability and promotion integrity can conflict. A cached discount may keep a page responsive, but it may be invalid for a scarce coupon, a budget-limited offer, or a loyalty redemption. Conversely, proceeding with “no promotion” preserves checkout availability but may violate a guaranteed advertised price. There is no universal technical answer. The scope baseline must classify each journey and obtain a business decision.

A workable policy might distinguish:

• Product and cart preview: Show a clearly identified estimated or cached promotional result only where the business accepts it.
• Ordinary checkout promotion: If decisioning is unavailable, proceed without discretionary promotions, explain the customer-facing outcome, and reconcile through a controlled process if required.
• Scarce, reserved, or contractual benefit: Do not locally invent eligibility. Either fail the affected action with a clear retry path or use a separately approved reservation/commitment design.
• Post-purchase notification or analytics: Process asynchronously; it must not delay checkout.

Second, retries are not a fallback strategy by themselves. Retrying a request may help a transient timeout, but uncontrolled retries increase load during an outage and can create duplicate commercial actions. The documented order is intentional: short timeout, limited exponential backoff with jitter, circuit breaker, then a deliberate fallback.

---

A concise scope-and-quality baseline

For the capstone, your first architecture artifact can fit in two to four pages if it is precise. It should contain the following sections.

1. Purpose and business outcome

State the commercial purpose in business terms.

Enable RetailCo to run governed cart promotions, unique coupon campaigns, and loyalty earn-and-burn journeys across web and mobile commerce, while preserving checkout continuity and accurate order reconciliation.

Avoid mixing the purpose with a solution. “Implement Talon.One APIs” is not an outcome.

2. Scope boundary

Document:

• channels, markets, currencies, and customer populations;
• journeys and transaction states covered;
• enterprise systems that exchange data;
• Talon.One features being used;
• explicit non-goals;
• the system of record for each contested business object.

3. Assumptions, constraints, risks, and decisions

Give each item an identifier and owner. For example:

ID	Statement	Classification	Owner	If invalid
A-01	Commerce provides immutable cart IDs.	Assumption	Commerce lead	Define an adapter-generated mapping before build.
C-01	No Talon.One credential may exist in a client application.	Constraint	Security lead	Architecture is noncompliant; release is blocked.
D-01	Loyalty guests receive distinct pseudonymous profile IDs.	Decision	Product and architecture	Define guest retention and account-linking behavior.
R-01	Coupon inventory may be exhausted under concurrent checkouts.	Risk	Promotion operations	Test concurrency and define customer messaging.

4. Quality-attribute scenarios and acceptance evidence

For each high-priority quality attribute, name the test or operational evidence that will demonstrate it:

• Load-test evidence for latency and saturation behavior.
• Failure-injection evidence for timeout, retry, circuit-breaker, and fallback behavior.
• Concurrency-test evidence for same-profile and same-session conflicts.
• Security-review evidence for credentials, log redaction, access control, and data minimization.
• Reconciliation-test evidence for payment failure, cancellation, partial return, coupon behavior, and loyalty rollback.
• Monitoring dashboard and alert evidence for production readiness.

This baseline is intentionally a decision document, not a full design. It tells the next architecture artifacts what they must demonstrate. The system-context diagram must show every in-scope external system. The deployment view must show where credentials, routing, and adapters live. The sequence diagrams must show the quality scenarios in action.

---

Conclusion

A defensible Talon.One architecture begins by separating four things:

• Scope: the journeys, systems, data, ownership boundaries, and non-goals.
• Assumptions: conditions that need validation and have consequences if false.
• Constraints, risks, and decisions: mandatory limits, possible failures, and deliberate trade-offs.
• Quality attributes: measurable requirements for integrity, availability, performance, security, privacy, operability, scalability, and recovery.

For Talon.One specifically, the highest-impact early decisions concern session lifecycle, guest-profile strategy, system-of-record ownership, backend-only credential handling, serialized updates, idempotency, and approved behavior when synchronous decisioning is unavailable.

Next, you will turn this written boundary into a system-context diagram showing Talon.One, the commerce platform, customers, and the enterprise systems that must interact with the implementation.