Skip to main content

Workshed + Loom = Magic

Operational Intelligence Layer — Core Concepts for RABS​

1. Overview​

This chapter defines the Operational Intelligence Layer that powers RABS.
It restores the conceptual framework originally validated in the RABS-POC and formalizes it for the modern system.

The operational layer consists of three tightly-coupled components:

  1. The Workshed — where structure and meaning live
  2. The Loom — where future truth is woven from intent
  3. The Ribbon — where past truth becomes immutable history

This triad is the foundation upon which RABS builds and executes daily operations, manages change, forecasts staffing and transport, and enables audit-safe record-keeping.

2. The Four Primitives (Core Data Model)​

The system is powered by four primitives that represent all operational reality:

2.1 Templates (Persistent Intent)​

Templates represent ongoing truth:

  • Who normally attends
  • What programs normally run
  • What resources and ratios apply
  • Which vehicles are used
  • Which staff are rostered
  • What billing rules apply

These are persistent and can be modified over time.
All changes are:

  • Date-stamped
  • Logged
  • Reversible (conceptually)
  • Reconstructible from history

Templates define the default plan of record.

2.2 Instances (Dated Projected Truth)​

Instances are generated when templates enter the Loom Window.

An instance is:

The template as it applies to a specific date, modified by all intents and current resource state.

Instances:

  • Exist only in the rolling Loom Window (e.g. 6–26 fortnights)
  • Update dynamically when new information arrives
  • Are re-woven whenever inputs change
  • Freeze once the day arrives and then become Ribbon entries

Instances are the operational plan for a specific date.

2.3 Sources (Assets in the Filing Cabinet)​

Sources are the concrete operational objects the system can use:

  • Participants
  • Staff
  • Vehicles
  • Venues
  • Credentials
  • Equipment and other assets

They change over time as employment, needs, or resources evolve.

Sources define what is available to be woven into instances.

2.4 Intents (Calendar Entries)​

Intents are the temporal DNA of the system.

They can modify:

  1. Instances — date-specific changes

    • “Jane is not attending on these two Saturdays.”

  2. Templates — future‑permanent changes

    • “Jane’s last day in this program will be August 16; remove her after this date.”

  3. Sources — asset truth

    • “Bus 4 is unavailable from July onward.”
    • “This staff member can no longer work weekends.”

Intents are logged, dated, and preserved indefinitely.

They allow RABS to:

  • Forecast accurately
  • Apply temporary or long-term changes
  • Alter templates at the correct moment
  • Alter resources at the correct moment
  • Reconstruct historical reality
  • Let Reggie interpret human communications as meaningfully structured events

In short:

Templates, Instances, Sources, and Intents are the four primitives that describe all operational reality.

3. The Workshed (Meaning & Structure Layer)​

The Workshed provides the structured environment where intent is captured and interpreted.

It contains three primary surfaces:

3.1 The Wall (Templates)​

The Wall holds the program templates that represent persistent intent:

  • Activities, programs, and services
  • Default schedules and time blocks
  • Default participants and staff
  • Default vehicles and venues
  • Default capacities and ratios

The Wall answers:

“What do we normally do?”

Templates on the Wall are not immutable.
They change over time, but changes are:

  • Explicit
  • Logged
  • Time‑bounded (“from this date onward…”)
  • Reconstructible

3.2 The Filing Cabinet (Sources)​

The Filing Cabinet stores all assets and reference records:

  • Participant profiles
  • Staff records
  • Vehicle profiles
  • Venue details
  • Capacity rules
  • Equipment inventory

Drawers can hold:

  • Active items (currently in use)
  • Archived items (no longer in use, but important for history)

The Filing Cabinet answers:

“What do we have available?”

3.3 The Calendar (Intents)​

The Calendar holds dated intent:

  • One‑off absences (“Jane will miss the next 2 Saturdays.”)
  • Date‑bound leave and unavailability
  • Resource outages (“Bus 4 is off the road for 3 weeks.”)
  • Future‑effective changes (“This will be Jane’s last day; remove her after this date.”)
  • Global directives (public holidays, closures, etc.)

