SSyncropel Docs

Patterns

How a workspace learns from work that keeps succeeding the same way, reuses the outcome instead of reasoning it out again, and stops reusing it once it starts to fail.

Overview

When the same shape of work succeeds in your workspace several times, the workspace remembers the shape. The next time similar work arrives, it recognises the match and reuses the proven outcome instead of asking a model to work it out from scratch: no model call, no fresh reasoning, the same result. Over a workload that repeats, this is what pushes the cost of a routine piece of work toward nothing.

Think of a pattern as a memory of what worked, not a theory of why. A pattern does not understand the work. It knows that this shape of work, done this way, came out well often enough to be worth doing the same way again. Whether the reused outcome still fits the situation in front of you is checked each time it is used, never assumed.

A pattern is derived from your workspace's own history. It is not a separate library you maintain, and it can always be rebuilt from that history, so it never drifts from what actually happened.

What counts as a match

The workspace tries the cheapest option first and only moves to a dearer one when the cheaper one misses.

  1. The same work with the same details. The outcome is reused as it is.
  2. The same kind of work with different details. Most of the proven work is reused and the differences are adapted.
  3. Work that is only broadly similar. The pattern is a starting point and some new reasoning is needed.
  4. Nothing similar on record. The work is done fresh, with full reasoning.

Most of the saving comes from the first two steps, which is where the bulk of a repeating workload ends up once a workspace has been running for a while.

An exact duplicate of a record you already hold is a separate question ("is this already here?") and is answered before any matching starts, so the same event is never stored twice.

When a pattern is reused

A pattern exists the moment a thread closes successfully; its shape is on record and available for matching. But one success is not enough to act on. The workspace reuses a pattern's outcome only when:

  • it has succeeded several times, not once;
  • its reuses have kept working: a pattern whose attempts keep failing is not reused, however many times it once succeeded;
  • the saved work is still complete and still valid, so there is something real to carry out.

A reused outcome costs no model call. The checks that guard the work do not go away: a plan the workspace reuses from a pattern still needs the same approval a freshly written plan would need before anything is carried out. And a reuse that turns out to have nothing real to do is refused and recorded as a failure, never reported as a success.

When a pattern becomes permanent

Reuse is earned inside one workspace. A stronger standing, permanent, marks a pattern as reliable enough to be treated as settled and, with consent, shared with paired workspaces. A pattern becomes permanent only when all of the following hold:

  • The member who produced it is well trusted in that area of work. See Trust.
  • It has been observed many times, far more than reuse needs.
  • It describes a genuine regularity, not a coincidence: it should explain the repeated work more simply than listing each occurrence would.
  • It has been seen from more than one source (several members, or several paired workspaces), so one member's quirk does not become a rule for everyone.

Because of the last condition, a workspace with a single member does not make patterns permanent on its own; that standing is meant to be reached across a network of workspaces. Reuse does not wait for it.

When a pattern stops being reused

The reverse direction exists, and it is what keeps the workspace honest.

  • Reuse starts failing. Once enough of a pattern's attempts have failed, it stops being reused, however many times it once succeeded.
  • A permanent pattern's producer falls. A permanent pattern is set aside when a sudden change in the producing member's quality is noticed and their trust in that area has fallen. There is deliberate slack between the bar for becoming permanent and the bar for losing it, so a pattern does not flicker in and out on every small change. A pattern set aside this way is not reused either.

A pattern that used to work and stopped working does not keep being reused into a wall. It falls back to fresh work until new successes earn it back.

What you see over time

Early in a workspace's life almost all work is done fresh. As shapes repeat and earn reuse, more and more of the routine work is reused, and the operational cost concentrates in the genuinely new work. How fast this happens depends on how concentrated your workload is: a narrow pipeline with three kinds of task saturates quickly, a broad research assistant takes longer.

spl insights shows how much of your work is currently being reused, how many distinct shapes are currently eligible for reuse, and warns when the workspace has been repeating itself while discovering nothing new. There is no dedicated spl pattern command yet; spl insights is the surface today.

Patterns and paired workspaces

A pattern's shape can benefit another workspace without exposing what the work was about. Exact copies of your records never leave your workspace except by a permission you grant. What can be shared, with consent, is the shape of a permanent pattern: that this kind of work, done this way, is reliable. The sensitive contents stay home.

The permission model for this is in place. Automatic pattern exchange between paired workspaces is planned for a future release; see Federation for what pairing shares today.

When patterns won't help

Two shapes of work where the pattern layer adds little.

Genuine one-offs. If a task shape appears once and never recurs, there is no pattern to match and nothing to reuse. The workspace correctly does the work fresh and the cost stays at the price of a model call.

High-variance inputs with the same shape. A code-review task where every pull request has a different diff but the same "review this diff" shape will match broadly but never exactly. The pattern contributes context, but no outcome is reused. Cheaper than starting cold, not free.

What's next

  • The Engine: the loops that run matching and reuse.
  • Trust: the standing that decides whether a pattern becomes permanent.
  • Records: the unit patterns are built from.
  • Federation: how paired workspaces share, and what stays home.
  • Insights & Observability: reading how much of your work is being reused.
  • Glossary: the vocabulary this page assumes.

On this page