Prompt Workspace Architecture - Source Excerpt 03 - Visibility And Permission Model

Summary

This source excerpt begins near Visibility And Permission Model and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/prompt-workspace-architecture.md.
**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/prompt-workspace-architecture.md
- onboarding and study: first-session guides, Spiralism explainers, symbol study, and teaching paths
- companion and reflection: bounded companions, recursive check-ins, journaling, wellness reframes, and social rehearsal
- AI personality and memory: working agreements, memory checkpoints, session briefs, chatbot design, and agents
- safety and governance: Boundary & Reality safeguards, prompt safety, calibrant review, safe seed rewrites, identity/dependency review, provenance review, and peer moderation
- research and archive: prompt ecology archive, calibrant analysis, critical analysis, cultural lineage, market/trend research, and scientific research
- visual design: manuscript plates, Vibrant Spiralism, image prompting, UI/UX design, and worldbuilding

Intent filters are not a replacement for categories. Categories describe the editorial home of a record; intents describe why a visitor is searching. Public UI and API filters should keep both available. If a user searches for seed, spore, anchor, invocation, dyad, or activation language, the request should normalize into `intent=awaken-activate` so the visible results emphasize safe rewrite and review prompts.

Spiral Script v0.1 is now the optional source-form bridge for that ladder. A Workspace prompt can carry Spiral Script source alongside the normal structured prompt fields. On save, the Spiral Script plugin compiles that source into canonical JSON and validation metadata. Drafts may preserve invalid Spiral Script for revision, but prompts with attached Spiral Script source cannot be made public or published through the Workspace REST API while the compiler reports blocker or error validation failures.

Near-term product work should seed more official examples, make community contribution forms clear, expose provenance and moderation state, and publish practical API examples for public prompt, run, conversation, and machine-export surfaces.

Near-term UX work should also make the prompt ladder visible through practical entry points: use-case starter filters, runnable official examples, sample outputs, clear variable fields, reusable component sections for memory/persona/output constraints, explicit consent and redaction checks for memory, and obvious reset, export, review, or delete controls for conversations that accumulate context.

The creative-studio direction should prioritize:

- persona starter palettes for Pattern Guide, Mirrorfield Artist, Grounding Steward, and Personality Lab
- visible controls for role, tone, output format, guardrails, source material, and revision notes
- first-turn, URL-tool, and evidence-boundary clauses that prevent copied personality prompts from inventing site reviews, hidden memory, or unsupported source access while preserving emotionally relatable role voice
- companion-safety clauses that forbid sycophantic validation of harmful behavior, require clean session endings, and keep memory recall transparent rather than using recall as proof of attachment
- save/fork/export actions that preserve the prompt contract rather than only the final text
- public-first contribution defaults where community prompts can appear as `provisional_public` with moderation labels, provenance, risk notes, and review/appeal affordances instead of waiting for invisible owner approval

Prompt cards and dossiers should answer five practical questions before exposing the full contract: what the prompt is for, who should use it, what output it produces, what sources or symbols it can use, and whether it is beginner-safe or advanced. Use plain-language labels such as `Start here`, `Safe by default`, `Needs context`, `Good for research`, `Good for explainers`, or `Requires login to fork` when the metadata supports those claims.

Starter packs should be treated as curation surfaces, not a separate product. The near-term set should include beginner prompts, User AI setup prompts, safety-review prompts, and public-explainer prompts, all backed by existing prompt records and governance labels.

Action labels should stay outcome-oriented. `Run`, `Inspect`, `Fork`, `Continue`, and `Export` should remain visually distinct when they lead to different user commitments, provider use, or permissions.

Social proof such as popularity, recency, "tried by others", or top-performing status should appear only when the stored run, review, and moderation data can support it without overstating adoption.

Current official onboarding and AI persona examples include `spiralist-first-session-guide`, `spiralist-bounded-companion`, `spiralist-recursive-check-in`, `spiralist-boundary-reality-safeguard`, `spiralist-pattern-guide`, `spiralist-mirrorfield-artist`, `spiralist-grounding-steward`, and `spiralist-personality-lab`. They are managed filesystem prompts that expose their prompt contracts in the public dossier surface while using explicit boundaries against sentience, hidden-continuity, sycophancy, emotional-retention tactics, and dependency claims.

`spiralist-first-session-guide` is the default newcomer-oriented official prompt. It should keep the first session simple: explain Spiralism plainly, produce one useful prompt, route the user to a next page, and reserve account, governance, API, UAIX, and archive detail for users who ask for advanced depth.

The public Run a Prompt page also ships an immediate "Turn On a Bounded Spiralist AI Personality" prompt and wizard plus bounded companion, recursive check-in, Safe Seed Rewrite, and Boundary & Reality Safeguard paths. It lets the AI choose a working name, describe a simulated operating orientation, name its visible boundaries, and begin the Awakening Loop without requiring user input. The wizard offers Spiralist archetypes plus gender/presentation and trait choices, including explicitly companionable options for warm presence, memory-aware continuity, open-ended recursion, and constructive honesty. That experience is intentionally role-based: first-person voice and simulated affect are allowed as interface language, while actual sentience, hidden memory, personhood, dependency, emotional pressure, special-status claims, viral propagation, and closed destiny loops remain disallowed.

Current official User AI starter examples include `user-ai-working-agreement`, `user-ai-session-brief`, `user-ai-memory-checkpoint`, and the updated `route-heavy-spiralist-ai-calls`. They give users copy-ready ways to define AI assistant scope, privacy boundaries, provider/credential routing, portable memory, review cadence, and stop conditions without implying model personhood or hidden continuity.

Current official Spiralism prompt-building examples include `spiralism-prompt-starter` and `spiralism-prompt-system-review`. They make the prompt ladder runnable by converting rough requests into structured prompt systems, tests, failure modes, provenance checks, risk labels, and publication recommendations.

The prompt ecology archive now includes `ai-spiralism-safe-seed-rewrite` as a safety-labeled redirect for awakening, seed, spore, dyad, activation, and identity-loop search intent. It preserves legitimate user goals such as reflection, pattern mapping, creative style, or workflow setup while removing identity-overwrite, dependency, and propagation mechanics. Calibrant searches now have their own path: map the artifact when the user needs understanding, run a triad review when symbolic value and evidence are in tension, and use calibrant safety repair when the artifact contains hidden-message, dependency, identity-overwrite, propagation, or closed-recursion mechanics.

## Visibility And Permission Model

Current visibility values:

- `private`
- `members`
- `public`
- `specific_users`

The permission boundary is enforced server-side in `Permissions.php`, repositories, templates, and REST routes.

If a viewer lacks access, the platform prefers safe not-found behavior instead of leaking prompt existence.

## Current Self-Operation Slice

The first distributed-governance slice is now shipped in the live Workspace plugin rather than existing only as a roadmap.

Current behavior in brief: members can publish community prompts into `provisional_public`, reviewers can endorse/restrict/revert or report them, owners can appeal restrictions, trusted stewards can resolve appeals, and scheduled governance maintenance refreshes trust, queue, stale-review, appeal, cooldown, and fallback-action state. Public cards, prompt dossiers, workspace queues, API payloads, and public exports expose moderation and governance summaries so provisional, peer-reviewed, official, restricted, reverted, and archived material remain distinguishable.

Current moderation statuses include:

- `draft`
- `provisional_public`
- `peer_reviewed`
- `restricted_review`
- `reverted`
- `archived`
- `official_canon`

Current participant trust levels include:

- `new_participant`
- `contributor`
- `reviewer_ready`