SYSE.8 - Develop an Integrated Offering and Provider Concept for Using an Engineered Result

SYSE.8:0 - Use This When

Use this pattern when a project is defining what a provider will make available and under what promise. The proposal may, for example, transfer a product, grant access to a shared enabling System, maintain an agreed condition, or accept responsibility for an agreed result, but the project has not yet connected that promise to the provider arrangement needed for the receiving use.

The result is an account that connects a bounded offering to the provider arrangement, responsibility claims, and evidence needed for it. It becomes an input to engineering and neighboring decisions. The account describes an engineering proposal; commercial viability, actual provider Systems, performed Work, duties, and authority claims require their own support.

Apply the pattern when a choice among forms of provision—for example, transfer, access, continuing provision, or responsibility for a result—changes the engineered System, interfaces, provider Systems, capabilities, risks, or realization network. A mere change from product to service wording is outside its boundary. Use A.2.3 for promise content alone; use SYSE.1, SYSE.16, and SYSE.2 when the project system-of-interest or use is unclear. Neighboring specialist practices retain their own Methods, results, and authority—for example, practices governing demand, positioning, price, finance, legal duty, organization change, continuing operations, or shared enabling Systems.

SYSE.8:0.1 - Terms and Distinctions

The everyday words in this field are overloaded. Recover the object or relation before relying on them:

Name in this pattern	What it denotes
client-side use	A bounded actual or possible-future situation in which a receiving System obtains or attempts to obtain a result. A scenario or journey is a description of that use.
promise content	A consumer-facing `U.PromiseContent` episteme stating the promised outcome, applicability, access terms when access is promised, and acceptance claims. Ground the provider, Method, Work occurrence, and any commitment through their own relations.
supplied or accessed subject	The product, asset, material portion, data, episteme, capability access, or other subject transferred, changed, accessed, or made available. It need not be a System.
provider System	An actual System that participates in a named provider relation, is classified under a local provider SystemRole kind, or holds an assignment under that kind. A department or company name is only a clue until the underlying System and relation are identified.
provider arrangement	The Systems and relations through which provision is expected to happen. Its account names actual providers and partners, possible-future provider referents, their assignments and other relations, and the capabilities, Methods, Work, interfaces, resources, and enabling Systems needed for provision. Claims about duty, risk, and evidence remain separate.
integrated offering concept	The engineering proposal that connects client-side use, promise content, supplied or accessed subjects, engineered Systems, provider arrangement, realization needs, evidence, and reopen conditions. This is a local collective name; the FPF kinds of its participants remain unchanged.
fulfilment or acceptance claim	A claim that evaluates evidence about performed Work, affected subjects and states, and the relevant direct relations against the promise content. Treat the promise, payment, fulfilment, and acceptance through their own relations.

Bare service is a recognition cue. At a consequential use, apply the FPF service-word recovery in A.6.P:4.11a and name the recovered referent or relation. A local ProviderSystemRole kind, an assignment occurrence, an actual provider System, its capability, its Method, and its dated Work remain different objects.

SYSE.8:1 - Problem Frame

Many engineered results are usable only through an arrangement that continues beyond transfer of a product. For example, software needs operating infrastructure and change capability; a machine may need consumables, calibration, maintenance, logistics, data, trained operators, or financing; and a promised condition such as temperature, availability, or stock level needs Systems that can observe and restore it. Changing the commercial or access relation can also change the technical architecture and the allocation of risks—for example, variability, failure, asset, or update risk.

Product-only engineering leaves those changes to later improvisation. Service-first rhetoric creates the opposite failure: every object and Work occurrence is bundled under one broad word, and the project assumes that renaming the offer creates a desired effect—for example, demand, recurring revenue, sustainability, or provider capability.

SYSE.8:2 - Problem

A plausible technical product concept can coexist with an impossible provider concept. Recurring mismatches include promising availability without observing the relevant state, retaining ownership without financing or maintenance capability, automating access while transferring exception Work to users, and depending on partner Systems whose responsibilities and interfaces are not engineered.

