Purpose
Sharing an external reference model that may help clarify how runtime governance layers relate to the security primitives defined in CoSAI and to the personas and controls that WS3 is shaping. This isn’t a proposal for incorporation — the goal is to support discussion by offering a concrete example of how certain boundaries and responsibilities can be articulated.
1. Context
Several threads in recent meetings have highlighted the need to distinguish:
- CoSAI’s security invariants (signing, attestation, integrity, logging),
- WS3’s risk-governance responsibilities (personas, controls, mappings),
- and the runtime layer that sits between them.
To help surface that structure, I’m providing a reference model that illustrates one way the runtime envelope can be framed relative to the underlying security substrate. This may be useful as WS3 refines personas, responsibilities, and cross-framework mappings.
2. Why this may be useful
A runtime governance profile provides:
- a stable “middle layer” between security primitives and the model core,
- a place where refusal logic, traceability, safety posture, domain detection, and context-integrity controls can be reasoned about,
- and a clear separation of responsibilities that aligns with the persona work currently underway (Issue #109).
An example makes the boundary easier to discuss. The specifics are less important than the structure.
3. Boundary placement model (informative)
+-----------------------------------------------------------+
| Organizational Governance |
| (NIST AI RMF, ISO 42001, law, policy, risk appetite) |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| Security Primitives |
| (CoSAI, platform security, cryptographic substrate) |
| - Model signing / attestation |
| - Runtime integrity / anti-bypass |
| - Immutable logging substrate |
| - IO boundary controls / sandboxing |
| - Secure governed-source retrieval |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| GEN-FIT™ Runtime Governance Envelope |
| - P0 deterministic envelope |
| - P1 binding / domain detection |
| - §4 normative principles |
| - Protective/containment modes |
| - Context integrity and sensitive-data governance |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| Model Core |
| (LLM / agent / tool engine) |
+-----------------------------------------------------------+
|
v
+-----------------------------------------------------------+
| User / External Interface |
+-----------------------------------------------------------+
This diagram is offered as an example structure for discussion.
4. Relation to the persona expansion work (Issue #109)
The expanded persona model provides clearer ownership boundaries.
The runtime layer above aligns most naturally with the AI System Governance persona, while remaining dependent on the primitives owned by Model Providers, Platform Providers, and Agentic Framework Providers.
Having a concrete runtime layer to point at may help WS3 map risk/control responsibilities across these personas more cleanly.
5. Reference document
For anyone interested in the details behind the runtime layer shown here, the external reference is:
GEN-FIT v0.5 — Runtime Governance Profile
CC-BY-SA licensed
Relevant sections for WS3 discussions include:
- §1.1 Security Preconditions
- §3.0 Preconditions (deterministic envelope, policy binding)
- §3.4 Threat Model
- §4 Normative Principles
- §8.1 Boundary Placement
Again, this is purely a reference artifact to illustrate a possible decomposition of runtime responsibilities.
6. Questions for WS3 Discussion
These questions are offered to help clarify placement, dependencies, and persona responsibilities as WS3 develops its taxonomy and shared-responsibility model. They incorporate the laddering concept discussed earlier and focus on how runtime-governance concerns intersect with WS3’s scope.
-
Security invariants and dependencies
Which CoSAI security invariants (signing, attestation, runtime integrity, logging guarantees, boundary controls) does WS3 expect runtime-governance responsibilities to depend on, and how explicitly should those dependencies appear in WS3’s risk and control taxonomy?
-
Boundary between primitives and runtime controls
Where does WS3 see the operational boundary between a “security primitive” and a “runtime control,” particularly when a runtime behavior (such as refusal logic, context integrity, or safety-mode transitions) only functions correctly if a lower-level security invariant is reliable?
-
Persona ownership across the ladder
In the expanded persona model from Issue #109, which personas should hold responsibilities at each layer — from the primitives defined by Model and Platform Providers up through the runtime-governance responsibilities associated with AI System Governance?
-
Control mapping and dependency modeling
As WS3 continues mapping risks and controls, how should controls that depend on lower-layer primitives (for example, attestation or boundary-control guarantees) be represented so that the dependency chain remains clear?
-
Distinguishing runtime risks from security risks
Does WS3 intend to distinguish risks rooted in failures of security primitives (attestation failure, boundary bypass, tampered logs) from risks rooted in runtime behavior (inconsistent refusal logic, unsafe mode transitions, loss of context integrity), or should these appear within a unified set?
-
Representing runtime-governance responsibilities within WS3’s model
As WS3 builds out its personas, activities, and control relationships, how should runtime-governance responsibilities be expressed in the overall taxonomy? For example, should runtime behaviors (policy binding, governed context enforcement, refusal behavior, traceability) be treated as:
- distinct control categories within WS3,
- subdivisions of existing control families,
- or responsibilities mapped directly to personas such as AI System Governance?
-
Expressing laddering relationships in WS3 artifacts
Should laddering relationships — where security invariants support higher-level runtime behavior — be expressed explicitly in WS3 artifacts (for example, via dependency relationships between control families), or remain conceptual within documentation?
Closing
I’m happy to clarify any part of the example or adjust my framing if these questions intersect with WS3’s direction differently than I’ve assumed. The intent here is simply to surface questions that may be useful as the group continues refining personas, taxonomies, and boundary definitions. If any of these prompts are misaligned with current thinking, I welcome guidance on how best to orient future contributions.
Purpose
Sharing an external reference model that may help clarify how runtime governance layers relate to the security primitives defined in CoSAI and to the personas and controls that WS3 is shaping. This isn’t a proposal for incorporation — the goal is to support discussion by offering a concrete example of how certain boundaries and responsibilities can be articulated.
1. Context
Several threads in recent meetings have highlighted the need to distinguish:
To help surface that structure, I’m providing a reference model that illustrates one way the runtime envelope can be framed relative to the underlying security substrate. This may be useful as WS3 refines personas, responsibilities, and cross-framework mappings.
2. Why this may be useful
A runtime governance profile provides:
An example makes the boundary easier to discuss. The specifics are less important than the structure.
3. Boundary placement model (informative)
This diagram is offered as an example structure for discussion.
4. Relation to the persona expansion work (Issue #109)
The expanded persona model provides clearer ownership boundaries.
The runtime layer above aligns most naturally with the AI System Governance persona, while remaining dependent on the primitives owned by Model Providers, Platform Providers, and Agentic Framework Providers.
Having a concrete runtime layer to point at may help WS3 map risk/control responsibilities across these personas more cleanly.
5. Reference document
For anyone interested in the details behind the runtime layer shown here, the external reference is:
GEN-FIT v0.5 — Runtime Governance Profile
CC-BY-SA licensed
Relevant sections for WS3 discussions include:
Again, this is purely a reference artifact to illustrate a possible decomposition of runtime responsibilities.
6. Questions for WS3 Discussion
These questions are offered to help clarify placement, dependencies, and persona responsibilities as WS3 develops its taxonomy and shared-responsibility model. They incorporate the laddering concept discussed earlier and focus on how runtime-governance concerns intersect with WS3’s scope.
Security invariants and dependencies
Which CoSAI security invariants (signing, attestation, runtime integrity, logging guarantees, boundary controls) does WS3 expect runtime-governance responsibilities to depend on, and how explicitly should those dependencies appear in WS3’s risk and control taxonomy?
Boundary between primitives and runtime controls
Where does WS3 see the operational boundary between a “security primitive” and a “runtime control,” particularly when a runtime behavior (such as refusal logic, context integrity, or safety-mode transitions) only functions correctly if a lower-level security invariant is reliable?
Persona ownership across the ladder
In the expanded persona model from Issue #109, which personas should hold responsibilities at each layer — from the primitives defined by Model and Platform Providers up through the runtime-governance responsibilities associated with AI System Governance?
Control mapping and dependency modeling
As WS3 continues mapping risks and controls, how should controls that depend on lower-layer primitives (for example, attestation or boundary-control guarantees) be represented so that the dependency chain remains clear?
Distinguishing runtime risks from security risks
Does WS3 intend to distinguish risks rooted in failures of security primitives (attestation failure, boundary bypass, tampered logs) from risks rooted in runtime behavior (inconsistent refusal logic, unsafe mode transitions, loss of context integrity), or should these appear within a unified set?
Representing runtime-governance responsibilities within WS3’s model
As WS3 builds out its personas, activities, and control relationships, how should runtime-governance responsibilities be expressed in the overall taxonomy? For example, should runtime behaviors (policy binding, governed context enforcement, refusal behavior, traceability) be treated as:
Expressing laddering relationships in WS3 artifacts
Should laddering relationships — where security invariants support higher-level runtime behavior — be expressed explicitly in WS3 artifacts (for example, via dependency relationships between control families), or remain conceptual within documentation?
Closing
I’m happy to clarify any part of the example or adjust my framing if these questions intersect with WS3’s direction differently than I’ve assumed. The intent here is simply to surface questions that may be useful as the group continues refining personas, taxonomies, and boundary definitions. If any of these prompts are misaligned with current thinking, I welcome guidance on how best to orient future contributions.