Modeling Rules That Depend on Context

So far, we have treated our system as if it exists in a single, fixed setting.

We defined facts, rules, effects, and invariants — and we reasoned about them as a coherent whole.

But real systems rarely operate in a single, universal context.

When Rules Are Not Absolute

Consider a simple statement from our Asset System:

Ownership can be transferred.

At first glance, this seems straightforward.

But in practice, whether a transfer is allowed may depend on:

• Legal jurisdiction
• Organizational policy
• Contractual agreements

For example: in one jurisdiction, certain assets may not be transferable. In another, transfers may require approval. Within an organization, additional restrictions may apply.

The rule is no longer absolute. It depends on context.

The Limits of Conditionals

In many systems, this kind of variation is handled with conditionals:

if country == X, apply rule A
if company_policy == Y, apply rule B

Over time, these conditions accumulate — scattered across code, difficult to track, hard to reason about.

The structure of the system becomes obscured by the logic used to adapt it.

A Layered Perspective

Instead of embedding all variation into conditionals, we can take a different view:

A system can be described in layers.

For example:

• General Layer — basic ownership rules, fundamental constraints
• Jurisdiction Layer — legal restrictions, regulatory requirements
• Organization Layer — company-specific policies, internal permissions

Each layer builds on the previous one.

Specializing Rules

In this layered view:

• The general system defines what is typically allowed
• Additional layers refine or restrict those possibilities

For example: a general rule allows ownership transfer. A jurisdiction layer may restrict transfers of certain assets. An organization layer may require approval before transfer.

Each layer adds meaning.

Context as Part of the System

This leads to an important shift:

Context is not external — it is part of the system itself.

Instead of asking "Which rules should we apply?", we can ask "In which context is this system operating?"

Once the context is known, the applicable rules follow naturally.

Facts, Rules, and Context

This idea applies across the system:

• Facts — what relationships exist may depend on context
• Rules — what transitions are allowed may vary
• Effects — what actions are possible may change
• Invariants — what must always hold may be context-dependent

Context influences everything.

The Asset System, Revisited

Let's extend our example.

We still have Owns(Agent, Asset) and TransferOwnership.

But now:

• In one context, all transfers are allowed
• In another, transfers require authorization
• In a third, some assets cannot be transferred at all

We are not changing the entire system. We are refining it based on where it is used.

Why This Matters

Clarity

Rules are not hidden inside conditionals. They are organized according to where they apply.

Reuse

The general system can be reused across jurisdictions, organizations, and applications.

Composability

Contexts can be layered and combined in predictable ways.

Reasoning

We can ask: what is allowed in this context? How do rules differ across contexts? Are constraints preserved in all cases?

A Subtle Shift

This introduces another shift in perspective: from writing systems with special cases, to describing systems that vary across contexts.

Instead of embedding variation into code, we structure it as part of the model.

Looking Ahead

We have now introduced structure (facts), behavior (rules and effects), correctness (invariants), and variation (context).

In the next post, we will explore how systems evolve over time and under uncertainty: how states change, how behavior unfolds, and how time and probability become part of the model.

And as we move forward, the idea of context will become even more central — eventually leading to a more precise way of describing it.