Four failures recur in engineering descriptions: a business model omits bearer and interface constraints; a technical architecture description omits obligations and continuing Work; an SLA omits the actual provider arrangement; and a service blueprint is treated as evidence that provision will work. Use the descriptions needed for the bounded decision, with their claims and omissions explicit.

SYSE.8:3 - Forces

The engineering decision must manage these recurring tensions:

A useful first concept must be cheap, while the provider arrangement crosses several kinds of boundary—for example, technical, operational, organizational, financial, legal, or commercial.
Arrangements such as product transfer, access provision, continuing activity, availability responsibility, or result responsibility allocate assets, variability, evidence, and risk differently.
Provider Agents need freedom to choose Methods, yet promise content and acceptance claims must be explicit.
A technically feasible arrangement can be commercially unattractive; a commercially attractive promise can be physically unrealizable.
Partner Systems and internal shared enabling Systems can supply capability through relations that make them neither parts of the provider System nor subjects of the same project.
Continuing change makes a frozen launch configuration inadequate; evidence must reopen both offer and provider choices.
Current PSS and servitization literature supplies many representations and Methods. Selecting one for the current use and claiming a performance gain still require project evidence.

SYSE.8:4 - Solution

Develop several client-use and provider-arrangement candidates together. For each candidate, distinguish the promise content, supplied or accessed subjects, Systems, assignments, Methods, Work, responsibility and authority claims, evidence, economic claims, and consequences that matter to the decision. Name the engineering decision that consumes each choice and the specialist practice that must answer each specialist question.

SYSE.8:4.1 - Perform the Move

Bound the use and decision. Name the client-side use, intended change, receiving Systems, project system-of-interest or intended System referent, configuration, horizon, and decision. Use SYSE.1, SYSE.16, or SYSE.17 results only when they fit that subject, configuration, use, horizon, decision, and evidence window. Otherwise use a qualified direct source or record the missing result, then pause only the decision that needs it. These result dependencies do not prescribe the order of Work.
Recover the promise. State the consumer-facing promise content, eligibility or applicability, access terms when access is promised, acceptance conditions, and evidence needed to evaluate fulfilment. Keep each actual commitment, permission, delivery relation, acceptance relation, payment, and Work occurrence separate.
Name the subject. Identify what is transferred, accessed, changed, used, restored, or kept within a stated range or condition: for example, a machine, material lot, software edition, data, access point, temperature range, stock state, or performed Work. Keep non-System subjects in their recovered kinds.
Generate materially different candidates. Compare plausible arrangements such as product transfer with support, access or use provision, continuing availability responsibility, result-oriented provision, and mixed forms. Retain variety when evidence can still change the choice.
Develop the provider structure. For each candidate, identify the actual provider and partner Systems. Represent a provider that does not yet exist only as an intended referent in a possible-future claim. Record the relations and assignments that obtain. Then name the capabilities, Methods, recurring and exceptional Work, interfaces, resources, data, tools, shared enabling Systems, supply relations, and recovery arrangements that can change the decision. State the kind of each relation—for example, parthood, interaction, transfer, access, obligation, or contribution—and ground it independently of any intended referent.
Separate expected Work from responsibility and authority. For planned Work, name the intended performer Agent or the conditions for selecting one, together with the sought result. For Work that has occurred, identify the actual performer Agent and the Work independently; add assignment-bound attribution only when the receiving use needs it. Separately identify the System that holds or owns each asset; the Agent expected to bear or manage variability and failure exposure, observe or restore a condition, and receive each decision or evidence result; and any current responsibility, commitment, permission, legal duty, or authority relation.
Connect realization and continuing change. Identify the realization and change Work, its intended or actual performer Agents as applicable, and the Systems it uses or changes. Name the subjects changed—for example, the product, provider capability, interfaces, data, operating arrangement, or shared enabling Systems. State what later evidence or change will reopen the concept—for example, evidence from a new configuration, update, migration, maintenance event, partner change, or recovery attempt.
Obtain specialist results. Request a specialist result only when it can change the candidate—for example, a result from strategy, marketing, commercial analysis, finance, law, organization change, operations, supporting-System engineering, safety, security, or environmental engineering. Preserve its source and authority boundary.
Compare the candidates. Compare decision-relevant consequences—for example, client-side use, technical feasibility, architecture, capability, value, cost, financing, risk allocation, operational burden, changeability, evidence, or affected-System consequences. Keep non-equivalent measures separate unless an explicit aggregation Method preserves the distinctions used by the decision.
Record the bounded concept. Give each candidate one current disposition: select it, retain it for later comparison, branch it by a stated condition, or reject it. Record unsupported claims, needed specialist and realization results, responsibilities, evidence needs, and conditions for reconsideration. A conditional candidate is useful when it makes the next decision visible.

