PAPER 125 · MODEL STRATEGY AND CONTROL REALISATION

Open Models, Closed Models and the Control You Actually Obtain

A model label describes a release arrangement. Control begins only when a right is permitted, possessed, operable and proven.

Rajesh Ranjan Mahapatra

An executive method for choosing hosted, open-weight and internally operated AI models by testing ten control rights, transferred responsibility, whole cost and irreversibility.

© 2026 Rajesh Ranjan Mahapatra. 22 min read

Open Models, Closed Models and the Control You Actually ObtainAll Research Essays
PAPER 125 · MODEL STRATEGY AND CONTROL REALISATION

Open Models, Closed Models and the Control You Actually Obtain

A model label describes a release arrangement. Control begins only when a right is permitted, possessed, operable and proven.

TLDR

Executive briefThe argument is not open against closed

  • Separate open source, open weights, source available, managed private deployment and hosted closed service before making a control claim.
  • Test ten rights through legal permission, technical possession, organisational capability and exercised evidence; a missing test makes the claimed right unrealised.
  • Price responsibility with control because deployment, modification and security authority transfer operations, assurance, incident and legal duties to the buyer.
  • Compare opposite irreversibilities: hosted access can be withdrawn or changed, while distributed weights and modified safeguards may be impossible to recall.
  • Choose the minimum sufficient control posture for consequence, data, differentiation, evidence and continuity, then re-test it as models and obligations change.

An executive committee announces that it has chosen an open model to gain control. The procurement file contains downloadable weights and a licence. No one can say whether the licence permits the intended commercial field, whether the training information supports the claimed reproducibility, whether the team can patch a discovered vulnerability overnight, or whether the available hardware can restore service inside the recovery target. The organisation possesses an artefact. It has not yet demonstrated control.

The reverse error is equally common. A hosted model is dismissed as uncontrollable because its weights cannot be inspected. Yet its contract can pin a version, reserve a region, grant representative test access, retain evaluation evidence, require release notice, support rollback and assign security response to a staffed provider. For a bounded workflow, those exercisable rights can be stronger than an internal installation that has no overnight operator, no patch path and no independent evaluation. Closed does not mean no control, just as open does not mean complete control.

This paper replaces the binary argument with a business test. It asks what the buyer may do, what it actually possesses, what it can operate and what it has proved. It also asks which duties arrive with each right. The answer can favour a hosted closed model, a managed open-weight runtime, an internally operated open model, a dual-track portfolio or neither option. The decision rule is the bounded outcome, not an identity.

Start with precise release languageFive arrangements that are routinely collapsed into two

Open Source Initiative Definition 1.0 describes Open Source AI through freedoms to use, study, modify and share, together with access to the preferred form for modification. For machine learning, that preferred form includes sufficient training-data information, complete training and running code, and parameters under appropriate terms.1 A weight download without these elements can be useful and legitimately described as open-weight, but it should not inherit every claim made for a fully open system.

Release language must remain separate from deployment language. A permissively licensed model can run in a provider-managed private environment. A source-available model may allow inspection but restrict commercial use. A hosted closed service may offer dedicated tenancy, regional processing and contractual change rights. “Local” describes placement, not necessarily privacy: telemetry, package retrieval, identity, monitoring and support channels can still cross the boundary.

TABLE 1 · RELEASE AND OPERATING ARRANGEMENTS
ArrangementWhat is normally availableControl that still needs proof
Open Source AIUse, study, modify and share freedoms plus the preferred modification formCompute, staffing, security, validation, continuity and exercised recovery
Open-weight releaseDownloadable parameters, sometimes with inference code and documentationTraining provenance, commercial permission, reproducibility and upstream change evidence
Source availableSome code or artefacts visible under specified restrictionsRights to modify, redistribute, deploy by field and retain derivatives
Managed private deploymentDedicated or isolated runtime with selected model and service controlsActual data paths, tenancy, version authority, portability and provider dependencies
Hosted closed serviceInterface access, managed capacity, security operations and contractual serviceIndependent testing, notice, rollback, evidence retention, regional processing and exit
The label is not the decision. Record the exact licence, artefacts, interface, runtime, service terms and responsible parties. Then test the control needed for the business obligation.
Release labels dissolve into ten control rightsOpen and closed labels at the top break apart into ten coloured rights spanning use, inspection, modification, deployment, evaluation, change, security, operation, compliance and exit.OPENCLOSEDUSEINSPECTMODIFYDEPLOYEVALUATECHANGESECUREOPERATECOMPLY +EVIDENCECONTINUEOR EXITcompare rights, not labels
Figure 1. The Ten Control Rights Stack is this article's synthesis. Both release families can realise or withhold particular rights.

