Skip to main content

Guardrails System

Memintel enforces correctness and consistency through a structured Guardrails System. Guardrails define the constraints, compatibility rules, and domain boundaries within which all concepts, conditions, and actions must operate.

They are defined in a separate file: memintel.guardrails.md


Purpose

The guardrails system ensures that:

  • All decision logic is structurally valid
  • Strategies are used correctly
  • Parameters are within valid bounds
  • LLM-generated definitions cannot violate system constraints
  • Decision behavior remains consistent across environments

Without guardrails, systems risk invalid condition definitions, incompatible strategy usage, unstable parameter selection, and non-reproducible decisions.


Core Components

1. Strategy Registry

A centralised registry of all supported decision strategies. Every strategy — threshold, percentile, z_score, change, equals, composite — is a versioned object with a declared input type, parameter schema, and output type. The LLM can only select strategies that exist in this registry.

2. Type–Strategy Compatibility

A compatibility map enforces which strategies are valid for each primitive type.

StrategyValid Input Types
thresholdfloat, int
percentilefloat, int
z_scoretime_series<float>, time_series<int>
changetime_series<float>, time_series<int>
equalsstring, categorical
compositeComposed from other conditions

Incompatible pairings are rejected at compile time.

3. Parameter Constraints

Defines valid ranges and structures for strategy parameters.

StrategyParameterConstraint
thresholdvalueWithin declared bounds
percentilevalue0–100
z_scorethresholdMust be > 0
changevalueWithin declared bounds

These constraints prevent invalid configurations, ensure stable evaluation behavior, and enforce consistency across systems.

4. Domain Constraints

Defines application-specific rules and preferences — acceptable thresholds for certain signals, prioritization rules, and risk tolerance boundaries. These are derived from the application context and system requirements.

5. Hard Constraints vs Soft Guidance

TypeExamplesEffect
Hard ConstraintsType compatibility, required parameters, valid ranges, structural correctnessViolations result in rejection
Soft GuidancePreferred parameter ranges, recommended strategies, domain heuristicsInfluences definition and calibration, but does not block execution

Strategy Selection Priority

When the LLM resolves strategy and parameters during task creation, it follows a strict priority order:

PrioritySourceDescription
1 (highest)user_explicitThreshold or strategy explicitly provided by the user. Always wins.
2primitive_hintStrategy hints declared on the primitive in guardrails.
3mapping_ruleIntent pattern matched to a strategy (e.g. "rises"change).
4application_contextStrategy bias from domain instructions.
5global_preferredGlobally preferred strategies declared in guardrails.
6 (fallback)global_defaultGlobal threshold priors.

The same intent + same guardrails always produces the same strategy and parameters. This is not heuristic inference — it is deterministic compilation.


Relationship to Application Context

Role
Application contextProvides domain understanding, instructions, intent biasing
GuardrailsProvides enforcement, validation, structural constraints

Together: application context guides interpretation, guardrails ensure correctness.


Role in the System

Guardrails operate at definition and validation time — when concepts are created, when conditions are defined, when strategies and parameters are assigned. They ensure that all executable logic is valid, consistent, and deterministic.

At runtime, guardrails are not re-evaluated dynamically — they are already enforced through validated definitions.

Application Context → guides intent
Guardrails → constrain interpretation
Concept → computes meaning
Condition → evaluates via strategy
Action → executes

Key Principles

  1. All strategies must be defined in the strategy registry
  2. All conditions must pass guardrail validation before execution
  3. Type–strategy compatibility must always be enforced
  4. Parameters must conform to defined schemas and bounds
  5. Guardrails separate enforcement from interpretation