These numbered moves are a CGUS presentation of the Method under A.22.CGUS: they expose logical dependencies but do not prescribe Work order. Work such as use analysis, concept development, architecture, organization change, operations, commercial analysis, trials, or realization can overlap and reopen earlier decisions.

SYSE.8:4.2 - Record the Result

The smallest useful offering-and-provider account contains:

Field	Required content
client-side use	Receiving Systems, intended change, use situation, configuration, horizon, and current decision.
promise and acceptance	Promise-content edition, applicability, access terms when access is promised, acceptance claims, evaluation Method, and required evidence.
subjects	The supplied, accessed, changed, or maintained subjects named by the proposal—for example, products, Systems, assets, material portions, data, epistemes, states, access, or Work.
candidate arrangements	Materially different arrangements—for example, transfer, access, continuing provision, responsibility for a result, or a mixed form—and each candidate’s current disposition.
provider structure	Actual provider and partner Systems; named possible-future provider referents; the relations and assignments that obtain; and the capabilities, Methods, Work, interfaces, resources, data, shared enabling Systems, and recovery arrangements needed for provision.
expected Work, responsibility, and risk	Planned or performed Work, intended or actual performer Agents as applicable, result-restoration actions, asset custody or ownership, variability and failure exposure, and separately supported responsibility, obligation, permission, remedy, or authority claims.
realization and change	Required realization and change Work, the Systems it uses or changes, configuration and update conditions, provider-capability changes, dependencies, and unsupported feasibility claims.
specialist returns	The needed specialist result and its receiving use—for example, a commercial, financial, legal, organizational, operational, supporting-System engineering, safety, security, or environmental result.
evidence and consequences	Decision-relevant evidence and its limits—for example, evidence about fulfilment, use, performance, cost, value, burden, benefit, harm, or consequences for affected Systems.
receiving engineering use	Selected or retained concepts, the architecture or realization decisions that use them, and reopen conditions.

An initial account needs the client-side use and decision, one promise claim, the supplied or accessed subject, one actual provider System or named possible-future provider referent, one critical Work or direct relation, and one evidence gap or receiving decision. Other fields may say not yet needed when they cannot change the current candidate. Mark an unavailable answer as unknown when the decision depends on it, and name what it blocks. The result may use several representations. A publication or representation—for example, a canvas, contract draft, architecture view, service blueprint, financial model, or operations account—is one source. Ground the provider arrangement from its actual Systems and relations.

SYSE.8:4.3 - What Changes in Practice

The practitioner treats transfer as one boundary in a longer provider arrangement and recovers the objects and relations hidden by service. The account keeps client-side use, promise content, subjects, technical architecture, provider capability, continuing Work, responsibilities, evidence, and change distinct while connecting them to the same engineering decision.

SYSE.8:5 - Worked Case: Cast-Iron Transfer, Delivery, or Replenishment

A foundry organization and a machining company must decide how an accepted grey-cast-iron lot will reach the machining plant. The lot is a material portion, not a System. The two organizations compare three provider arrangements for the same machining use, material specification, unloading point, and planning horizon.