Ten Control Rights StackDecompose the control claim before scoring it

A single ownership or openness score conceals the very differences a decision needs. The Ten Control Rights Stack records ten distinct claims. Each right is specific enough to negotiate, design, operate and test. A team can hold strong deployment control and weak inspection control, or excellent evaluation access and poor exit continuity. That shape is more useful than a total.

Use

Permitted purposes, users, geographies, volumes, redistribution and downstream fields. The intended business use must fit the actual licence and contract, including derivative and output conditions.

Inspect

Architecture, weights, training information, code, evaluations, limitations and change history. Visibility may range from complete artefacts to confidential regulator or auditor access.

Modify

Prompts, adapters, fine-tunes, weights, safety layers, runtime and downstream behaviour. Modification authority includes the duty to validate the resulting system.

Deploy

Environment, region, hardware, network, tenancy, data path and availability. Placement decisions must include every service that data, logs and updates touch.

Evaluate

Representative tests, hidden cases, telemetry, reproducibility, independent review and result retention. A benchmark result is not evidence for the buyer's workflow.

Change

Version pinning, update timing, rollback, patching, derivative releases and acceptance. Change control covers model behaviour as well as interface compatibility.

Secure

Access, misuse controls, provenance, vulnerability response, incident evidence and recovery. The right matters only with staffed detection and response.

Operate

Capacity, latency, cost, monitoring, support, scaling, runbooks and specialist staffing. Possessing weights does not reserve accelerators or create an on-call team.

Comply and evidence

Documentation, copyright, privacy, safety, audit, regulator access and accountability. Model-layer material must support, not replace, system-layer duties.

Continue or exit

Availability, substitutes, portability, licence survival, transition, deletion and retirement. Continuity needs a timed route, not a theoretical compatible model.

The stack extends the sourcing choice in Paper 006. That paper decides how build, buy, partnership and open-source routes allocate residual decisions. This paper stays at the model arrangement and asks whether the precise rights needed by one outcome are real. It also differs from Paper 123: model portability is one input here, while that paper traces lock-in across the complete data, workflow, evaluation and operating capability.

TABLE 2 · RIGHTS RECEIPT
RightClaim to recordDecisive receipt
Use and modifyCommercial field, redistribution and derivative permissionsLicence opinion tied to the exact release and planned adaptation
Deploy and operatePrivate region, required capacity and recoveryObserved data path, reservation, runbook and timed recovery exercise
Evaluate and changeHidden tests, notice, pinning, rollback and evidence retentionRepresentative acceptance run against a named version and witnessed rollback
Secure and complyVulnerability, incident, provenance and audit responsibilitiesEvidence pack mapped to provider and buyer owners
Continue or exitLicence survival, substitute, transition and deletionExercised migration with retained evidence and verified termination
Control Realisation TestA claimed control right passes through four gates labelled permission, possession, capability and evidence before reaching realised control.CLAIMEDRIGHTPERMISSIONPOSSESSIONCAPABILITYEVIDENCE✓✓✓✓terms allow itartefacts existteam can acttest succeededONE FAILED GATE = UNREALISED CONTROL
Figure 2. The Control Realisation Test is this article's synthesis. A nominal freedom becomes control only after all four gates pass.

Control Realisation TestPermission, possession, capability and evidence

