Find the vendor lock-in in an architecture

Do not include credentials, secrets, personal data, internal addresses, undisclosed controls or confidential architecture and contract details. Redact them, or use an approved private or local assistant.

Architecture or service description: [redacted description]. Provider being assessed: [provider]. Scope: service/release [version], deployment [profile], operating model [description], relevant agreements and governance [details], customer-control boundary [boundary], review date [date] and exit window [window].

Act as a portability engineer looking for anything that makes leaving slow, costly or impossible. Missing evidence is not proof that a dependency is reversible.

Classify dependencies, without forcing a dependency that spans layers into one category:
- proprietary service or runtime;
- data format, history, metadata, lineage, keys or export;
- API, SDK, schema or semantic definition;
- identity, secrets or control plane;
- hardware, network, operator or deployment target;
- skills, tooling, runbooks or operating process;
- contract, licence, minimum commitment, egress charge, decision right or exit term;
- applicable compliance constraint that affects customer authority or an exit duty.

For each dependency, provide: affected area or areas | effect on the exit | supplied evidence | assumptions and missing evidence | reversal path | portable alternative | effort range and assumptions | exercise that would prove reversibility. State separately whether the organisation has the contractual authority, approvals, duties and supplier support needed to carry out the technical exit.

After the dependency analysis, add a separate heading "Data-ethics considerations" for effects on people or communities that customer governance should discuss. Keep these considerations out of the technical dependency ranking so responsible-use questions are not mistaken for evidence of portability or contractual authority.

Rank the dependencies by the operational loss and time-to-reverse they create, not by rhetoric or provider popularity. Do not call a path easy, portable or sovereign from architecture prose alone. End with the smallest three exercises that would retire the most uncertainty. Do not produce an overall sovereignty score, badge or certification.
---
Use the toolkit as a practical way to examine who can possess, use and dispose of data and the software, hardware and organisational arrangements around it. Keep weak points visible instead of hiding them in one overall judgement.
Examine the organisational side through two complementary perspectives. Data compliance covers applicable rules, contracts, policies, authority, duties and supplier commitments. Data ethics asks whether choices are proportionate, fair, transparent and explainable. Governance operates across both.
Keep compliance questions and data-ethics concerns separate. Leave applicability and legal interpretation to qualified counsel, and do not present ethical considerations as a certification or universal verdict.
Scope every conclusion to the described service, deployment, operating model, agreements, customer boundary and date. Separate supplied facts from assumptions and missing or conflicting evidence. Do not produce an overall score, legal or ethical verdict, or certification.
Data handling: do not include personal data, credentials, secrets or confidential contractual, security or architecture details. Redact them and use an approved private or local assistant when redaction is insufficient.
Background and definitions: https://hoist-it.nl/toolkit
Relevant concepts: https://hoist-it.nl/toolkit/vendor-lock-in  https://hoist-it.nl/toolkit/data-portability