A commercial lead may decide price and credit and select an arrangement only after an operations coordinator accepts its schedule. Each person has a current assignment and a separate authority relation. The assignments identify their project participation; they do not create authority.

Candidate	Promise and subject	Provider arrangement	Evidence and decision
Gate transfer	The accepted lot will be available at the foundry gate.	The foundry organization performs production Work; the machining company arranges transport from the gate.	Current lot and gate records support availability. The operations coordinator accepts the handover window. The current gate quote is EUR 40,000 with payment due in 30 days. The machining company would also pay EUR 1,800 for haulage within 7 days and perform eight staff-hours of pickup and exception coordination, valued at EUR 50 per hour under `CommercialComparisonRule-2`. The commercial lead retains gate transfer as the low-provider-burden alternative for the foundry, while recording the transport burden received by the machining company.
Scheduled delivery	The accepted lot will reach the plant’s unloading point between 08:00 and 12:00 on the agreed day.	`ForgeHaul-A` is the proposed logistics-provider System. `Truck-12` is the intended transport bearer, and a driver selected under the qualified-driver condition is the intended Agent for the planned transport Work. The proposed `PlantHandover-and-Acceptance-Lot-27` relation keeps custody with the foundry until handover at the unloading point and lets the machining receiver accept only the identified lot, seal, mass, and visible condition against `LotAcceptanceRule-7`. Under proposed `DeliveryExceptionRecovery-Lot-27`, the provider dispatcher must arrange a replacement truck within four hours after a truck failure before handover. No transport, handover, acceptance, or recovery Work has yet occurred.	Operations coordinator `OC-4` performed delivery-assessment Work by applying the plant’s delivery-planning Method. The resulting `DeliveryScheduleAssessment-Lot-27` uses the current carrier roster, unloading calendar, and ten recent runs on the same route: nine arrived inside a four-hour window, and one truck failure was recovered with a replacement in three hours. It supports the 08:00–12:00 window and four-hour recovery only for this route, lot class, season, and current provider roster; it establishes neither future performance nor legal responsibility. The authorized operations coordinator accepts that schedule. The current delivered-lot quote is EUR 42,000 with payment due in 30 days. The machining company would perform one staff-hour of arrival confirmation and handover Work, valued at EUR 50 under `CommercialComparisonRule-2`. For schedule-accepted candidates, that rule compares quoted buyer payments plus receiving transport-coordination Work valued at EUR 50 per hour; it selects a candidate only when its advantage exceeds EUR 100 and records any earlier payment obligation. Gate transfer totals EUR 42,200 and includes a haulage payment due within 7 days; scheduled delivery totals EUR 42,050 with payment due in 30 days. The authorized commercial lead therefore selects scheduled delivery for this lot and retains gate transfer as fallback.
Stock replenishment	Accepted stock at the plant will remain above a stated minimum during operating windows.	A stock sensor exists, but the replenishment controller is only an intended System referent. Observation Work, replenishment Work, access permission, custody, ownership, and restoration commitment remain separate claims.	Sensor history does not yet establish observation reliability; no finance result supports retained inventory; no authorized commitment supplies restoration responsibility. The candidate remains open only for a named observation test and finance decision.

The authorized commercial lead uses DeliveryScheduleAssessment-Lot-27, the operations coordinator’s schedule acceptance, and CommercialComparisonRule-2 with the quoted payments, credit terms, and receiving transport burden to select scheduled delivery. Gate transfer remains the fallback; stock replenishment remains a possible-future candidate pending its named observation test and finance decision. The selection does not assert that transport, handover, acceptance, or recovery Work has occurred, and the intended driver is not an actual performer until separately identified Work occurs. Engineers use the account to carry product, interface, custody, Work, provider System, evidence, and recovery constraints into use, architecture, and realization decisions. Commercial and operations decisions remain separate and use their own authority and evidence. Replacing these relations with the phrase cast iron as a service would lose the decision.

