WRIT Docs

Prerequisites

#Questions & Actions

#The Problem

Detecting misalignment is only useful if it leads to the right response. A service with no owner assigned needs a different response than a service whose ownership data has not been collected. The first is a problem to fix; the second is a data gap to fill. Conflating them wastes effort and sends requests to the wrong people.

#How WRIT Handles It

When expectations are evaluated, WRIT produces two distinct types of output based on the three-valued result:

Result Output Directed To Purpose
False Action The expectee (person responsible) Fix the misalignment
Unknown Question The attestor (data provider) Fill the data gap
True Nothing — Expectation is met

#Actions

An action is generated when an expectation evaluates to False — meaning the condition is definitively not met. Actions are directed at the expectee, the entity responsible for making the expectation true.

From the expectation definition:

expectation: "all_services_owned"
    ...
    expectee: SELF->"owner_lead"
    actions:
        - "Contact GBGF leads to assign service owners"

The expectee is found by traversing a relationship from the entity that failed. SELF->"owner_lead" means: starting from the IT service that has no owner, follow the owner_lead relationship to find who should be contacted.

Multi-hop traversals are supported:

expectee: SELF->"source_namespace"->"service"->"owner"

#Questions

A question is generated when an expectation evaluates to Unknown — meaning the data needed to determine alignment has not been collected or has gone stale.

Questions are directed at the attestor — the person or system that provided (or should provide) the data. The attestor is defined at the attestation source level, not per-attribute, because the person who provides a spreadsheet of services is the person to ask about any missing field in that spreadsheet.

#Staleness and Validity

Attestation data has a validity period defined per attribute:

attribute: "owner_email"
    ...
    validity: 365 days

When data exceeds its validity period, the value transitions to Unknown, and WRIT generates a new question. This ensures that stale data is systematically refreshed.

#Worked Example

Given the expectation "all IT services must have an owner":

Service Owner Evaluation Output
CRM System Alice True (none — aligned)
Email Platform (empty) False Action: "Assign an owner to Email Platform" → directed to the owner lead
HR Portal (not collected) Unknown Question: "What is the owner of HR Portal?" → directed to the services data attestor

Notice the outputs go to different people:

  • The action goes to the owner lead (the person responsible for ensuring services have owners).
  • The question goes to the attestor (the person who maintains the services data spreadsheet).

#Common Pitfalls

  • Expecting actions from unknowns — An unknown does not mean "false". It means "we cannot tell yet". The response is to gather data, not to take corrective action.
  • Missing attestor configuration — If no attestor is configured for an attestation source, questions have no recipient. Always specify who is responsible for each data source.
  • Ignoring validity periods — Without validity periods, data never goes stale and questions are never regenerated. Set realistic validity periods based on how often data changes.