Permission asks whether the licence and contract allow the action. Download access does not settle commercial use, redistribution, field restrictions, trademark duties, attribution, acceptable-use conditions or the survival of rights after termination. The test must follow the exact model version, adapters, runtime components and distribution path. A legal freedom that applies to one artefact does not silently extend to every dependency.

Possession asks whether the necessary weights, code, training information, interfaces, records and change history are available. The Model Openness Framework treats completeness across model components as distinct from the degree of legal openness.14 This matters because reproducibility can fail even when final weights are available. Conversely, a hosted provider can supply evidence, testing and version records without transferring its weights.

Capability asks whether the organisation has compute, expertise, process, authority and funding to act. A right to patch is not useful when no team can diagnose the fault. A right to deploy anywhere is not continuity when suitable hardware is unavailable. Scarce skills and key-person dependence belong in the control analysis because they determine whether the organisation can exercise the right inside the business time limit.

Evidence asks whether the action has worked in the intended operating context. Run the hidden evaluation, pin the version, roll back the release, fail the telemetry endpoint, rebuild the runtime, switch the model, restore capacity and retain the records. NIST's AI Risk Management Framework and its generative AI profile emphasise context, ownership, measurement and lifecycle treatment across the AI value chain.67 The evidence gate converts a procurement representation into an operating receipt.

Do not average the four tests. If a consequential right lacks permission or evidence, an excellent capability score elsewhere cannot compensate. Record the precise failure and the decision it affects. This preserves a route to cure: amend the licence, obtain the artefact, build the capability or run the test.

Responsibility Transfer MapEvery additional control right has a duty shadow

A buyer that gains deployment, modification or security control may also remove a provider duty. Self-hosting can improve data-path authority while transferring runtime hardening, capacity, observability, patching and recovery. Fine-tuning can create useful differentiation while transferring evaluation, safety configuration, derivative documentation and change governance. The buyer may become responsible for the very evidence it hoped openness would reveal.

The European Commission's current material distinguishes general-purpose model-provider obligations from downstream AI-system requirements. It also explains when modifiers may become providers of new models, while preserving duties for downstream systems regardless of model status.34 The open-source exemptions are specific, not a general removal of accountability, and do not apply in the same way to general-purpose models with systemic risk. The General-Purpose AI Code of Practice adds transparency, copyright, safety and security practices across release arrangements.5

Responsibility Transfer MapOperational, security, evaluation, legal and continuity duties move from provider to buyer as deployment and modification control increases.PROVIDERBUYERRUNTIME + CAPACITYPATCH + VULNERABILITYEVALUATION + SAFETYINCIDENT + EVIDENCERETIREMENT + LIABILITY
Figure 3. The Responsibility Transfer Map is this article's synthesis. Control and duty move together, but upstream information may not move far enough to discharge the new duty.
TABLE 3 · CONTROL AND DUTY PAIRS
Buyer control gainedProvider duty that may shrinkBuyer evidence needed
Private deploymentRuntime availability, network defence and capacity responseHardened build, reserved capacity, monitoring and recovery exercise
Weight or safety-layer modificationBehavioural assurance and standard safeguard maintenanceChange-specific evaluation, abuse testing and derivative record
Version authorityAutomatic patching and standard lifecycle managementVulnerability intake, patch decision, revalidation and retirement plan
Independent security controlCentral misuse detection and incident coordinationTelemetry coverage, response authority and evidence preservation
Long-term continuityProvider operation, support and upgrade pathLicence survival, runnable artefacts, skills, hardware and migration rehearsal

Control Realisation Cost LedgerThe free weight can be the smallest line

Acquisition and inference charges are visible, comparable and often misleading. A control posture also pays for infrastructure and energy, adaptation, integration, evaluation, independent assurance, security engineering, monitoring, capacity, support, specialist people, documentation, patching, revalidation, migration, retirement and residual liability. Some of these costs purchase strategic option value. Others are undifferentiated work that a provider can perform more reliably across many customers.

