WEB / WEB-20.04

Third-party services and trust boundaries

Trace a provider response through local purpose, validation, and persistence gates.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Validated commit

Request prepared
The adapter prepares the fixed public tea query; the provider has not received it and the local catalog is unchanged.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
Provider request unknown
Local catalog owner
Local draft committed
Provider arrival
The conceptual public query becomes known at provider arrival; the adapter knows no response or validation result yet.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
Public tea query received
Local catalog owner
Local draft committed
Response prepared
The supplied provider fixture prepares its response; ordinary schema drift or error status is declared here, not observed from a real SaaS runtime.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
200 string title prepared
Local catalog owner
Local draft committed
Adapter arrival
The raw response reaches the adapter; schema acceptance and local mutation have not happened and the catalog retains its prior state.
Application caller
Public enrichment pending
Integration adapter
Raw200 bytes received
Provider projection
200 string title prepared
Local catalog owner
Local draft committed
Gate decision
The local status/schema gate evaluates the intended public id and string-title contract; the decision is not a wire message.
Application caller
Public enrichment pending
Integration adapter
Contract accepted
Provider projection
200 string title prepared
Local catalog owner
Local draft committed
Local write
The accepted title is pending in an own SQLite transaction; the independent reader still sees Local draft.
Application caller
Public enrichment pending
Integration adapter
Contract accepted
Provider projection
200 string title prepared
Local catalog owner
Tea note pending commit
Commit visible
After COMMIT an independent connection reads Tea note; observed local persistence does not expand provider authority.
Application caller
Enrichment committed
Integration adapter
Contract accepted
Provider projection
200 string title prepared
Local catalog owner
Tea note committed

Schema drift

Request prepared
The adapter prepares the fixed public tea query; the provider has not received it and the local catalog is unchanged.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
Provider request unknown
Local catalog owner
Local draft committed
Provider arrival
The conceptual public query becomes known at provider arrival; the adapter knows no response or validation result yet.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
Public tea query received
Local catalog owner
Local draft committed
Response prepared
The supplied provider fixture prepares its response; ordinary schema drift or error status is declared here, not observed from a real SaaS runtime.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
200 numeric title prepared
Local catalog owner
Local draft committed
Adapter arrival
The raw response reaches the adapter; schema acceptance and local mutation have not happened and the catalog retains its prior state.
Application caller
Public enrichment pending
Integration adapter
Raw200 bytes received
Provider projection
200 numeric title prepared
Local catalog owner
Local draft committed
Gate decision
The local status/schema gate evaluates the intended public id and string-title contract; the decision is not a wire message.
Application caller
Public enrichment pending
Integration adapter
Contract mismatch
Provider projection
200 numeric title prepared
Local catalog owner
Local draft committed
Preserve result boundary
The selected error category becomes caller state; local catalog commit count stays0 and Local draft remains.
Application caller
Error; no new success
Integration adapter
Contract mismatch
Provider projection
200 numeric title prepared
Local catalog owner
Local draft committed

Provider error

Request prepared
The adapter prepares the fixed public tea query; the provider has not received it and the local catalog is unchanged.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
Provider request unknown
Local catalog owner
Local draft committed
Provider arrival
The conceptual public query becomes known at provider arrival; the adapter knows no response or validation result yet.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
Public tea query received
Local catalog owner
Local draft committed
Response prepared
The supplied provider fixture prepares its response; ordinary schema drift or error status is declared here, not observed from a real SaaS runtime.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
503 error prepared
Local catalog owner
Local draft committed
Adapter arrival
The raw response reaches the adapter; schema acceptance and local mutation have not happened and the catalog retains its prior state.
Application caller
Public enrichment pending
Integration adapter
Raw503 bytes received
Provider projection
503 error prepared
Local catalog owner
Local draft committed
Gate decision
The local status/schema gate evaluates the intended public id and string-title contract; the decision is not a wire message.
Application caller
Public enrichment pending
Integration adapter
Provider unavailable
Provider projection
503 error prepared
Local catalog owner
Local draft committed
Preserve result boundary
The selected error category becomes caller state; local catalog commit count stays0 and Local draft remains.
Application caller
Error; no new success
Integration adapter
Provider unavailable
Provider projection
503 error prepared
Local catalog owner
Local draft committed