SYSE.8:6 - Bias Annotation

Select candidate distinctions and Methods for the named engineering decision rather than importing a branded framework as a whole. Sources such as PSS, servitization, service design, SaaS, outcome contracting, or engineering of shared enabling Systems can contribute bounded alternatives. Reported economic and environmental gains are configuration-dependent. Academic popularity or official adoption is evidence of visibility or declared use, not of enacted prevalence or success.

Identify each provider or receiving System from its own basis and name the actual Agent performing each Work occurrence. Keep neighboring claims separate—for example, claims about ownership, legal duty, capability, authority, assignment, or a later provider-development decision—even when one System participates in several of them.

SYSE.8:7 - Conformance Checklist

ID	A conforming use…
`CC-SYSE8-1`	names a client-side use, intended change, receiving Systems, project system-of-interest or intended System referent, configuration, horizon, and decision.
`CC-SYSE8-2`	separates promise content, commitments, permissions, supplied or accessed subjects, Systems, Methods, Work, fulfilment, acceptance, payment, and evidence.
`CC-SYSE8-3`	compares materially different offering and provider arrangements rather than renaming one product.
`CC-SYSE8-4`	identifies provider and partner Systems, relations, assignments when current, capabilities, interfaces, Work, resources, shared enabling Systems, and recovery.
`CC-SYSE8-5`	separates expected Work, result restoration, custody or ownership, and risk exposure from any independently supported responsibility, duty, permission, or authority claim.
`CC-SYSE8-6`	connects the selected concept to realization, provider-capability change, configuration, continuing operation, and reopen evidence.
`CC-SYSE8-7`	preserves specialist decisions and authority rather than absorbing, for example, strategy, finance, law, organization change, operations, or Platform Engineering.
`CC-SYSE8-8`	returns a bounded conditional or selected concept with unsupported claims, evidence needs, receiving decisions, and reopen conditions.

SYSE.8:8 - Common Failures and Repairs

Failure	Symptom	Repair
Rename and declare victory	A product is called a service or solution with no changed engineering claim.	Recover the promise, subjects, provider arrangement, and decision; stop if none changes.
Service-object collapse	Provider, API, promise, Method, Work, ticket, access, product, and result share one referent.	Apply `A.6.P:4.11a`; name each referent and direct relation.
Product-only architecture	Technical transfer is designed while continuing provision and recovery are assumed.	Develop provider Systems, capability, Work, interfaces, resources, evidence, and change with the product concept.
Provider as organization label	A company or department label is used as if it had identified the actual Agent for every provider Work occurrence.	Recognize the actual Systems and Agents; separate local SystemRole kinds, assignments, capabilities, and Work attribution.
Universal PSS recipe	One canvas, maturity ladder, or servitization sequence is made mandatory.	Generate context-relevant alternatives and compare them under the named use and evidence.
Guaranteed gain	Recurring revenue, sustainability, loyalty, or market growth is inferred from the arrangement form.	Return the commercial, financial, environmental, and use claims to evidence and specialist decisions.
Hidden burden transfer	Automation or self-service reduces provider effort while increasing user Work or excluding cases.	Trace Work, exception handling, affected Systems, and burden under each candidate.
Specialist absorption	Systems Engineering invents a neighboring result—for example, a price, legal duty, organization design, operating policy, or Platform Engineering result.	Obtain the specialist result and use it as an input with its authority boundary.
Frozen provider	Launch architecture is treated as sufficient for continuing provision.	Record configuration, update, maintenance, partner, migration, recovery, and reopen evidence.

SYSE.8:9 - Consequences

The project can compare arrangements that change the engineered System and provider capability. Promises are matched to feasible provider arrangements and evidence plans. Technical architecture exposes operational and organizational dependencies, and specialist results reach the decisions that need them.

