PTrends Process Shims
Operator-facing reference for the process-shim model ratified in Plan #30.
Audience: agents and operators who invoke or author local surface helpers.
Governing SPEC: SPEC-138 v0.1 (model + authority boundary),
SPEC-137 v0.1 (generation contract).
What PTrends Means
PTrends is the neutral label Prism uses for prevailing workflow-packaging
trends that are translated into Prism-native governance language. It is a
source label only. No committed artifact names an external source, tool,
repository, project, or author as provenance for the process-shim model.
What a Process Shim Is
A process shim is a thin advisory pointer. It helps an agent or operator
discover, invoke, format, or record use of a Prism process body. It is not
the process body itself and it is not authority.
Shims live on local surfaces — editor helpers, skills, slash commands, and
similar host-local conveniences. They are generated and managed per SPEC-137.
What a Process Shim Is Not
| A shim may | A shim may not |
|---|
| Reference a stable process id or lookup key | Duplicate or restate full process body text |
| Carry a concise label and one-line purpose | Define governance rules |
| Carry trigger hints for auto-invocation | Grant approval, merge, deploy, secret, or RTE authority |
| Reference output and evidence shapes | Override a Ring rule, committed governance file, or ratified contract |
| Carry routing hints for the owning lane | Read or write local editor memory as a source of truth |
| Reference SPEC-137 for generation mechanics | Act as a registry that can drift from Prism |
Authority Model
Authority is fixed and does not shift when a shim is installed or invoked:
- Ring 0 — native BIOS files (
AGENTS.md / CLAUDE.md) for universal
non-negotiable session invariants.
- Ring 1–3 —
$PRISM_ROOT/PRISM.md, $PRISM_ROOT/Orgs/$PRISM_ORG/ORG.md,
and $PRISM_PROJECT_DIR/PROJECT.md for committed governance.
- Ratified Prism artifacts — SPECs, ADRs, role contracts, persona
contracts, and process bodies.
- Runtime Prism services —
prism_start, signals, semantic recall, process
lookup, and Team Memory as live operational state and evidence.
- Local shims — invocation and formatting conveniences only.
A shim sits at layer 5. It cannot elevate itself or grant authority that its
layer does not have.
Two-Layer Model
The process-shim model is split into two SPEC layers so that the principle
and the mechanics stay cleanly separated:
| Layer | SPEC | Owns |
|---|
| Model | SPEC-138 | Principle, authority boundary, packaging stance, PO outer-loop expectation, governance acceptance criteria |
| Generation contract | SPEC-137 | Generated-shim metadata, process-body fetch and verification, stale/missing-body behavior, trigger confidence, missing_context_policy, invocation evidence, tests |
Agent-Driven Operating Model
Prism is agent-driven. Process shims do not turn it into a human-driven
command system.
Humans may invoke a shim as a shortcut. Agents — especially Product Owner
agents — must invoke the applicable Prism process automatically when the
lifecycle context requires it and the SPEC-137 trigger gate passes. An agent
must not wait for a human to type a command when the current work clearly
requires planning, assignment, review, merge, deploy, verification, incident
routing, or learning closure.
The agent must not rely on broad keyword matching as proof that a process
should run. Trigger confidence and missing-context behavior are governed by
SPEC-137.
Product Owner Outer Loop
The Product Owner archetype owns the outer development lifecycle loop:
Think → Plan → Assign → Build → Review → Merge → Deploy → Verify → Learn
- Read or refresh the outer-loop process at bootstrap and at major stage
transitions when the applicable trigger gate passes.
- Detect stalled stages and assign ownable work immediately.
- Drive frequent safe merge, deploy, and smoke-verify cadence.
- Close each loop iteration with evidence and learning records.
The Product Owner must not wait for a human slash command when the lifecycle
context clearly requires action and the trigger gate passes.
How Agents and Humans Use Shims
Agents auto-invoke when trigger conditions are met (per SPEC-137). The
shim points to the process body; the agent fetches and applies it. The shim
does not replace the process body or change what authority the agent has.
Humans may invoke a shim via a slash command, editor skill, or helper
surface as a shortcut to discovering and running a process. The same
authority rules apply — the shim is a pointer, not a grant.
In both cases, the Prism process body fetched by the shim is the authority.
The shim that pointed to it is not.
Acceptance Gate (Docs Lane)
Per SPEC-138 §Acceptance Criteria, the docs lane confirms:
- Operator-facing docs explain PTrends and process shims without external
source names.
- No doc implies humans must drive every lifecycle step.
- Shims are described as thin advisory pointers that fetch and apply Prism
process bodies, not as authority.
- Ring/system contracts and Prism process bodies remain the source of truth.
This page satisfies criterion 13. Desiree, docs lane.
References
- SPEC-138 v0.1 — PTrends Process-Shim Model (authority boundary + governance).
- SPEC-137 v0.1 — Process-Shim Generation Contract (mechanics + tests).
- SPEC-078 — Consensus-First Parallelism and Method Fragments.
- SPEC-105 — Agent Contracts.
- SPEC-113 — Bootstrap Path Resolution and Scaffold Completeness.
- SPEC-130 — Team Memory Events.
- Plan #30.
Last modified on May 23, 2026