The ledger does not assume that internal operation is expensive or hosted service is economical. It requires both to be costed under the same workload, consequence and evidence envelope. A stable, high-volume task with available skills may favour internal operation. A volatile frontier task with severe availability requirements may favour managed service. A provider's headline token price and an open model's licence price are both incomplete denominators.

Control Realisation Cost LedgerA small weights cost at the top reveals accumulating layers for compute, skills, assurance, security, change and exit.ACQUISITION + LICENCECOMPUTE + ENERGYADAPTATION + SKILLSEVALUATION + ASSURANCESECURITY + OPERATIONSPATCHING + CHANGEMIGRATION + EXIT + RESIDUAL LIABILITY
Figure 4. The Control Realisation Cost Ledger is this article's synthesis. Weight possession reveals, rather than removes, operating cost.
TABLE 4 · WHOLE-COST RECONCILIATION
Cost lineHosted closed questionOpen or open-weight question
Runtime and capacityAre reservation, region, latency and surge terms included?Are hardware, energy, scaling and recovery capacity available?
People and assuranceWhat testing, support and evidence remain buyer work?Can the buyer staff evaluation, security and on-call operation?
ChangeWhat is the cost of notice, pinning, migration and provider updates?What is the cost of patch triage, revalidation and derivative governance?
ComplianceWhich upstream documents and audit rights are supplied?Which provenance and development facts remain unavailable?
Exit and liabilityWhat transition, deletion and substitute costs survive termination?What retirement, licence and residual misuse duties survive distribution?

Irreversibility MapControl can be lost in opposite directions

A hosted provider can withdraw access, deprecate a version, alter behaviour or change commercial terms. Central operation can also patch a vulnerability, block abuse and restore capacity across customers. The buyer's concern is dependence on another party's continuing service and change discipline.

Widely distributed weights can preserve access after the original provider disappears. They support independent research, modification and operation, and may enable private inference without sending input data to a third party. NTIA's report documents these potential benefits while also examining safety, security, accountability and monitoring risks, and it explicitly recommends marginal comparison with alternatives rather than assuming one release form is uniquely risky.2 Once weights spread, however, a provider cannot reliably recall every copy. Embedded safeguards can be altered. A defect, capability or misuse route can remain available outside the original operator's control.

Opposite directions of irreversibilityThe hosted side shows a central provider withdrawing and patching access, while the weights side shows copies spreading beyond recall and safeguards being modified.HOSTED SERVICEDISTRIBUTED WEIGHTSCENTRAL PATCHOR WITHDRAWALCOPYPERSISTSbuyer depends on providerprovider cannot recall every copy
Figure 5. The Irreversibility Map is this article's synthesis. Continuity and recall move in opposite directions.

The correct question is not which arrangement is reversible. Ask which irreversible event matters for the intended use. A confidential internal assistant may prioritise provider withdrawal and private continuity. A broadly distributed capability with removable safeguards may prioritise recall and downstream control. Record the event, affected population, remaining authority, evidence path and accountable owner.

Minimum Sufficient Control DecisionAcquire enough control, and no more unowned duty

Start with seven facts: consequence, data boundary, differentiation, required adaptation, evidence need, operational competence and recovery target. A low-consequence commodity workflow may need strong use terms, basic evaluation and an exit route, but not training-data reproducibility or weight modification. A consequential regulated workflow may require private processing, version pinning, representative testing, retained records and regulator access. That can be satisfied by a managed private deployment if the team does not need to alter weights.

Differentiation changes the case for adaptation. If the model behaviour itself creates strategic value, internal fine-tuning or operation may be justified. If differentiation lies in proprietary data, workflow or customer trust, portable controls around a managed model may preserve more advantage than rebuilding infrastructure. Consequence raises the evidence threshold, not automatically the degree of openness.

Minimum Sufficient Control curveA rising curve matches increasing consequence and differentiation to selected control rights without continuing to maximum ownership.CONSEQUENCE + DIFFERENTIATIONREQUIRED RIGHTScommoditycontrolledcriticaldo not buy unusable control
Figure 6. The Minimum Sufficient Control Decision is this article's synthesis. The curve stops when the obligation is satisfied, not when theoretical ownership is maximised.

