Status: Draft v0.1
Repository: purity-ui-control-architecture-v0.1
Version: 0.1.0
Purity UI Control Architecture v0.1 is a draft specification for designing creator-controlled user interfaces that preserve, display, and govern human-origin epicenters in AI-mediated platforms.
This repository extends the concept of Purity beyond scoring.
It focuses on how creators can control:
- epicenter visibility
- unresolved friction
- question structure
- meaning boundaries
- AI inference permissions
- trace visibility
- royalty-readiness previews
- circle versioning
- platform-level disclosure controls
- epicenter network relationships
The goal is not to judge creators.
The goal is to give creators control over how their human-origin meaning structures are displayed, accessed, interpreted, and reused in AI ecosystems.
In AI-mediated platforms, articles, essays, notes, protocols, research logs, and creative works are no longer only read by humans.
They may also be:
- retrieved by AI search
- summarized by AI systems
- embedded into RAG pipelines
- referenced by platform AI tools
- reused in downstream generated outputs
- connected to trace and royalty-readiness systems
- interpreted by autonomous agents
This creates a new problem.
Even if a work contains a strong human-origin epicenter, the platform interface may fail to show it.
A traditional article page usually shows:
title
body
likes
comments
share button
But an AI-era article page may need to show:
title
purity signal
epicenter structure
question origin
friction layer
AI reference log
visibility settings
no-inference policy
royalty-readiness preview
creator controls
Purity UI Control Architecture v0.1 explores this transition.
It asks:
How can a platform interface preserve the creator's question, friction, meaning boundary, and control authority in an AI-readable world?
Purity UI should not be only a score display.
It should become a creator-controlled origin interface.
In short:
Purity Detection
= estimates origin composition
Purity UI
= displays origin signals
Purity UI Control Architecture
= allows creators to control visibility, interpretation, inference, and circulation
The central principle is:
AI may assist.
AI may read.
AI may retrieve.
AI may summarize.
But creator-defined boundaries must remain authoritative.
This repository is derived from, but separate from:
ai-purity-detection-algorithm-v0.2
The relationship is:
AI Purity Detection Algorithm v0.2
= scoring, warning, and review-routing layer
Purity UI Control Architecture v0.1
= UI control, visibility, inference, and creator-sovereignty layer
In other words:
Purity Detection asks:
How strong is the human-origin signal?
Purity UI Control asks:
Who can see it, how can AI use it, and what must not be inferred?
Purity UI Control Architecture v0.1 defines the following initial layers:
Epicenter Layer
Proto-Friction Layer
Visibility Protocol
Circle Versioning
No-Inference Layer
Royalty OS Visibility
Epicenter Network
Creator Control Dashboard
The Epicenter Layer visualizes the source structure of a work.
It may include:
- friction
- core question
- sub-questions
- meaning boundary
- creator-defined interpretation scope
- non-public context markers
Possible structure:
Friction Layer
↓
Question Layer
↓
Meaning Layer
The goal is to show that a work did not emerge from empty data, but from a human-origin contact point with reality.
See:
docs/epicenter-layer.md
The Proto-Friction Layer preserves friction before it becomes fully verbalized.
This is important because human-origin meaning often begins as:
- discomfort
- silence
- vague resistance
- bodily sensation
- unfinished intuition
- fragmented note
- unresolved question
Possible controls:
[ ] I cannot verbalize this yet
[ ] Save as unresolved friction
[ ] Do not allow AI completion
[ ] Allow private creator-only note
[ ] Allow later conversion into core question
The principle is:
Unfinished friction should not be forcibly completed by AI.
See:
docs/proto-friction-layer.md
A simple public/private switch is not enough for AI-mediated platforms.
Creators may need more granular visibility controls.
Proposed levels:
| Level | Label | Description |
|---|---|---|
| 1 | Public | Visible to readers and AI systems |
| 2 | AI-Readable | Hidden from public UI, readable by authorized AI systems |
| 3 | Summary-Only | Only a summary may be used by AI systems |
| 4 | Friction-Only | Only the friction category or abstract signal may be disclosed |
| 5 | Private | Not visible to readers or AI systems |
Example:
visibility_protocol:
core_question: public
initial_friction: friction_only
deep_layer: private
rotation_dynamics: summary_only
trace_log: publicSee:
docs/visibility-protocol.md
Meaning structures evolve.
A creator's question, friction, or interpretation boundary may change over time.
Circle Versioning records these changes.
Example:
circle_version:
id: circle_v0.2
previous_version: circle_v0.1
change_type:
- question_refinement
- visibility_update
summary: "The original emotional friction evolved into a design question."The purpose is to prevent a creator's early thought from being frozen as a permanent identity.
See:
docs/circle-versioning.md
AI systems often infer missing context.
This may be useful in ordinary tasks, but dangerous when handling creator-defined meaning structures.
The No-Inference Layer defines where AI must not infer, reconstruct, summarize, or expand.
Possible controls:
[ ] Do not infer beyond this field
[ ] Do not reconstruct private context
[ ] Do not convert friction into psychological diagnosis
[ ] Do not summarize Deep Layer
[ ] Do not use this field for training
Example:
no_inference_policy:
enabled: true
protected_fields:
- initial_friction
- deep_layer
- private_creator_note
prohibited_actions:
- infer_intent
- reconstruct_private_context
- summarize_protected_fields
- use_for_trainingCore principle:
AI should assist within the boundary.
AI should not silently expand the boundary.
See:
docs/no-inference-layer.md
Royalty-related UI must be handled carefully.
This layer does not define final payment.
It only shows trace-to-allocation-readiness visibility.
Possible UI elements:
- trace events
- reference depth
- contribution score
- allocation-readiness status
- estimated preview
- review status
- dispute status
Required disclaimer:
This preview is an estimation only.
It does not guarantee payment, ownership, entitlement, or final allocation.
See:
docs/royalty-os-visibility.md
Individual works may contain epicenters.
But in AI-mediated ecosystems, epicenters may resonate with each other.
The Epicenter Network layer explores how platforms may visualize:
- question resonance
- friction overlap
- meaning distance
- trace connection
- influence path
- version relationship
Example:
epicenter_network:
related_epicenters:
- id: epicenter_001
relation_type: question_resonance
strength: 0.82
- id: epicenter_002
relation_type: friction_overlap
strength: 0.67The purpose is not to rank creators.
The purpose is to map meaning relationships.
See:
docs/epicenter-network.md
The Creator Control Dashboard is the practical UI layer where creators define:
- what is public
- what is private
- what AI may read
- what AI may summarize
- what AI must not infer
- whether trace logs are visible
- whether royalty-readiness preview is enabled
- whether training use is allowed
- whether unresolved friction may remain private
Example:
Creator Controls
[x] Core Question: public
[x] Initial Friction: friction-only
[ ] Deep Layer: private
[x] Allow Trace visibility
[x] Allow Royalty OS participation
[ ] Allow AI training use
[x] Enable No-Inference Policy
.
├── README.md
├── CHANGELOG.md
├── CITATION.cff
├── LICENSE
├── spec/
│ └── purity-ui-control-architecture-v0.1.yaml
├── docs/
│ ├── architecture-overview.md
│ ├── epicenter-layer.md
│ ├── proto-friction-layer.md
│ ├── visibility-protocol.md
│ ├── circle-versioning.md
│ ├── no-inference-layer.md
│ ├── royalty-os-visibility.md
│ └── epicenter-network.md
├── schemas/
│ └── purity-ui-control.schema.json
├── examples/
│ ├── basic-article-ui.example.yaml
│ ├── creator-controls.example.yaml
│ ├── visibility-settings.example.yaml
│ └── no-inference-policy.example.yaml
└── .github/
└── workflows/
└── validate-examples.yml
Defines the main machine-readable draft specification for Purity UI Control Architecture v0.1.
It includes:
- purpose
- core thesis
- relationship to AI Purity Detection
- core principles
- architecture layers
- visibility levels
- epicenter model
- proto-friction structure
- circle versioning
- no-inference policy
- royalty visibility
- epicenter network
- creator control dashboard
- non-goals
- future extensions
Provides the high-level architecture overview.
It explains how the main layers connect:
human friction
↓
question formation
↓
meaning boundary
↓
creator control
↓
AI-readable boundaries
↓
trace visibility
↓
value circulation
↓
epicenter network
Defines the five-level visibility model:
Public
AI-Readable
Summary-Only
Friction-Only
Private
It clarifies that public visibility, AI readability, summarization, training permission, and inference permission are different things.
Defines how creators may restrict AI inference.
It covers:
- protected fields
- prohibited actions
- enforcement levels
- proto-friction protection
- deep-layer protection
- training-use restrictions
- AI behavior requirements
Defines the human-origin source structure behind a work.
It distinguishes:
topic
vs.
epicenter
and formalizes the relationship between friction, question, and meaning boundary.
Defines how unresolved, pre-verbal, or incomplete friction may be preserved.
It protects early human-origin signals from premature AI completion.
Defines how meaning structures evolve over time.
It tracks changes in:
- proto-friction
- friction
- questions
- meaning boundaries
- visibility settings
- No-Inference Policies
- trace policies
- royalty visibility
Defines how trace-to-allocation-readiness signals may appear in a creator-controlled UI.
It clearly separates:
trace evidence
allocation-readiness preview
final payment execution
Defines how relationships between human-origin epicenters may be represented.
Its central principle is:
Map resonance, not hierarchy.
The JSON Schema is located at:
schemas/purity-ui-control.schema.json
It validates Purity UI Control objects, including:
creator_controlsvisibility_protocolno_inference_policycircle_versionroyalty_visibilityepicenter_network- optional article UI metadata
This repository includes four example YAML files.
Demonstrates a basic article-page UI configuration.
It includes:
- reader-facing Purity badge
- epicenter summary
- trace summary
- royalty-readiness preview
- creator boundary notice
Demonstrates a creator-controlled configuration where:
- core question is public
- initial friction is friction-only
- deep layer remains private
- trace visibility is allowed
- royalty preview is enabled
- AI training use is disabled
Demonstrates the five-level Visibility Protocol:
public
ai_readable
summary_only
friction_only
private
Demonstrates strict AI inference restrictions, including:
- no private context reconstruction
- no protected-field summarization
- no training use
- no psychological profiling
- no unfinished-friction resolution
This repository includes a GitHub Actions workflow for validating example YAML files against the JSON Schema.
Workflow:
.github/workflows/validate-examples.yml
Validation targets:
examples/basic-article-ui.example.yaml
examples/creator-controls.example.yaml
examples/visibility-settings.example.yaml
examples/no-inference-policy.example.yaml
↓
schemas/purity-ui-control.schema.json
The workflow uses:
Python 3.12
jsonschema
PyYAML
The validation process is:
Load YAML examples
↓
Load JSON Schema
↓
Validate each example against schema
↓
Report pass / fail
The current validation workflow has passed successfully.
Creators must retain authority over visibility, inference boundaries, and disclosure scope.
Private meaning structures should remain private unless explicitly disclosed.
AI assistance should not be treated as invalid by default.
The concern is not AI use itself, but whether AI-generated structure overwrites or obscures the human-origin epicenter.
AI systems should not silently infer, reconstruct, or expand protected meaning fields.
Trace or royalty-related UI should not imply automatic entitlement.
Review and dispute handling must remain separate from display.
Epicenter networks should map relationships, not produce creator hierarchy.
Creators should be able to update visibility, inference settings, and circle versions.
This repository does not attempt to:
- define a final production UI
- replace Purity Detection scoring
- determine legal authorship
- determine copyright ownership
- guarantee royalty payment
- define royalty rates
- rank creators by purity
- expose private creator context
- force creators to disclose deep meaning structures
- allow AI systems to infer beyond permitted boundaries
- define a final platform standard
- replace human or multi-wing review
- define final legal consent frameworks
- define a final payment system
This is a draft UI-control architecture for future platform design.
1. README.md
2. spec/purity-ui-control-architecture-v0.1.yaml
3. docs/architecture-overview.md
4. docs/visibility-protocol.md
5. docs/no-inference-layer.md
6. docs/epicenter-layer.md
7. docs/proto-friction-layer.md
8. docs/circle-versioning.md
9. docs/royalty-os-visibility.md
10. docs/epicenter-network.md
11. schemas/purity-ui-control.schema.json
12. examples/basic-article-ui.example.yaml
13. examples/creator-controls.example.yaml
14. examples/visibility-settings.example.yaml
15. examples/no-inference-policy.example.yaml
16. .github/workflows/validate-examples.yml
README.md
↓
docs/architecture-overview.md
↓
examples/basic-article-ui.example.yaml
README.md
↓
docs/visibility-protocol.md
↓
docs/no-inference-layer.md
↓
docs/epicenter-layer.md
spec/purity-ui-control-architecture-v0.1.yaml
↓
schemas/purity-ui-control.schema.json
↓
examples/
↓
.github/workflows/validate-examples.yml
docs/no-inference-layer.md
↓
docs/circle-versioning.md
↓
docs/royalty-os-visibility.md
↓
docs/epicenter-network.md
docs/proto-friction-layer.md
↓
docs/epicenter-layer.md
↓
docs/visibility-protocol.md
↓
docs/epicenter-network.md
Possible future extensions include:
- platform UI mock
- creator dashboard mock
- AI crawler access-control profile
- RAG metadata integration
- trace-to-royalty readiness flow
- dispute handling UI
- accessibility-friendly UI labels
- multilingual UI field definitions
- API profile for platform integration
- relationship document to AI Purity Detection Algorithm
- relationship document to Royalty OS
- relationship document to Consciousness Circle
- relationship document to Trace Protocol
- additional pass / fail validation vectors
- semantic consistency checks in CI
See:
CHANGELOG.md
Current release:
0.1.0
If you use this specification, please cite it using:
CITATION.cff
This repository is released under the license defined in:
LICENSE
Purity UI Control Architecture v0.1 defines a draft creator-controlled interface layer for AI-mediated platforms.
It connects:
human friction
↓
question formation
↓
meaning structure
↓
creator control
↓
AI-readable boundaries
↓
trace visibility
↓
value circulation
↓
epicenter network
The purpose is simple:
Do not let human-origin meaning become invisible infrastructure.
Give creators control over how their epicenters are displayed, accessed, interpreted, and circulated.
Purity Detection measures the water.
Purity UI Control designs the gate, flow, and boundary of the river.