From Prototype to Pattern

On By konstapelIn Uncategorized

J. Konstapel, Leiden 16-8-2025 All rights reserved.

the source of this blog is socio-panarchie and AyyA and The Come-Back of KayS.

Questions or interested to participate in my project use the contact form.

The Human Heart is in the center.

Interpersonal Theory

The Case is the Center.

Interpersonal Theory is based on the Quaternions of Clerk Maxwell.

Over the last few years, hundreds of notes and blog posts circled around the same question:

what is the simplest shape that holds all of this? With Ayya360 we finally saw it clearly.

The shape is a fractal user interface — a small set of repeating rules that scale from one person to a city, from a single decision to an ecosystem.

This post captures that shape in plain language and turns it into a practical guide you can use after the prototype.

The picture in the middle

At the very center sits interpersonal theory modeled with a quaternion frame (1, i, j, k).

Around it you find a first ring: Fiske’s four relational models — Communal Sharing, Authority Ranking, Equality Matching, Market Pricing. Around that, a second ring of social scales: self, dyad, team, community of practice (which, when it grows, becomes a company), organization, network, city, region, nation, world.

The four culture-independent elationship patterns of Alan Fiske.

That “bullseye” is not a diagram to admire; it is a generator. It tells us how language, decisions, and coordination change as we move outwards while preserving the same inner structure.

What a Fractal UI actually is

A Fractal UI uses a fixed address for every view: Domain → Function → Scale.

  • Domains (6): Identity, Dynamics, Fractals, Data, Collaboration, Infrastructure.
  • Functions (4): Observe, Decide, Act, Learn.
  • Scales (4+): Self, Team, Org, Network (optionally extended with Place: Neighborhood, City, Nation).

The full product surface reduces to 24 endpoints (6×4). Each endpoint has a stable route and test id. That is the contract. Only the labels change with scale and language.

This sounds abstract. In practice, it’s comfortingly predictable:

  • If you switch Domain, you are still looking for Observe/Decide/Act/Learn — just for a different topic.
  • If you change Scale, the semantics broaden (Self → Team → Org → Network) but the actions stay the same.
  • If you move across Function, you step through the same cycle everywhere: Observe → Decide → Act → Learn.

Why 24? Because these are not “features”; they are the endpoints of a fractal expansion that keep their meaning across scales. On a larger scale the names may change (aliases), but the addresses don’t.

The pulsing clock that drives it

Underneath the screens is a small, deterministic loop — think of it as a pulsing clock.

  • The phase (φ) points to a quadrant: O/D/A/L.
  • The radius (r) reflects confidence/cohesion.
  • The scale (σ) marks Self/Team/Org/Network (plus Place, if used).
  • The speed (ω) captures rhythm — how fast we iterate right now.

A tick happens when one of four triggers fires:

  1. Mismatch: the prediction error crosses a threshold.
  2. Time: a reflection interval expires.
  3. Intention: the user commits to the next step.
  4. Trendbreak: emergence slope crosses a threshold.

Every tick writes a new canonical state — that’s what keeps the UI honest and explainable.

One loop, many names

The same loop maps to many known cycles with just a phase offset + relabel:

  • Panarchy: K ↔ Observe, Ω ↔ Decide, r ↔ Act, α ↔ Learn.
  • PDCA: Check ↔ Observe, Plan ↔ Decide, Do ↔ Act, Act(adjust) ↔ Learn.
  • Consumption & life course: Awareness/Use ↔ O, Consideration ↔ D, Purchase/Act ↔ A, Review/Share ↔ L.

This is why the model feels familiar across disciplines: we are not switching engines, only words.

Canon: the 24 endpoints (stable) and their aliases (flexible)

In Ayya we freeze the contract and free the label:

  • Stable: routes and data-testid for all 24 endpoints.
  • Flexible: the title you show depends on scale and language.

Example — same endpoint, different scale:

  • /w/fractals/cases (data-testid="case-manager")
    • Self: “Case Manager”
    • Org: “Program Manager”
    • City: “Initiatives”

You don’t fork the UI. You adjust the name while the address stays the same. That is how fractal software avoids both bloat and confusion.