The Calendar answers:

“What must be true on or after a specific date?”

An intent on the Calendar can modify:

  • A single instance (just that date)
  • A template (change persistent intent from a certain date forward)
  • A source (resource truth from a certain date forward)

This separation is critical:

  • The Wall expresses persistent intent.
  • The Calendar expresses dated intent.
  • Together they define how the world should behave over time.

3.4 Purpose of the Workshed​

The Workshed is where:

  • Humans define programs and services
  • Staff and coordinators record changes and exceptions
  • Reggie and other agents convert unstructured input (emails, SMS, calls, notes) into structured Intents
  • Assets are added, updated, or retired

It provides the Loom with:

  • The structure of operations (Templates)
  • The raw resources required (Sources)
  • The instructions per date (Intents)

The Workshed is the place where intent is captured and organised.

4. The Loom (Temporal Weaving Engine)​

The Loom answers:

“Given everything we know, what will be true on each date in the planning window?”

4.1 The Loom Window​

The Loom operates over a rolling planning window, e.g.:

  • 6–26 fortnights (two‑week slices), or
  • Any flexible N‑week forward projection.

Within this Loom Window:

  • Relevant Templates are projected into dates as Instances
  • All applicable Intents are applied to those Instances
  • Current Source state is taken into account

The window can safely expand or contract because:

  • Templates are stored outside the window as persistent definitions
  • Intents span all time (past and future)
  • Instances inside the window can always be regenerated from Templates + Intents + Sources

4.2 Weaving Process​

For each date D in the Loom Window:

Instance(D) =
  Template(s) active on D
  + All Intents targeting D
  + Source state valid on D
  + Policy and compliance constraints
  + Ratio and capacity validation
  + Resource availability (staff, vehicles, venues)
  + Any relevant global rules (e.g. holidays)

The result is a set of Instances for that date representing:

  • Who is rostered
  • Which participants are attending
  • Which vehicles and venues are used
  • What activities are running
  • What should be billed and to whom

This is the best current prediction of operational reality for that day.

4.3 Reweaving​

As new information arrives, the Loom can reweave:

  • New or modified Intents (e.g. new absences, cancellations, or future changes)
  • Changes to Templates (program design changes, ratio changes, etc.)
  • Changes to Sources (new staff, retired vehicles, changed supports)
  • Policy updates and new validation rules

When reweaving:

  • Instances within the Loom Window may be recomputed
  • Conflicts (e.g. overbooked staff or vehicles) are detected and surfaced
  • Reggie or human operators can be asked to resolve conflicts

Reweaving ensures:

  • Forecasts grow more accurate as time approaches
  • The system adapts to evolving reality

4.4 Freezing and Hand‑off to the Ribbon​

When a date D is reached (and past):

  • Instances for D become frozen
  • They are written into the Ribbon as immutable history
  • RABS uses these frozen records for:
    • Billing and financial reconciliation
    • Payroll and attendance
    • Compliance and auditing
    • Operational analytics
    • Training data and feedback for Reggie

From that point, D is no longer part of the Loom Window.
It is part of the historical ledger.

5. The Ribbon (Immutable History)​

The Ribbon represents the braided history of the organisation:

  • Each day is a segment of the Ribbon
  • Each segment contains the final, frozen Instances for that day
  • Each instance links:
    • Template used
    • Intents applied
    • Sources involved
    • Resulting attendance
    • Financial and billing outcomes
    • Any incidents, notes, or exceptions

Once written, Ribbon entries are:

  • Immutable
  • Audit‑safe
  • Reconstructible
  • Traceable back to the configuration and intents in place at the time

The Ribbon is the source of truth for:

  • NDIS audits
  • Random sampling and QA
  • Participant journey histories
  • Staff work histories
  • Vehicle and venue utilisation
  • Organisational analytics