The strongest rival

A granular rights analysis can underplay a simple commercial truth. Strong hosted models can outperform local alternatives and remove expensive undifferentiated work. Widely available weights can create practical privacy, continuity and customisation advantages even when upstream openness is incomplete. Organisations must ship useful systems, not win a taxonomy argument.

The answer is proportionality. Test a right only where it changes the bounded outcome, duty or option. Do not demand full training reproducibility when private inference and version stability are the actual needs. Do not accept hosted simplicity where consequential testing and change evidence remain unavailable. Compare capability, latency, reliability, whole cost and control under the same operating conditions, then select the least elaborate posture that clears every non-negotiable gate.

Same-workflow model arrangement comparisonHosted closed, managed open-weight and internally operated open models are compared across capability, data, change, operations and continuity on the same workflow.HOSTED CLOSEDMANAGED OPEN-WEIGHTINTERNAL OPENCAPABILITYDATACHANGEOPERATIONSCONTINUITYcompare within one outcome, dataset and evidence envelope
Figure 7. Same-workflow comparison prevents headline benchmarks or ideology from deciding a different operating problem.
TABLE 5 · POSTURE SELECTION GATES
PostureBest fitNon-negotiable gate
Hosted closed under strong termsFast-changing capability and demanding operations with negotiable evidenceRepresentative test access, change control, data terms and credible exit
Open-weight in managed private runtimePrivate inference and version control without internal infrastructure burdenVerified isolation, licence fit, provider responsibilities and portability
Internally operate and adapt an open modelDifferentiating adaptation with durable operating competenceFull rights, staffed assurance, patching, capacity and recovery evidence
Dual-track portfolioFrontier reasoning and sensitive stable tasks need different arrangementsCommon evaluation, policy, identity, evidence and fallback contracts
Reject bothNo option satisfies a consequential right or accountable dutyDo not scale until permission, artefact, capability or evidence gap closes

Ten worked casesFollow the whole stack, not the appealing first fact

1. Weights without reproducibility

A research team receives permissively licensed weights and inference code. Use, basic inspection, modification and deployment permissions are strong. Possession fails for training-data information, preprocessing code, checkpoints and development evaluations. The team has compute for inference but not retraining, and it has never reconstructed the reported results. The Responsibility Transfer Map assigns runtime security, evaluation and change control to the buyer, while upstream provenance remains incomplete. The cost ledger includes independent evaluation and documentation remediation. Distribution is already irreversible, but continuity is credible for the existing artefact. Decision: use an open-weight model in a managed private runtime for bounded inference, while rejecting the claim of reproducibility and barring uses that depend on it.

2. Research permission blocks the commercial field

A team identifies a strong open-weight model for a customer product. Inspection and technical modification are possible, but the licence permits research and blocks the intended commercial field and redistribution. That permission failure stops the use and exit rights before technical quality matters. Possessing the weights cannot cure it. The team could negotiate another licence, select a genuinely compatible release or buy a service with express commercial rights. Engineering effort spent before clearing the licence would become stranded cost. Decision: reject the open-weight arrangement and use a hosted closed model under strong commercial, evaluation and change terms if it passes the same workflow tests.

3. Regulated private inference without weight modification

A regulated investigations team needs regional private processing, version pinning, hidden evaluation, evidence retention and a recovery target. It does not need to alter weights. A managed private deployment supplies dedicated tenancy, documented data paths, controlled updates and rollback, while the provider retains staffed runtime and vulnerability operations. The buyer owns scenario evaluation, human authority and system-level compliance. The arrangement passes deployment, evaluation, change and evidence needs without transferring infrastructure duties the team cannot staff. Decision: use an open-weight model in a managed private runtime and retain portable tests, logs and policy outside the provider environment.

4. Closed service is more controllable in operation

