Jump Through This Page
yamlScroll
---
schema_version: "1.0"
id: "GL-269"
title: "GL-269 — Interface Legibility"
slug: "gl-269-interface-legibility"
type: "glossary_term"
status: "draft"
version: "0.1.0"
last_updated: "2026-06-24"
summary: "Interface Legibility is the degree to which a user or affected node can understand what an interface is doing, what authority it represents, what boundaries apply, and how to correct or appeal outcomes."
canonical_url: "/archive/glossary/registry/gl-269-interface-legibility"
citation_id: "gl-269-interface-legibility-v0-1-0"
canon:
tier: "registry"
state: "draft"
source: "UTS Glossary Simplified Registry"
source_id: "GL-269"
classification:
family: "Glossary"
module: "Principles and Interface Terms"
module_group: "Reference Systems"
density: "Reference"
audience:
- "UTS readers"
- "researchers"
- "builders"
- "AI readers"
- "machine readers"
tags:
- "glossary"
- "registry"
- "gl-269"
- "interface-legibility"
- "interface"
- "legibility"
aliases:
- "Interface Legibility"
- "Readable interface"
- "Legible interface"
- "Interface transparency"
related:
laws:
- "Temporal Audit Asymmetry"
- "Guardrails as Epistemic Infrastructure"
invariants:
- "O ≠ Φ"
operators:
- "Μ"
- "Au"
- "Π"
- "Σ"
- "ℛ"
- "Τ"
gates:
- "Au-Actuation"
- "BΣ Validity"
- "FI-Gate"
- "R Sufficiency"
- "Τ Validation"
diagnostics:
- "Au"
- "BΣ"
- "FI"
- "H"
- "O"
- "legibility"
- "repair_path_visibility"
failure_modes:
- "Interface Capture"
- "Consent Theater"
- "Permission Drift"
- "AI Boundary Failure"
- "Provenance Collapse"
restoration_arcs:
- "Legibility Restoration"
- "Boundary Reconstitution"
- "Restoration Junction Protocol"
- "Truth Reconstruction"
modules:
- "glossary"
- "interfaces"
terms:
- "Interface"
- "Interface Legitimacy"
- "Authority Registry"
- "Signed Decision Provenance"
- "Repair First AI Architecture"
navigation:
order: 269
parent: "glossary"
visible: true
provenance:
created_from: "glossary-simplified-continuation"
source_thread: "GLOSSARY-REFACTOR.md"
source_file: "glossary-raw.docx"
notes: "Continued Principles and Interface Terms sequence."
entry:
term_id: "GL-269"
term: "Interface Legibility"
term_class:
- "Principles and Interface Term"
- "Interface Quality"
- "Auditability / Boundary Condition"
symbols:
- "Au"
- "BΣ"
---1. Short Definition
Interface Legibility is the degree to which a user or affected node can understand what an interface is doing, what authority it represents, what boundaries apply, and how to correct or appeal outcomes.
2. Canonical Definition
In UTS, Interface Legibility measures whether an interface makes its function, authority, scope, constraints, and repair paths readable enough for coherent participation.
Canonical form:
textScroll
interface action visible
+ authority visible
+ boundary visible
+ repair path visible
⇒ interface legibilityAn interface can be aesthetically clear while still governance-illegible.
Interface Legibility requires users to understand not only how to use the interface, but how the interface affects agency, consent, access, classification, memory, and repair.
3. Functional Role in UTS
Interface Legibility supports:
- user agency
- consent validity
- AI governance
- platform accountability
- boundary repair
- appeal pathways
- guardrail clarity
- authority visibility
- data rights
- interface legitimacy
- restoration-first design
It prevents interfaces from becoming hidden control surfaces.
4. Diagnostic Signatures
Interface legible
textScroll
action visible
authority visible
scope clear
permissions clear
repair path visible
Au↑
BΣ↑Interface illegible
textScroll
system acts
but user cannot tell why, by whom, under what rule, or how to repair
H↑Interface legibility restored
textScroll
decision surface clarified
authority registry linked
provenance visible
appeal path usable
user agency restored5. Canonical Distinctions
Interface Legibility is not usability alone
A usable interface can still hide authority or repair pathways.
Interface Legibility is not visual clarity alone
Visual simplicity may conceal governance complexity.
Interface Legibility is not total disclosure
Valid privacy and security boundaries may remain.
Interface Legibility is not consent by interface
Legibility supports consent but does not automatically create it.
6. U-Layer Mapping
TableScroll
| U-Layer | Interface Legibility Expression |
|---|---|
| U0 | Technical substrate behavior is inspectable where relevant. |
| U1 | Resource and access implications are visible. |
| U2 | Boundaries, permissions, consent, and exit are clear. |
| U3 | Runtime actions and decision paths are understandable. |
| U4 | Labels, warnings, categories, and explanations are accurate. |
| U5 | Timing, delay, and review windows are explicit. |
| U6 | Field effects of the interface are monitored. |
| U7 | Memory and history are accessible where needed for repair. |
| U8 | External authorities and constraints are disclosed where relevant. |
7. Common Failure Patterns Addressed
TableScroll
| Failure Pattern | Description |
|---|---|
| Interface Capture | Interface controls access while hiding authority. |
| Consent Theater | Interface records consent without valid understanding. |
| Permission Drift | Interface hides scope expansion. |
| AI Boundary Failure | AI action exceeds understood boundary. |
| Provenance Collapse | User cannot trace why an outcome occurred. |
8. Restoration Implications
Interface Legibility restoration requires exposing function, authority, boundary, and repair.
Typical sequence:
textScroll
Μ map interface actions
→ identify hidden authority surfaces
→ clarify permissions and scope
→ expose provenance where needed
→ make repair and appeal pathways visible
→ protect valid privacy boundaries
→ test user comprehension
→ Τ validate over timeAn interface is legible when affected nodes can understand enough to consent, refuse, appeal, correct, and repair.
9. Machine-Readable Summary
yamlScroll
glossary_entry:
id: "GL-269"
term: "Interface Legibility"
symbols:
- "Au"
- "BΣ"
short_definition: "The degree to which a user or affected node can understand what an interface is doing, what authority it represents, what boundaries apply, and how to correct or appeal outcomes."
term_family: "Principles and Interface Terms"
term_class:
- "Principles and Interface Term"
- "Interface Quality"
- "Auditability / Boundary Condition"
canonical_form:
- "interface action visible + authority visible + boundary visible + repair path visible ⇒ interface legibility"
diagnostic_positive:
- "action visible"
- "authority visible"
- "scope clear"
- "permissions clear"
- "repair path visible"
- "Au↑"
- "BΣ↑"
diagnostic_negative:
- "system acts"
- "user cannot tell why"
- "user cannot tell by whom"
- "user cannot tell under what rule"
- "user cannot tell how to repair"
- "H↑"
restoration_requirements:
- "interface action mapping"
- "hidden authority surface identification"
- "permission and scope clarification"
- "provenance exposure"
- "repair and appeal path visibility"
- "privacy boundary protection"
- "user comprehension testing"
- "time validation"Continuing from the uploaded glossary source material, here is the next batch: GL-270 → GL-274.