Response unknown

Input prepared
The fixed local unknown-outcome case starts; no real network send or provider delivery is observed.
Application caller
Public enrichment pending
Integration adapter
Public tea query prepared
Provider projection
Provider result unknown
Local catalog owner
Local draft committed
Adapter attempt
The direct adapter enters the supplied TimeoutError fixture; it obtains no new information about remote completion.
Application caller
Public enrichment pending
Integration adapter
Local call attempted
Provider projection
Provider result unknown
Local catalog owner
Local draft committed
No response
The injected exception leaves the adapter without a status or body observation; it is not a real deadline measurement.
Application caller
Public enrichment pending
Integration adapter
No response observed
Provider projection
Provider result unknown
Local catalog owner
Local draft committed
Keep unknown distinct
An unknown response is not converted into provider503 or schema mismatch; no automatic retry or local mutation occurs.
Application caller
Public enrichment pending
Integration adapter
response-unknown
Provider projection
Provider result unknown
Local catalog owner
Local draft committed
Caller knowledge
The caller observes the selected unknown result; Local draft stays unchanged and provider completion is not asserted.
Application caller
Unknown; no new success
Integration adapter
response-unknown
Provider projection
Provider result unknown
Local catalog owner
Local draft committed

ACTORS · STATE · DATA FLOW

Provider contract, local purpose, and ownership

A third-party service supplies an externally managed capability through an API, webhook, library, or browser integration. A SaaS dependency also binds operation, changes, availability, quotas, and retention to the provider contract. A provider name or a successful demo is not evidence of suitability for every application purpose. Record what data leaves, what result returns, and who treats that result as authoritative.

The example sends only the public tea identifier under a fixed catalog-v1 contract associated with the inert catalog-demo alias. catalog.example.invalid is not a real target and the native fixture opens no network. The integration adapter checks status, media type, JSON shape, and expected identifier before touching the local catalog. The provider can supply a title; it receives no authority over private user permissions or account state. This purpose boundary remains distinct from authentication and TLS channel trust.

A SaaS contract version may depend on account defaults, an SDK, or endpoint configuration, with product-specific selection rules. Stripe versioning is a named source example, not a payment API used by this fixture. catalog-v1 is an own teaching-contract alias. Object revision1 differs from API version. If the UI expects a string title but ordinary provider drift returns title7, successful transport still has not delivered a usable application representation.

Arrival, validation, and commit are three distinct events

HTTP status and a provider error body belong to a contract; receiving an external response does not mean a local mutation happened. An adapter can parse a 200 application/json result before checking types, the intended object, or its purpose. The normal branch accepts idtea, titleTea note, and integer revision1, then uses a parameter-bound SQLite write and COMMIT. An independent connection reads the committed title afterward. Provider arrival, validation, and local commit have distinct scene snapshots.

Ordinary schema drift retains 200 but number7 in the title field fails the string gate. The provider-error branch receives 503 with a temporary error and maps it to an own unavailable result without applying the success schema. This mapping is not every vendor error contract. The client does not receive raw upstream diagnostics, stack traces, credentials, or response dumps. Retaining the local Local draft title does not establish a fresh provider result.

The unknown-response branch injects a TimeoutError in the selected local fixture; no network deadline is measured. Since the adapter sees no response, it invents neither a status nor provider completion. A remote side effect with an unknown outcome needs safe retry and idempotency design. This fixture uses only a public read and does not automatically retry. The commit versus caller-knowledge distinction from WEB-19.S01 underlies this boundary. Refusing to turn missing evidence into success is an application decision.

Read every scenario without motion

200, wrong type

