Getting started: submit your first decision request

Introduction to submitting a governed request

A governed request is how actions enter MIDAS. Rather than executing immediately, a request is evaluated at the point where a decision becomes an action. This creates a clear boundary between deciding what should happen and determining whether it is permitted to happen.

Every request defines a decision surface, the calling agent, and the context in which the action will occur. Together, these elements allow MIDAS to assess authority, risk, and intent before execution. Instead of relying on implicit trust in systems or users, each action is treated as something that must be explicitly governed.

This approach is consistent across use cases, whether the request originates from an automated workflow, a rules engine, or an AI-driven agent. The structure remains simple, but the evaluation is deliberate.

Structuring your first request

A typical request includes three core components: what is being attempted, who is attempting it, and the context in which it occurs. The decision surface represents the action, such as approving a payment or issuing a loan. The agent represents the system or actor initiating the request. Context provides supporting information such as amount, confidence, or environmental data.

When submitted, MIDAS evaluates these inputs against the configured authority model. It determines whether the agent has the right to act under the given conditions and whether the request falls within acceptable thresholds.

The result is not just a technical response, but a governed outcome. By introducing this step, execution becomes controlled, consistent, and auditable across all systems.

From request to evaluation

Once a request is received, MIDAS performs a single, atomic evaluation. The system resolves the relevant surface, identifies the agent, and traces the authority chain that governs the action. Context is validated, thresholds are checked, and the request is assessed as a whole.

This process ensures that every action is evaluated in the same structured way. There are no hidden paths or implicit approvals. Each request is treated as a formal entry into a governed system.

By the end of the evaluation, MIDAS produces an outcome that determines what happens next. This outcome becomes the foundation for execution, escalation, or rejection.

Applying governed requests in real scenarios

Governed requests are not limited to a single type of system. The same structure applies whether an action originates from a user interface, a backend service, or an automated agent. What changes is the context, not the model.

In a payment scenario, a request might represent an instruction to transfer funds. The surface defines the action, the agent represents the service initiating it, and the context includes attributes such as amount, currency, and confidence. MIDAS evaluates whether the action is permitted under the current authority configuration before any transfer takes place.

In a lending scenario, the request may represent a loan approval decision. Even if a decision engine determines eligibility, MIDAS governs whether that decision can be executed. This ensures that authority, thresholds, and policy constraints are consistently enforced at the point of action.

Consistent control across systems

One of the key advantages of using governed requests is consistency. Every action, regardless of its origin, is evaluated using the same structured process. This removes ambiguity and reduces the risk of inconsistent enforcement across different systems or teams.

By introducing a single entry point for execution, MIDAS creates a shared control model. Systems no longer need to embed their own fragmented checks or rely on implicit assumptions about authority. Instead, each request is treated as a formal evaluation against a defined governance framework.

This consistency becomes especially important as systems scale. As more agents, services, and workflows are introduced, the need for a unified approach to execution control becomes critical.

Preparing for governed execution

Submitting a request is the first step in introducing governance into your systems. Once requests are flowing through MIDAS, execution becomes observable, controlled, and repeatable. Each action is no longer just performed, but evaluated and recorded.

This shift allows teams to move from implicit trust to explicit control. Instead of asking whether a system should be trusted to act, the question becomes whether a specific action is permitted under the current conditions.

As you begin to integrate MIDAS, start with a small number of decision surfaces and expand gradually. Focus on high-impact actions where governance provides immediate value. From there, the model can be extended across workflows, services, and agents.