An organization can know which agent is operating, have a written policy, and provide a place to hold an action while still lacking the basis for a decision. The missing work may be establishing who owns a business condition and what makes the information about it authoritative.
The eight layers discussed here are an analytical view of the eight functions in the KonaSense Runtime AI Governance Framework. They describe connected responsibilities, not eight services, a prescribed execution sequence, or controls required on every path. Their value is helping a team route a governance gap to the people able to resolve it.
An inventory does not settle a policy condition
Hypothetical design exercise: an organization requires the requester's acceptance before an agent may close an internal service ticket. The application is inventoried, and the proposed design includes a point at which closure can be withheld. However, no one has established the authoritative source of acceptance or who is responsible for maintaining it. No ticket is closed and no test is performed for this example.
The inventory helps locate the application and its operator. It cannot decide what “accepted” means in the service process. A ticket comment might contain an expression of satisfaction, an operator's interpretation, or text copied from another source. Finding the word does not establish that the required person accepted the relevant resolution.
NIST's AI RMF Playbook, GOVERN 1.6, addresses maintaining AI system inventories and assigning responsibility for them. That is useful work with a defined purpose. The governance program still needs to connect the known application to the authority and information required by its policy.
Adding another inventory field called “approval required” can document the condition. It does not establish the source that will satisfy it. The team has moved from a discovery question to an unresolved responsibility in the business process.
Establish the meaning before implementing the condition
The service-process owner needs to define which action constitutes acceptance and who may provide it. Is it an authenticated response from the requester, a decision from an authorized delegate, or another explicitly permitted procedure? These are design choices for the hypothetical organization, not requirements for every service desk.
The source also needs a defined relationship to the ticket and resolution under review. Acceptance of an earlier resolution should not silently become acceptance of a materially different one. The process must establish what its record means, who can create or change it, and which conditions make it applicable.
The policy owner and process owner resolve those questions. The integration owner can then determine how the relevant information reaches the evaluator and what the control can do with its decision. One person may hold several roles; the requirement is a clear assignment of authority and responsibility, not a larger organization chart.
NIST GOVERN 2.1 calls for documented roles, responsibilities, and communication paths in AI risk management. Applied to this example, that principle means the person configuring the gate should not have to invent the organization's definition of valid acceptance.
The agent governance architecture guide explains how decision context crosses technical boundaries. Before engineering that connection, the program must establish which source the receiving component is entitled to rely on and what the source is authorized to assert.
More observations can help without supplying the missing authority
Additional observations may reveal that an acceptance record already exists or explain why an existing record is not reaching the evaluator. Instrumentation and investigation can therefore be part of resolving the problem. The distinction is between finding evidence of an established condition and deciding what should count as that condition.
If the process has no agreed source or delegation, collecting a longer conversation cannot make that agreement on the owner's behalf. More accurate extraction of a sentence also does not decide whether its author had authority to accept the work. The observation can inform the review while the authority question remains open.
This is why the next task should be named precisely. “Improve agent visibility” describes a broad area of work. “Establish the acceptance source and the authority for recording it in this ticket process” identifies the unresolved relationship. Once that is settled, an implementation task can specify how to obtain and verify the relevant information.
Keep any valid observations already available. An unresolved condition does not erase the inventory, make every record unusable, or prove that the agent acted improperly. It limits the conclusion the program can reach about whether this proposed closure meets the policy.
Keep an unresolved condition from becoming permission
Within the hypothetical policy, closure requires applicable acceptance. If that acceptance cannot be established, a missing record must not be treated as permission. It also does not prove that the requester rejected the resolution. Those are different conclusions requiring different evidence.
An authorized owner may define a separate exception procedure or reconsider the condition itself. That is an explicit policy decision with its own scope and responsibility. It should not emerge accidentally from an integration that substitutes a convenient field or treats an unavailable value as approval.
A confirmation prompt to the agent operator is not automatically the requester's acceptance. The organization must establish whether that operator can act for the requester and whether the decision covers the relevant ticket resolution. Adding a person to the workflow does not remove the need to define that person's authority.
Until the relationship is established, the team can keep closure outside the automated path under a defined operating restriction. That restriction is a proposed response to the hypothetical gap, not a control tested here. The runtime governance pillar explains the separate work of specifying and verifying how a decision affects the protected operation.
Use the layers to assign the next piece of work
The framework makes the gap visible across responsibilities. Discovery locates the agent and its usage path. The acceptance question concerns the business context and the authority needed to evaluate and decide. The control owner needs a usable answer, and a reviewer needs evidence of what that answer established.
Review the completed handoff against the original requirement. A new field may be populated without an authoritative producer. A documented procedure may exist without a supported way for the controlled path to use its result. If either relationship remains unresolved, keep the gap and its owner visible rather than reporting the policy as operational because each team completed its own task.
The canonical framework contains the eight functions and their diagram. Use it to identify which responsibility must be resolved next, then carry that decision into the relevant process or engineering work. Progress is the ability to support the governed decision within its scope, with an accountable source and an applicable control, rather than a larger inventory or a longer log alone.