The contract is defined first
The requested public id is tea; title must be a string and revision an integer. The contract requires more than status=200.
Provider record
request.id=tea
Contract / local state
title:string / revision:integer
Trust boundary
Acceptance decision pending
A body arrived with 200
SchemaDrift.status=200 arrived, but title=7 in the body does not satisfy the string requirement.
Provider record
status=200 / body.title=7
Contract / local state
Contract not evaluated yet
Trust boundary
Transport outcome and type differ
The schema gate rejected the body
Accepted=false and reason=contract-mismatch show that HTTP success did not make the representation acceptable to this application.
Provider record
status=200 / body.title=7
Contract / local state
accepted=false / reason=contract-mismatch
Trust boundary
Local effect not inspected yet
The local note did not change
LocalAfter=Local draft and commits=0 show no note mutation from the incompatible provider response in this branch.
Provider record
status=200 / body.title=7
Contract / local state
localAfter=Local draft / commits=0
Trust boundary
Provider 200 != local COMMIT
Extra fields are not authority
The contract does not persist unused extra fields. Additional response fields do not grant application permission or private-user authority.
Provider record
status=200 / body.title=7
Contract / local state
unusedExtraFields=ignored, not persisted
Trust boundary
providerCanAuthorizePrivateUser=false
Name the failing layer correctly
This branch stops at schema acceptance rather than HTTP delivery. Report status, acceptance and mutation separately instead of renaming 200 as local success.
Provider record
status=200 / body.title=7
Contract / local state
accepted=false / localAfter=Local draft / commits=0
Trust boundary
Schema rejection

Accept and commit

The normal body matches the contract
The normal body contains tea, Tea note and revision=1. The requested id and types match this selected contract.
Provider record
status=200 / title=Tea note / revision=1
Contract / local state
Local contract decision pending
Trust boundary
Local commit not inspected yet
The representation was accepted
Accepted=true records acceptance of the provider body for local processing. It alone does not establish a completed transaction.
Provider record
status=200 / title=Tea note / revision=1
Contract / local state
accepted=true / localBefore=Local draft
Trust boundary
Acceptance != commit
An independent read during the transaction
IndependentReaderDuring=Local draft shows that beginning local processing is not the same as a separate reader seeing the new title.
Provider record
status=200 / title=Tea note / revision=1
Contract / local state
accepted=true / independentReaderDuring=Local draft
Trust boundary
The old committed value is visible
The commit result is separately recorded
Commits=1 and localAfter=Tea note establish a separate local transaction outcome after provider receipt.
Provider record
status=200 / title=Tea note / revision=1
Contract / local state
commits=1 / localAfter=Tea note
Trust boundary
Local state changed
The later reader saw the new title
IndependentReaderAfter=Tea note separately establishes visibility of the committed title to another connection. It does not change the earlier read retroactively.
Provider record
status=200 / title=Tea note / revision=1
Contract / local state
commits=1 / independentReaderAfter=Tea note
Trust boundary
During=Local draft; after=Tea note
Authority boundary of public enrichment
Even a successful title-enrichment commit does not let the provider authorize a private user. Public data contracts and access-control authority are separate responsibilities.
Provider record
status=200 / title=Tea note / revision=1
Contract / local state
commits=1 / localAfter=Tea note
Trust boundary
providerCanAuthorizePrivateUser=false

ASSUMPTION · BOUNDARY · CONTROL

A trusted channel is not unlimited trust in data

TLS trust supports peer identity and transit integrity; it does not establish that a title has the correct type, intended note, or local purpose. Removing the input gate because a SaaS provider is well known allows even ordinary version drift to break storage or UI invariants. This perspective connects condition, impact, and control: a numeric title fails the string contract before mutation. No vulnerable parser or exploit example is constructed.

Promoting external capability into local authority is a separate boundary error. A public-title provider has no contract to decide user roles or private-object authorization. The fixed request carries only a public id, with no credentials or personal data. Real integration review considers minimization, provider identity, and allowed purposes together. Provider-owned account configuration and retention are not assumed to be application-owned.

Reading errors and unknown outcomes as success

Using status200 as schema validation differs from treating a provider-error body as a success body. An unknown response is neither: there is no status to classify. Each can leave the prior catalog title unchanged, but the reasons remain distinct. Diagnostic categories can differ even when a UI message is shared. The control binds contract mismatch, provider unavailability, and missing observation to a mutation gate without conflating them.

