Facts, Logic, and Effects in One Language

So far, we have introduced the core elements of a Spine system:

• Facts describe what is true
• Rules describe how truth can change
• Effects describe what actions are possible
• Invariants describe what must always hold

Each of these ideas is useful on its own.

But the real shift happens when they are no longer separate concerns.

A Fragmented Landscape

In most systems today, these aspects are split across different layers:

• Data models describe structure
• Business logic implements behavior
• Access control defines permissions
• Validation enforces constraints
• Verification, if present, is external

Each layer has its own language, its own tools, and its own assumptions.

As a result, the same concept is expressed multiple times, consistency becomes difficult to maintain, and reasoning about the system as a whole is hard.

A Unified View

Spine takes a different approach.

Facts, logic, and effects are not separate layers — they are part of the same system.

This means:

• Facts are not just stored — they participate in behavior
• Rules are not just documentation — they define valid transitions
• Effects are not just implementation — they are constrained by the model
• Invariants are not just checks — they shape what is possible

Everything is expressed in a single, coherent framework.

Returning to the Asset System

Let's revisit our running example.

We have:

• Facts: Owns(Agent, Asset), PartOf(Asset, Asset)
• Rules: ownership can be transferred
• Effects: TransferOwnership
• Invariants: an asset has at most one owner

Individually, these are simple. Together, they define a system with structure, behavior, and guarantees.

Interaction Between Layers

The important part is how these elements interact.

Facts and Rules

Rules operate over facts: they require certain facts to hold and produce new facts.

Rules and Invariants

Rules must respect invariants: a transfer cannot create multiple owners, and invalid states are not allowed.

Effects and Rules

Effects trigger rules: an effect corresponds to a valid transition and cannot occur unless its conditions are satisfied.

Effects and Facts

Effects are constrained by facts: only an owner may initiate a transfer, and permissions are expressed as facts.

A Coherent System

When these pieces are combined, something interesting happens.

We are no longer dealing with isolated functions, scattered checks, or implicit assumptions.

Instead, we have a system where structure, behavior, and correctness are defined together.

And as we will see, this coherence extends further: not all facts are equal. Some are persistent, others are consumed on use. Resource discipline — tracking how many times each element may be used — will become another dimension of this unified framework.

This makes it possible to reason about the system as a whole.

No Hidden Layers

One of the goals of this approach is to reduce hidden complexity.

In many systems, behavior is hidden in code, constraints are hidden in validation logic, and permissions are scattered across modules.

In Spine, facts are explicit, rules are explicit, effects are explicit, and invariants are explicit.

This makes the system easier to understand, analyze, and evolve.

Composability Across Concerns

Because everything lives in the same framework, composition becomes more natural.

We can extend the fact system (e.g., delegation), refine rules (e.g., conditional transfers), add new effects (e.g., temporary access), and strengthen invariants.

And all of these changes interact in predictable ways.

A Different Way to Think About Programs

This leads to a broader shift:

A program is not just a sequence of instructions. It is a structured description of a system.

In this view, execution is one aspect, correctness is another, modeling is another. But they are all part of the same whole.

Why This Matters

When these elements are unified:

• Fewer inconsistencies arise
• Reasoning becomes more direct
• Verification becomes possible
• Systems become more transparent

This is especially important in domains where correctness matters, rules are complex, and systems evolve over time.

Looking Ahead

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

But real systems rarely do.

Rules may depend on jurisdiction, organizational policies, or environmental conditions. The same action may be valid in one context and invalid in another.

In the next post, we will explore this idea: how the meaning of facts, rules, and effects can depend on context.

This will take us one step closer to understanding how Spine models not just systems, but systems that vary across different domains and interpretations.