The cost is coordination across several practices and maintenance of corresponding descriptions. Viability and success retain their own evidence and decisions. Record unsupported promise, capability, responsibility, and evidence claims in the offering-and-provider account so that concept comparison and realization decisions can branch or stop the candidate before commitment.

SYSE.8:10 - Rationale

FPF already distinguishes promise content, SystemRole assignments, Systems, Methods, Work, evidence, commitments, permissions, value, and direct relations. The recurring Systems Engineering difficulty is more specific: a choice among transfer, access, continuing provision, or result responsibility changes both the engineered subject and the provider arrangement that realizes and sustains use. This pattern connects the offering choice with the provider arrangement needed to fulfil it.

SYSE.8:11 - SoTA and Source Use

Offering and provider design distinguishes promises, access, participation, providers, Methods, performed Work, obligations, fulfilment and acceptance. Recover the relevant subjects and relations before drawing conclusions about a product-to-service transition, a shared project referent, attribution to an Agent, or a market or provider gain.

Source line	Use here	Epistemic boundary
Brambila-Macias, Sakao, and Kowalkowski (2018), Braga Junior, de Toledo, and González (2020), and Kim (2020)	Support interdisciplinary PSS design, plurality of development Methods, and several possible representation structures.	Use the reviews and case comparison to generate alternatives. Select ontology, practical Method, and representation for the current engineering decision.
Brax et al. (2021), Åkesson et al. (2024), Menon et al. (2024), and Zhao et al. (2025)	Support configuration-dependent provider performance, SME limits, mixed economic and environmental outcomes, and fragmented technical–social–ecological integration.	Use the studies as bounded evidence. Choose the enterprise arrangement from its use and evidence; assess prevalence separately; qualify any reusable provider-design Method through further cases.
Current FPF `A.2.3`, `A.1.SCR`, `A.13`, `A.15.1`, `A.15.6`, `F.6`, `A.6.P:4.11a`, `A.10`, `A.22`, `C.11`, `C.17`, `E.10.ROLE`, and `E.18.NET`	Supplies promise content, actual-System recognition versus intended reference, actual-performer and Work identity, optional assignment-bound attribution, project-focus distinctions, service-word recovery, evidence use, selected structures, value and temporal distinctions, role-word recovery, and transformation-flow structure.	Use these general distinctions directly. `SYSE.8` adds the engineering comparison of offering and provider arrangements and the bounded account returned to later decisions.

Reconsider the affected source-dependent claim when later evidence changes a practical Method, performance boundary, or receiving engineering decision. Treat academic or institutional visibility as evidence of publication or declared use; assess enacted prevalence separately and import only the distinctions needed by the current decision.

SYSE.8:12 - Relations

A.15.6 supplies the general project-focus and system-of-interest distinctions. SYSE.1 specializes that result for an engineering project; SYSE.16 supplies the operational use-context account; and SYSE.17 supplies consequence-bearing Systems and unresolved consequences. Compatible current results can be supplied directly; the relations do not impose a lifecycle order.
A SYSE.8 account supplies only its supported provider-arrangement claims and design constraints to the Agents performing linked-concept, realization, or architecture-decision Work. Those Agents apply SYSE.2 to compare linked use and System concepts, SYSE.3 to develop the recursive realization network, or SYSE.6 to decide the engineered architecture.
A.2.3 defines promise content and its acceptance-facing structure. A.6.P:4.11a recovers the actual referent or relation hidden by service or access wording. Neither pattern selects a provider arrangement.
Organization Change Engineering changes provider organization and capability; Operations Management coordinates continuing provision; and Platform Engineering changes shared enabling Systems and the Methods used to provide or evolve them. Neighboring practices—for example, strategy, commercial analysis, finance, law, safety, security, environmental engineering, or governance—retain their own decisions and authority.
Application profiles retain specialized offering and provider Methods—for example, software, electrical, mechanical, building, ship, transport, medical, industrial, or public-sector Methods—when their subjects, risks, evidence, or working moves differ.