Weight access
Can the institution inspect the model it is delegating to? Open weights make inspection possible; they do not make it happen. Governance asks whether anyone has looked.
Open weights and the delegation boundary
Ethotechnics takes no side on open or closed weights. It classifies a deployment by nine properties and governs the assembled system, not the model.
Ethotechnics takes no position for or against open weights. It favors architectures in which consequential authority can be inspected, constrained, contested, and reversed, whichever way the weights are distributed.
Open weights move the work of governance from the model provider to the institution that deploys the model. They can make the model easier to inspect, easier to replace, more stable between versions, and easier to withdraw. They also remove the limits a provider sets centrally on how the model is used. Closed weights keep those limits and give up some of the rest.
The method therefore classifies a deployment by nine properties rather than by weight access alone: weight access, runtime control, update authority, version stability, revocation, substitutability, observability, standing, and dependency. Together they make up the deployment's substrate profile: a record of what the institution controls about where and how the model runs. Its schema is not yet published.
A hypothetical case. Two institutions deploy the same open-weight model for benefits triage. The first runs it on its own infrastructure, pins the version, keeps a substitute vendor warm, logs every decision in its own format, and gives applicants a challenge route. The second calls a hosted endpoint for the same model, accepts silent updates, has no substitute, and keeps records only in the vendor's console. The weights are identical. The substrate profiles are not, and the second institution has less governable authority than a well-run closed deployment would give it.
In the glossary: Permission surface.
In practice
What to look for
Runtime control
Who decides where and how the model runs, and can the institution halt it? If a provider holds that control, the institution has handed over authority without ever deciding to.
Update authority
Who can change the model's behavior, and does a change need the institution's approval? An update nobody in the institution approved widens what the system does without anyone deciding it should.
Version stability
Can the institution keep running the version its evidence was gathered on? The evidence that justified using the model holds only for the version that was tested.
Revocation
Can the provider withdraw the model, and can the institution withdraw from the provider? Both ask whether the arrangement can be undone, and what undoing it would cost the institution.
Substitutability
How difficult would it be to replace the model with another? Substitutability is the largest single input to dependence, and open weights can raise it or leave it untouched.
Observability
Can the institution see what the model did, in a form it controls? Observability that lives in a provider's console is observability the institution can lose.
Standing
Who can challenge a decision the assembled system made, and does the challenge reach the system regardless of where the model runs? Standing attaches to the deployment, not to the weights.
Dependency
How far has the institution come to rely on this model and where it runs, and what would withdrawal cost? Dependency is a state of the deployment that weight access neither creates nor removes.
Where the standards use it:
- Laws for engineering delegated intelligence (doctrine). The twelve laws the nine properties are read against. Law I separates capability from authority; Laws V, VI, and XII govern dependence and reversibility.
- Permission surface (explainer). What a system can do without institutional approval, and why that is the first property to measure.
- Frontier doctrine scan (research). Ten frontier labs' published policies and products cover separating capability from authority and correcting errors. They say almost nothing on dependence, standing, or renewing authority.
Does Ethotechnics prefer open or closed models?
Neither. The method classifies deployments, not models. A deployment is more governable when consequential authority can be inspected, constrained, contested, and reversed, and either distribution can score well or badly on that.
Why nine properties instead of open versus closed?
Because weight access is one property and it does not predict the others. An open-weight model served by a third party with silent updates can have less version stability and less runtime control than a closed model under contract. The nine properties separate what weight access bundles together.
Why does freedom to assemble a system raise the bar?
Greater freedom to compose capability requires greater explicitness about delegated authority. When an institution can assemble any model with any tools on any runtime, nothing upstream constrains what the assembled system may do. The constraint has to be stated by the institution, as a grant, or it does not exist.
What do open weights reveal about model-provider governance?
That it was never a sufficient abstraction. Provider-side policy governs the model. It cannot govern the agent the model is wrapped in, the delegation that authorizes the agent, or the institution that depends on it. Open weights make that visible by removing the provider from the loop, but the gap was there in closed deployments too. Governance attaches to the assembled system.
Where will the substrate profile live?
As a forthcoming schema in the object model, attached to a system record alongside the dependency record and the authority grant. Until it is published, the nine properties can be recorded as a table in the safety case.