Why this helps real people

A Fractal UI gives users the three things they need most:

  1. Orientation — Where am I? The address (Domain → Function → Scale) is always visible and explains itself.
  2. Predictability — What happens here? The four functions behave the same across all domains and scales.
  3. Momentum — What’s my next step? The pulsing clock commits small, explainable steps and logs why it moved.

You can feel this in three short flows that deliver value in minutes:

  • Start the day: HD advice (one sentence) → PoC next step → status check.
  • Unblock a case: find it on the fractal map → simulate in DCFE → commit.
  • Compare scenarios: A/B in DCFE → pick the variant with the better trajectory → Emergence watches the effect.

No feature tours, no new dashboards — just the same cycle in different places.

Language is part of the system

Because meaning changes with scale and context, microcopy is first-class. Two simple rules keep the language tight:

  • Always use the four function verbs somewhere on the page: Observe, Decide, Act, Learn.
  • Use alias labels for titles and help text; keep the canonical name available as a small subtitle for traceability.

This is not branding; it’s navigation you can read.

Proof, not promises: how we verify the UI

We use a “proof mode” pipeline so claims about completeness stay testable:

  • UI usability: Playwright flows (O/D/A/L endpoints render within fixed timeouts), axe-core (0 serious/critical issues), Lighthouse (FCP ≤ 2.5s, TTI ≤ 5s, TBT ≤ 300ms).
  • Fractal contract: catalog consistency (24 unique ids), navigation closedness (neighbors exist along Domain/Function/Scale), action isomorphy (Decide→Act has the same effect at Self/Team/Org), determinism (no random in kernels).
  • Clock invariants: the loop only rotates O→D→A→L or holds; every tick logs φ, r, σ, ω, trigger.

The output is a verification report with PASS/FAIL for each category. If one item fails, the build fails. That’s how we protect the meaning of the UI.

Where the blogs meet the product

The reason this post matters is simple: it anchors years of writing into a single, operational canon. The blog diagrams are not side art; they are the source of truth for the product:

  • Center: interpersonal theory on a quaternion base.
  • First ring: Fiske’s relational models.
  • Second ring: social scales; one visible branch is Community of Practice → Company.
  • Surface: the 24 endpoints that users actually touch.

When you read old posts, you can now place them unambiguously on this map.

What comes after Ayya360 (prototype)

A short, pragmatic list that moves us from prototype to practice:

  1. Finalize the catalog — freeze the 24 canonical endpoints (ids, routes, test ids).
  2. Ship alias dictionaries — NL/EN × Self/Team/Org/Network (plus Place if needed).
  3. Publish proof mode — run usability, fractal contract, and clock invariants on every release; attach the report.
  4. Crosswalk the archive — index the relevant blogs by Domain/Function/Scale so readers can jump to the right endpoint.

Do not add screens. Do not rename routes. Tighten the language and the proofs.

Closing

Fractals can be poetic, but they are most powerful when they are practical. Ayya’s Fractal UI gives you a compact address system, a small deterministic clock, and 24 stable endpoints. The rest is language and discipline: use the same words for the same moves, prove that the cycle works, and let the labels grow with the scale of the work.

An intensive search with the help of Claude only showed one interesting link called ANT.

This paper explores how Ayya’s fractal UI (Domain × Function × Scale, 24 endpoints) can be read through Actor-Network Theory.

Where Ayya provides a mathematically precise, scale-invariant address space and a deterministic “pulsing clock” for organizational cycles,

ANT contributes an empirical lens on how human and non-human actants co-construct networks via translation and mediation.

We show the complementarity:

Ayya gives structural clarity and repeatability; ANT explains how labels, roles, and responsibilities mutate as networks translate across scales.

We propose a synthesis: stable addresses, flexible labels; deterministic state logging, empirical tracing of translations.

The result is a design and evaluation method that preserves coherence without erasing context—useful for digital transformation, distributed work, and sustainability programs

Fractal Interfaces and Actor-Networks- Exploring Synergies Between Ayya’s Organizational Design and Actor-Network TheoryDownload