It is also a key surface for Reggie’s learning, letting the intelligence layer see:

  • What actually happened
  • How that compares to what was planned
  • Which Intents and decisions led to good or bad outcomes

6. Worked Examples​

6.1 Temporary Absence (Intent → Instance)​

Scenario:

Jane normally attends Saturday Adventure every week.
She will miss the next two Saturdays due to illness.

Representation:

  • Template:
    • “Jane attends Saturday Adventure.” (persistent)
  • Intents (Calendar):
    • “Jane absent on [Date1].”
    • “Jane absent on [Date2].”

Effect:

  • Instances for Date1 and Date2 are woven without Jane
  • Template remains unchanged
  • Future instances beyond those dates include Jane as normal

6.2 Permanent Departure (Intent → Template)​

Scenario:

Jane is moving to France.
Her last Saturday Adventure is August 16.
After that, she will never attend this program again.

Representation:

  • Template:
    • “Jane attends Saturday Adventure.” (until changed)
  • Intent (Calendar):
    • “On August 16, this is Jane’s last day.
      After this date, remove her from the template.”

Effect:

  • Instances up to and including August 16:
    • Jane appears as normal (subject to any separate absence Intents)
  • After August 16:
    • Template is updated
    • Future Instances no longer include Jane
    • Loom does not attempt to roster her or bill for her
  • Historical reconstruction:
    • The timeline clearly shows when and why Jane stopped attending

6.3 Resource Change (Intent → Source)​

Scenario:

Bus 4 is being retired from service from July 1 onward.

Representation:

  • Source (Filing Cabinet):
    • “Bus 4” as a vehicle asset
  • Intent (Calendar):
    • “Bus 4 unavailable from July 1.”

Effect:

  • Instances for dates before July 1:
    • May still use Bus 4
  • Instances on and after July 1:
    • Loom selects alternative vehicles
    • Any conflicts (e.g. insufficient capacity) are surfaced
  • Template:
    • May remain unchanged unless explicitly updated
  • Historical reconstruction:
    • Bus 4’s last date of use is clear and auditable

7. Why This Architecture Works​

The Workshed/Loom/Ribbon model provides:

  • Separation of concerns:

    • Workshed captures and organises intent and structure
    • Loom projects that structure through time
    • Ribbon stores the final outcome

  • Temporal clarity:

    • Past, present, and future are clearly distinguished
    • You can always answer “What was true then?” and “What will be true if nothing else changes?”

  • Auditability:

    • Every change to Template, Source, and Intent is logged
    • Every day’s final state is frozen and traceable
    • It is always possible to reconstruct why something happened

  • Adaptability:

    • Adding or modifying Intents does not require rewriting the past
    • The Loom Window can expand or contract without losing information
    • The system can respond to illness, outages, client changes, and policy shifts

  • AI‑readiness:

    • The structure is ideal for Reggie’s Brainframe to:
      • Interpret human communications as Intents
      • Attach Reason Tags and Context Buckets to operational events
      • Learn from the Ribbon as a source of “what actually happened”

8. Preparing for Reggie Integration​

When combined with the Brainframe:

  • Incoming unstructured signals (emails, SMS, call notes, shift reports) can be analysed and turned into structured Intents.
  • Reggie can explain why the system made certain decisions by tracing:
    • Template state
    • Intents
    • Source constraints
    • Loom operations
    • Ribbon history
  • Reggie can propose or even automate new Intents when:
    • Conflicts or risks are detected
    • Patterns of cancellations or failures emerge
    • Policy breaches or near‑misses appear in the Ribbon

This operational layer is therefore the bridge between:

  • The intelligence layer (Reggie / Brainframe)
  • And the execution layer (RABS operations, billing, transport, rostering, and audits)

It ensures that as the system grows more intelligent, it remains:

  • Grounded in reality
  • Auditable
  • Compliant
  • Explainable

And most importantly:

It ensures that the organisation’s plans, actions, and history all speak the same language.