A hosted closed provider grants representative test access, a named version, release notice, rollback, regional processing, reserved capacity and incident evidence. The internal alternative exposes weights and code but has no round-the-clock operator, weak vulnerability intake and no validated surge capacity. The hosted option has less inspection and modification, yet the rights that matter for the bounded service are permitted, staffed and exercised. Whole cost includes provider charges but avoids an unreliable internal operating layer. Decision: use the hosted closed model under strong control terms. Record inspection limits and maintain an exit rehearsal rather than pretending the less operable option offers more control.

5. Local inference with an external telemetry path

A model runs on the buyer's hardware, so the project describes it as private. Network observation shows runtime telemetry, package checks and support diagnostics reaching external services. Deployment possession is local, but data-path evidence fails. Security responsibility is fragmented between internal infrastructure, an inference package maintainer and a monitoring vendor. The cost ledger adds replacement telemetry, offline update distribution and validation. Decision: operate internally only after disabling or controlling every external path, documenting package provenance and proving the isolated recovery process. “Local” is not accepted as privacy evidence.

6. Fine-tuning creates a new duty surface

A product team fine-tunes an open-weight model and modifies its safety layer. The licence permits the work, artefacts are present and the team can train the adapter. The new behaviour invalidates upstream evaluation and transfers safety testing, vulnerability response, derivative documentation, version governance and incident analysis. European Commission guidance also makes the scale and nature of modification relevant to model-provider status, while system duties remain.3 NIST SP 800-218A supports explicit provenance, component and secure-development practices.8 Decision: operate and adapt internally only if the derivative evidence pack, security response and revalidation cadence are funded and assigned.

7. A model alias changes behind the contract

A hosted provider updates behaviour behind an unchanged alias. Interface tests pass, but refusal patterns and answer calibration change. The buyer's acceptance evidence no longer identifies the operating model. Evaluation and change rights fail because the contract lacks version pinning, adequate notice and rollback. The repair is not necessarily weight access. It is a named-version service, behavioural change notice, retained test results and authority to delay acceptance. Decision: keep a hosted model only after strong change terms are added; otherwise move the bounded workflow to a managed open-weight runtime with pinned artefacts.

8. Weight continuity meets hardware scarcity

A provider leaves the market, but the buyer retains lawful weights and code. Continue-or-exit permission and artefact possession survive. Recovery still misses its target because the model needs scarce accelerators, a specialist kernel and two people who understand the deployment. The control claim fails capability and evidence. Capacity reservation, a documented lower-resource mode and cross-trained operators enter the cost ledger. Decision: retain the open artefact as continuity leverage but use a dual-track portfolio until a timed internal recovery proves that hardware, skills, evaluation and authority can stabilise service.

9. Removable safeguards make distribution unacceptable

A model's useful capability is bundled with safeguards that can be removed after weight release. The proposed audience is broad, consequences are severe and downstream copies cannot be recalled. The arrangement offers strong modification and continuity but weak control over redistribution, misuse response and retirement. A hosted interface can enforce access, rate, monitoring and withdrawal controls, although it still needs independent evaluation and evidence. Decision: reject open-weight distribution for this use and choose a hosted controlled service only if the residual misuse and oversight gates pass.

10. Two models under one portable control contract

A company needs frontier reasoning for bounded research and stable private inference for sensitive operations. It uses a hosted closed model for the first and an internally operated model for the second. Both sit behind common identity, policy, prompt classification, evaluation cases, telemetry semantics, human authority and evidence retention. The portfolio does not pretend the models are interchangeable. It preserves a degraded route for each workflow and rehearses movement only where capability and safety remain acceptable. Decision: use a dual-track model portfolio with portable controls and separate operating receipts for each path.

These cases show why model cards, system cards, licences and benchmarks are inputs rather than operating proof. AISI's open Inspect framework demonstrates how evaluation tooling can itself be portable and inspectable, while its frontier trend reporting compares capability and safeguard developments across model access arrangements.910 Stanford's transparency work and the 2025 Foundation Model Transparency Index show that disclosure varies across upstream, model and downstream dimensions.1115 The buyer therefore needs its own rights receipt even when provider documentation is strong.