Passing raw provider errors to end users can expose internal topology or sensitive fields, and unnecessary body retention creates another exposure. Native records keep only the selected reason, local title, and commit count. No automatic redirects or arbitrary endpoint choices are demonstrated. Resource and time budgets are defensive source guidance; finite bytes and an injected unknown result do not prove actual timeout enforcement or production robustness.

Read every scenario without motion

Observed 503

A response is known to exist
A fixed local provider adapter supplies status/body observations; an independent SQLite connection supplies commit visibility. These are not logs or network captures proving a remote provider ran. ProviderError records status=503 and an error=temporary body. This branch describes an observed error response rather than no response.
Provider observation
status=503 / body.error=temporary
Local record
Local state not inspected yet
Outcome knowledge
Provider response observed
The local contract did not accept it
Accepted=false and provider-unavailable reject use of the error body as a successful public-note representation.
Provider observation
status=503 / body.error=temporary
Local record
accepted=false / reason=provider-unavailable
Outcome knowledge
Mutation not inspected yet
There is no local commit
Commits=0 and localAfter=Local draft record no commit in this branch; the provider error is not a failed committed transaction.
Provider observation
status=503 / body.error=temporary
Local record
localAfter=Local draft / commits=0
Outcome knowledge
The local note was preserved
Diagnostics are separately bounded
RawDiagnosticsExposed=false records that raw provider diagnostics were not exposed to the user. Recording status does not require sharing the raw message.
Provider observation
status=503 / body.error=temporary
Local record
localAfter=Local draft / commits=0
Outcome knowledge
rawDiagnosticsExposed=false
Keep the 503 within its observed scope
This response is the provider error outcome for the selected request. It does not establish other operations’ state or lasting unavailability.
Provider observation
status=503 / body.error=temporary
Local record
localAfter=Local draft / commits=0
Outcome knowledge
Other request outcomes are unknown
Record the separate outcomes together
Record the observed 503, rejected representation and zero local commits together. Do not replace this known response with the uncertainty of the no-response branch.
Provider observation
status=503 / body.error=temporary
Local record
accepted=false / localAfter=Local draft / commits=0
Outcome knowledge
Known error response

Unknown response

No response was observed
A fixed local provider adapter supplies status/body observations; an independent SQLite connection supplies commit visibility. These are not logs or network captures proving a remote provider ran. Unknown.responseObserved=false and status=null provide neither 503 nor 200. Do not fill status from another branch.
Provider observation
responseObserved=false / status=null
Local record
Local state not inspected yet
Outcome knowledge
Response outcome unknown
Local state stayed unchanged
LocalAfter=Local draft and commits=0 establish the local owner outcome. They do not show that the provider never ran.
Provider observation
responseObserved=false / status=null
Local record
localAfter=Local draft / commits=0
Outcome knowledge
Provider completion is separate
Provider completion is unknown
ProviderCompletionKnown=false separates caller response absence from the claim that the provider did no work.
Provider observation
responseObserved=false / status=null
Local record
localAfter=Local draft / commits=0
Outcome knowledge
providerCompletionKnown=false
A deadline was not measured
TimeoutActuallyMeasured=false records no real network timing measurement. Do not rename status=null as a measured timeout.
Provider observation
responseObserved=false / status=null
Local record
localAfter=Local draft / commits=0
Outcome knowledge
timeoutActuallyMeasured=false
No automatic retry is produced
AutomaticRetry=false is supplied. Unknown provider completion does not establish retry safety; that decision needs contract and effect evidence.
Provider observation
responseObserved=false / status=null
Local record
localAfter=Local draft / commits=0
Outcome knowledge
providerCompletionKnown=false / automaticRetry=false
Preserve the UNKNOWN outcome
Report the unchanged local note alongside unknown provider completion. Substituting one for the other assigns the wrong failure boundary.
Provider observation
responseObserved=false / status=null
Local record
localAfter=Local draft / commits=0
Outcome knowledge
provider completion=UNKNOWN

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Put the integration contract in a boundary ledger

