Using policies

Policies package focused checks and frame decisions. L3 supplies the hooks that invoke them; the framework does not discover and execute an arbitrary array automatically.

Follow the complete module example

Start with your first policy. Its L3 app gets a named stack, runs policy frame hooks, resolves competing action proposals, records the result, and executes the selected action when one exists.

Its intent export runs policy request checks, resolves their aggregate Boolean, records the audit, and returns that Boolean to the engine.

Keep responsibilities small

A useful policy has a defined input requirement, state identity, and decision scope. The quantity policy checks individual request quantity; it does not become an account-wide exposure allocator because it lives in L3.

Use defining a module and using modules to assemble reusable policy instances. Give independent instances distinct IDs and define what configuration changes mean for their saved runtime state.

Separate proposal, resolution, and execution

A frame result can describe an observation without proposing any action. A proposed action can lose resolution. A selected action can fail execution or remain pending after submission.

Status strings such as watching or cooldown describe policy state; they do not automatically implement time delays or execution reservations. See policy state and lifecycle.

Validate L3-generated actions

Actions submitted by the framework's L3 executor use L3 provenance and bypass the L3 intent hook. Validate their inputs in the policy/resolution path rather than relying on the same intent guard to check them again.

Continue with handling intents. The policy framework guides remain the detailed source for policy contracts and resolution rules.