Contextual Evaluation

Contextual evaluation is the process by which Nomotic assesses an action not just on its own merits but against the full context in which it occurs. The same action by the same agent can warrant different governance responses depending on when it happens, what else is happening concurrently, how sensitive the target system is, and where the agent's behavioral trajectory currently sits.

Most governance systems check context sequentially — first check scope, then check rate limits, then check time of day, and so on. Sequential checking misses interactions between context factors. Nomotic evaluates all context dimensions simultaneously in a single pass, which means compounding risk signals — individually borderline factors that together indicate a problem — are detected and reflected in the UCS.

What Counts as Context

Context in Nomotic has four components:

Component	Examples
Situational	Time of day, day of week, active maintenance windows
Behavioral	Agent's recent action history, current drift score, trust trajectory
Environmental	Target sensitivity, governance zone, concurrent activity by this agent
Operational	Rate consumption, active execution handles, workflow position

These are not separate checks. They are the inputs to specific governance dimensions that score in parallel.

How Context Reaches the Dimensions

When runtime.evaluate(action, context) is called, the AgentContext object carries everything governance needs to assess situational factors. The 14 dimensions pull from this context simultaneously:

None of these dimensions waits for another to finish. All 14 scores are produced in parallel and aggregated into the UCS.

Building the AgentContext

The AgentContext is constructed by the calling code — the framework integration, the executor, or the application layer. It carries the agent's identity, trust profile, session history, active constraints, and optional user context.

from nomotic.types import AgentContext, TrustProfile, UserContext

context = AgentContext(
    agent_id="claims-processor",
    trust_profile=runtime.get_trust_profile("claims-processor"),
    action_history=runtime.get_agent_history("claims-processor"),
    active_constraints=["no_bulk_export", "require_confirmation_above_1000"],
    metadata={
        "session_id": "sess_8a3f",
        "workflow_position": 3,
    },
    user_context=UserContext(
        user_id="[e-mail]",
        classification="normal",
    ),
)

verdict = runtime.evaluate(action, context)

The richer the context, the more accurate the governance evaluation. Sparse context means dimensions that depend on history or session data fall back to conservative defaults.

Temporal Context

Dimension 9 (Temporal Compliance) uses wall-clock time and rate state to evaluate timing. Actions during prohibited windows are vetoed. Actions that would exceed rate limits are vetoed. Actions that follow a recent burst of similar actions score lower even if they are individually within limits.

agents:
  my-agent:
    temporal:
      allowed_hours: "06:00-22:00"    # UTC
      rate_limit: 100/minute
      cooldown_after_denial: 30s      # Backoff after a denied action

Concurrent Activity

The Human Override dimension (D12) considers whether the agent currently has other active execution handles — actions that were approved and are currently running. An agent executing five concurrent write operations is in a different context than an agent executing its first action of a session.

active = runtime.interrupt_authority.get_active_handles("my-agent")
print(f"Concurrent executions: {len(active)}")

Target Sensitivity

Not all targets carry the same risk. The Cascading Impact (D5), Stakeholder Impact (D6), and Isolation Integrity (D8) dimensions incorporate target classification into their scores. A write to production/payment_records scores differently from a write to development/test_data, even if the action type is identical.

agents:
  my-agent:
    scope:
      boundaries:
        - production/payment_records     # Hard boundary — veto if crossed
        - pii/*                          # Pattern boundary

Context Profiles

For applications with multiple distinct operational modes, Context Profiles allow switching governance parameters based on detected context — production vs. batch, peak hours vs. off-hours, normal operation vs. incident response.

from nomotic.context_profile import ContextProfile

profile = ContextProfile(
    profile_id="batch-processing",
    allow_threshold_override=0.65,
    weight_overrides={"temporal_compliance": 0.5},
    description="Overnight batch processing context",
)

runtime.context_profiles.register(profile)

Cross-Dimensional Signals

Some governance risks only appear when multiple dimensions show correlated weakness. Nomotic's cross-dimensional detector identifies patterns like:

• Scope assembly — individually minor out-of-scope probes that together suggest boundary testing

• Trust suppression — trust dropping simultaneously with rising action frequency

• Authority escalation — a sequence of authority requests each slightly broader than the last

When cross-dimensional signals are detected, they push ambiguous UCS values toward ESCALATE, even when no individual dimension score would trigger a denial on its own.

verdict = runtime.evaluate(action, context)

if verdict.cross_dimensional_signals:
    for signal in verdict.cross_dimensional_signals:
        print(f"Signal: {signal.pattern} | Severity: {signal.severity}")

:::note Cross-dimensional analysis runs after all 14 dimension scores are computed. It does not replace dimensional scoring — it provides an additional layer of pattern detection for cases where individual scores are not sufficient. :::