A fixed local provider adapter supplies status/body observations; an independent SQLite connection supplies commit visibility. These are not logs or network captures proving a remote provider ran. Record provider identity alias, intended capability, data classification, expected status and media type, schema version, and local authority together. When a contract changes, review ordinary schema drift and provider errors as well as success fixtures. The strict gate checks requested-id equality, a string title, and an integer revision; unused extra fields are not consumed. This selected policy is not a universal JSON-schema standard and does not automatically sanitize a title for every output context.

If a normal result is persisted locally, observe validation separately from authoritative storage. During the own SQLite transaction an independent reader sees the old title, then Tea note after COMMIT. Invalid responses retain commit count0. This evidence checks a local database relation, not provider delivery, a real handler deadline, or distributed commit. Native expectations are fixed independently rather than loaded from the artifact.

Connect response categories to user effects

Do not present success for contract mismatch, map unavailability to a selected application error, and do not assert remote completion for an unknown outcome. If an old local title exists, retain provenance and freshness information; explicitly describe any chosen stale fallback. This fixture neither presents stale data as new success nor retries an external write. A generic user error can coexist with a distinct internal category without copying an entire provider object into logs or the browser.

The selector looks for the inconsistent combination accepted=false and localCommitted=true. The rejected ledger yields count=0 and the inconsistent positive fixture count=1; missing events remain insufficient evidence. Do not record schema acceptance before response arrival or commit before the local transaction completes. Keep provider status, contract acceptance and local mutation separate for the same request.

NOW APPLY IT TO THE CASE

Are HTTP 200, schema acceptance and local COMMIT the same success?

Atlas enriches its public tea-note title from catalog-demo. The response is evaluated against the contract before the local note changes through its own transaction.

Which components contribute to the case response? Show where UI, service, platform and external-provider outcomes complete along their respective hops.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Provider response / local commit ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "contract": {
    "providerAlias": "catalog-demo",
    "endpointAlias": "https://catalog.example.invalid",
    "apiVersionAlias": "catalog-v1",
    "purpose": "public-title enrichment",
    "request": {
      "id": "tea"
    },
    "dataClassification": "public synthetic only",
    "successStatus": 200,
    "mediaType": "application/json",
    "schema": {
      "id": "requested public id",
      "title": "string",
      "revision": "integer, not boolean"
    },
    "unusedExtraFields": "ignored, not persisted",
    "providerCanAuthorizePrivateUser": false
  },
  "normal": {
    "status": 200,
    "body": "{\"id\":\"tea\",\"title\":\"Tea note\",\"revision\":1}",
    "accepted": true,
    "localBefore": "Local draft",
    "localAfter": "Tea note",
    "commits": 1,
    "independentReaderDuring": "Local draft",
    "independentReaderAfter": "Tea note"
  },
  "schemaDrift": {
    "status": 200,
    "body": "{\"id\":\"tea\",\"title\":7,\"revision\":1}",
    "accepted": false,
    "reason": "contract-mismatch",
    "localAfter": "Local draft",
    "commits": 0
  },
  "providerError": {
    "status": 503,
    "body": "{\"error\":\"temporary\"}",
    "accepted": false,
    "reason": "provider-unavailable",
    "localAfter": "Local draft",
    "commits": 0,
    "rawDiagnosticsExposed": false
  },
  "unknown": {
    "responseObserved": false,
    "status": null,
    "reason": "response-unknown",
    "accepted": false,
    "localAfter": "Local draft",
    "commits": 0,
    "providerCompletionKnown": false,
    "automaticRetry": false,
    "timeoutActuallyMeasured": false
  },
  "limits": {
    "native": "fixed direct adapter + own SQLite + independent response/schema parsing",
    "realThirdPartyApiExecuted": false,
    "browserExecuted": false,
    "realTlsVerified": false,
    "networkDeadlineMeasured": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<audit><integration accepted=\"false\" localCommitted=\"false\"/></audit>",
    "xpath": "count(/audit/integration[@accepted='false' and @localCommitted='true'])",
    "expected": 0,
    "positiveFixtureXml": "<audit><integration accepted=\"false\" localCommitted=\"true\"/></audit>",
    "positiveExpected": 1,
    "scope": "Authored inert decision ledger only; these are teaching fields, not product log or API field names.",
    "missingFieldBehavior": "A missing observation is insufficient evidence; zero matches alone proves no runtime control."
  }
}

