WRIT Docs

Prerequisites

#Partitions & Predicates

#The Problem

Once you have entity sets filled with data, you need a way to classify entities — to determine which ones meet a condition and which do not. This classification is what expectations measure against. Without it, you cannot answer "which IT services have an owner?" or "which employees have completed training?"

#How WRIT Handles It

WRIT uses partitions to classify entities. A partition takes an entity set and a predicate (a logical condition), and sorts every entity into one of five branches based on the predicate's three-valued result.

#The Five Branches

Branch Contains Meaning
is_true Entities where the predicate evaluates to True Condition is definitely met
is_false Entities where the predicate evaluates to False Condition is definitely not met
is_known Union of is_true and is_false We have a definite answer (either way)
is_unknown Entities where the predicate evaluates to Unknown Data is missing
is_void Entities where the predicate evaluates to Void Structural impossibility

Every entity in the source set lands in exactly one of is_true, is_false, is_unknown, or is_void. The is_known branch is a convenience union.

#DSL Syntax

partition: "has_owner"
    of: "all_it_services"
    predicate: "owner_email" is known
    when true: "owned"
    when false: "unowned"
    when unknown: "ownership_unclear"
    when void: "__IRRELEVANT__"

The when labels name each branch for display purposes. Use "__IRRELEVANT__" when a branch is not expected to contain any entities.

#Predicates

Predicates are logical expressions that evaluate each entity. They support:

Comparisons:

"salary" is greater than 100000
"status" is "active"
"age" is less than 65

Known/Unknown checks:

"owner_email" is known
"backup_policy" is not known

Logical operators:

"status" is "active" and "owner" is known
"salary" is greater than 100000 or "role" is "executive"

Relationship traversals:

"budget" of "department" is greater than 250000

Existential quantifiers:

there is a svc in "all_services" of "ITService": "owner" of svc is "name"

Conditional expressions:

if "is_critical" then "has_backup_plan" else true

#Worked Example

Given three IT services:

Service owner_email
CRM System alice@example.com
Email Platform (empty)
HR Portal (field not in data source)

Applying the partition "has_owner" with predicate "owner_email" is known:

Service Predicate Result Branch
CRM System True (email is known) is_true ("owned")
Email Platform False (email is empty string, mapped to Unknown... actually depends on sentinel config) Depends on config
HR Portal Unknown (field not collected) is_unknown ("ownership_unclear")

An expectation can then assert: "expect empty: is_false" — meaning no services should lack an owner.

#Chaining Partitions

Partitions can be chained — a second partition can operate on a branch of the first:

partition: "high_earner"
    of: "all_employees"
    predicate: "salary" is greater than 100000
    when true: "high_earners"
    when false: "standard_earners"
    when unknown: "salary_unknown"
    when void: "__IRRELEVANT__"

partition: "senior_high_earner"
    of: "high_earners" of "high_earner"
    predicate: "years_of_service" is greater than 10
    when true: "senior_and_well_paid"
    when false: "junior_and_well_paid"
    when unknown: "tenure_unknown"
    when void: "__IRRELEVANT__"

#Common Pitfalls

  • Forgetting all four branch labels — The DSL requires all four when clauses even if a branch is irrelevant. Use "__IRRELEVANT__" for unused branches.
  • Confusing is_known with is_true — is_known includes both true and false results. It means "we have a definite answer", not "the condition is met."
  • Ignoring is_void — Void entities are structurally impossible cases. If you see unexpected entities in is_void, it usually means a relationship target set is marked exhaustive when it should be partial.