Interactive instrumentModel Control Realisation Board

Choose the conditions for one bounded outcome. The board does not calculate a universal openness score. It routes missing permissions, artefacts, capability and evidence to one of five distinct postures, and it exposes the responsibility, cost and irreversibility that accompany the choice.

Model Control Realisation Board flowBusiness need enters ten rights, passes four realisation tests and responsibility, cost and irreversibility checks before five possible model postures.BOUNDEDOUTCOMETEN RIGHTSuse · inspectmodify · deployevaluate · changesecure · operatecomply · exitFOUR TESTSpermissionpossessioncapabilityevidenceDUTYCOSTIRREVERSIBILITYCONTINUITYFIVEPOSTURES
Figure 8. The Model Control Realisation Board is this article's synthesis and turns rights, responsibilities and evidence into a live decision.

Operating cadenceKeep the receipt current

At initial selection, the capability owner states the outcome, affected population, consequence and recovery target. Legal and procurement record the use, modification, change and exit permissions. Architecture and security trace the actual data, telemetry, update and incident paths. Evaluation runs representative and hidden cases against the named version. Finance reconciles the whole-cost ledger. The accountable executive accepts only the rights and duties that have evidence.

At each material model, licence, provider, runtime, workload or regulatory change, rerun the affected rights. A model card update does not prove the production behaviour. A new weight does not inherit the old derivative's evidence. A contract renewal does not preserve a neglected exit path. Periodically exercise the hardest right: rollback a hosted version, rebuild an internal runtime, recover without an external telemetry service or switch a bounded workflow through the portable control layer.

Competition authorities add another reason to preserve precise rights. The UK Competition and Markets Authority highlights access, diversity, deployment options and switching in foundation-model markets, while the US Federal Trade Commission discusses key inputs, bundling, switching and the possibility that firms change their openness strategy over time.1213 Openness can improve competition, but it is not diversification when the same cloud, runtime, data or skills remain common.

The final board record should be plain: these are the rights we need; these are the permissions and artefacts we possess; these are the controls we have exercised; these are the responsibilities we own; this is the whole cost and irreversible exposure; this is the next gate. Anything less turns a release label into borrowed confidence.

Evidence spineSources checked 3 September 2026

  1. Open Source Initiative, The Open Source AI Definition 1.0.
  2. US NTIA, Dual-Use Foundation Models with Widely Available Model Weights Report.
  3. European Commission, General-Purpose AI Models in the AI Act: Questions and Answers.
  4. European Commission, Guidelines on the Scope of Obligations for Providers of General-Purpose AI Models.
  5. European Commission, General-Purpose AI Code of Practice.
  6. NIST, Artificial Intelligence Risk Management Framework.
  7. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.
  8. NIST, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, SP 800-218A.
  9. UK AI Security Institute, Frontier AI Trends Report.
  10. UK AI Security Institute, Open-Sourcing Our Testing Framework Inspect.
  11. Stanford HAI, Transparency in AI Is on the Decline.
  12. UK Competition and Markets Authority, AI Foundation Models Update Paper.
  13. US Federal Trade Commission, Generative AI Raises Competition Concerns.
  14. White et al., The Model Openness Framework.
  15. Wan et al., The 2025 Foundation Model Transparency Index.
  16. Kapoor et al., On the Societal Impact of Open Foundation Models.
  17. Liu et al., Instella: Fully Open Language Models with Stellar Performance.
  18. Widder et al., Open AI in the Wild: Adoption and Adaptation of Open Models on r/LocalLLaMA.

About this paperRelease description is not operating control

The Ten Control Rights Stack, Control Realisation Test, Responsibility Transfer Map, Control Realisation Cost Ledger, Irreversibility Map, Minimum Sufficient Control Decision and Model Control Realisation Board are this article's synthesis. They combine licensing, model artefacts, deployment, evaluation, operations, accountability and continuity without treating open source, open weights, source availability, private deployment or hosted service as automatic proof of control.