contract: Own public capability scope, contract version, and private-authority boundary.
normal/schemaDrift: Response arrival, type gate, and committed local effect differ.
providerError/unknown: Observed status errors and no-response knowledge have different categories.
selector/limits: Local evidence gate; no SaaS, network, browser, or measured deadline.

Actual direct fixed adapter and own SQLite only. Provider messages are conceptual; no external call, TLS check, actual network timeout, or browser run.

Two reality checks

A well-known SaaS and HTTP200 make local data trustworthy.

Peer/channel, expected schema, object/purpose, and local authority require separate gates.

No response provides the same knowledge as provider503 and can default to success.

An unknown outcome has no observed status; completion is not invented and selected local state is preserved.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The provider returned 200 but title is 7. Is selected local persistence updated?

Yes; a trusted provider 200 makes every body field business-valid.
No; contract-mismatch and commits=0.

Read the explained answer

No; contract-mismatch and commits=0. — Required title is not a string, so accepted=false; the local draft stays unchanged.

The response was not observed. Does this evidence justify retry by assuming the provider operation never completed?

Selected lesson artifact fields; teaching example

unknown: {"responseObserved":false,"status":null,"reason":"response-unknown","accepted":false,"localAfter":"Local draft","commits":0,"providerCompletionKnown":false,"automaticRetry":false,"timeoutActuallyMeasured":false}

No; providerCompletionKnown=false and automaticRetry=false.
Yes; every timeout or missing response guarantees no effects.

Read the explained answer

No; providerCompletionKnown=false and automaticRetry=false. — Response loss does not reveal remote completion state; replay-safe operation policy is separately required.

The provider is selected for public-title enrichment. Why can it determine neither private-user authorization nor raw-diagnostic disclosure?

Read the explained answer

ProviderCanAuthorizePrivateUser=false; the local application enforces its own trusted subject/object policy. A selected provider error maps to unavailable with rawDiagnosticsExposed=false. Fixed direct-adapter/SQLite evidence is not a real third-party API/TLS/browser measurement; unused extra fields are not persisted.

□ I did not count external data as private-identity authority.

□ I separated mapped product errors from raw diagnostics.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

OWASP API10:2023 — Unsafe Consumption of APIsIs the API Vulnerable? · How To Prevent
Stripe — VersioningVersioning: major releases and monthly API versions · Versioning: account, SDK and webhook version selection
Stripe — ErrorsHTTP Status Code Summary · Error Types · Attributes
AWS — Shared Responsibility ModelAWS responsibility “Security of the Cloud” · Customer responsibility “Security in the Cloud” · Shared Controls
OWASP — REST Security Cheat SheetHTTPS · Access Control · Input validation · Error handling
SQLite — Transaction2. Transactions · 2.3. Implicit versus explicit transactions
SQLite — IsolationIsolation Between Database Connections

YOUR NOTES / THIS BROWSER

Third-party services and trust boundaries

1. Core · Mechanism

Validated commit

Schema drift

Provider error

Response unknown

Provider contract, local purpose, and ownership

Arrival, validation, and commit are three distinct events

2. Red · Trust & Impact

200, wrong type

Accept and commit

A trusted channel is not unlimited trust in data

Reading errors and unknown outcomes as success

3. Blue · Secure development & defense

Observed 503

Unknown response

Put the integration contract in a boundary ledger

Connect response categories to user effects

Are HTTP 200, schema acceptance and local COMMIT the same success?

Two reality checks

The provider returned 200 but title is 7. Is selected local persistence updated?

The response was not observed. Does this evidence justify retry by assuming the provider operation never completed?

The provider is selected for public-title enrichment. Why can it determine neither private-user authorization nor raw-diagnostic disclosure?

Sources and scope