0. Plain Statement
Security must be legible enough to audit, steer, repair, and trust.
Plain-language version:
Security cannot depend on total opacity.
Some details may need to remain restricted to protect boundaries, prevent exploitation, or preserve safety.
But if no one can trace what happened, why it happened, who was affected, what rule was applied, what boundary was protected, what debt was created, what repair is required, or whether recurrence decreased, then the system is not secure.
It is illegible.
Illegible security accumulates hidden debt.
1. Formal Definition
The Security Legibility Law states that security systems must preserve enough traceability, auditability, explanation, reviewability, and repair visibility to remain coherent under pressure.
Security may require selective opacity around:
- credentials;
- exploit details;
- sensitive logs;
- active investigations;
- threat intelligence;
- defensive configurations;
- private data;
- harmed-node information;
- critical infrastructure;
- adversarial detection thresholds;
- temporary containment actions.
But selective opacity is not the same as illegibility.
A coherent security system must still make legible:
- what class of action occurred;
- what boundary was involved;
- what rule or constraint applied;
- what classification was made;
- what evidence category supported the classification;
- what authority or scope was used;
- what affected nodes exist;
- what harm or debt occurred;
- what restoration path exists;
- what appeal or correction path exists;
- what recurrence-prevention path exists;
- what temporal review will occur;
- what claims can be audited by whom.
Security that cannot be audited cannot be steered.
Security that cannot be steered cannot reliably repair.
Security that cannot repair cannot maintain legitimacy.
Therefore:
security requires legibility proportional to risk, authority, and effect2. Canonical Form
Core form:
security must be legible enough to audit, steer, repair, and trustProportionality form:
security_legibility ∝ risk + authority + affected-node impactAudit form:
security claim valid ⇔ traceable to boundary + classification + action + effect + repair pathOpacity boundary form:
selective opacity valid only when Au_eff remains sufficientFailure form:
security opacity↑ + Au_eff↓ ⇒ H↑ + L↓Restoration-valid contrast:
security valid when sensitive pathways remain protected while enough trace remains for audit, correction, and repair over ΤRelated variables:
O, H, H_security, ε, ι, Au, Au_eff, µᵢ, BΣ, K, σ, R, R_eff, 𝓑, 𝓓, Φ, Λ, ⊗, Γ, Π, Ξ, ℛ, Θ, Σ, Ψ, Τ, FI, MS, L, security_legibility, traceability, opacity_scope, security_claim, classification_trace, action_trace, control_trace, boundary_trace, effect_trace, restoration_trace, appeal_path, correction_path, review_path, sensitive_detail_protectionWhere:
| Variable | Meaning in this law |
|---|---|
security_legibility | Degree to which security state, action, rationale, effect, and repair path can be understood by valid auditors or affected pathways |
traceability | Ability to reconstruct decision, classification, rule, authority, boundary, action, effect, and repair path |
opacity_scope | Domain and limits of intentionally restricted visibility |
security_claim | Claim that an action, system, restriction, refusal, surveillance, policy, or control is security-valid |
classification_trace | Trace of how a signal, node, event, or risk was classified |
action_trace | Trace of what security action occurred and why |
control_trace | Trace of restrictions, enforcement, denial, surveillance, or containment |
boundary_trace | Trace of what membrane, access boundary, consent boundary, or coupling boundary was protected or altered |
effect_trace | Trace of consequences for nodes, system state, debt, recurrence, and legitimacy |
restoration_trace | Trace of repair actions, obligations, pathways, completion, and recurrence prevention |
appeal_path | Pathway for review, correction, dispute, or escalation |
correction_path | Pathway for fixing misclassification, overreach, or erroneous effect |
review_path | Pathway for independent, internal, external, or affected-node review |
sensitive_detail_protection | Protection of details whose exposure would create risk |
Au / Au_eff | Auditability and effective auditability of security claims and effects |
FI | Feedback integrity; security legibility allows correction |
BΣ | Boundary integrity; security must protect sensitive boundaries while remaining audit-capable |
R / R_eff | Restoration capacity; legibility must reveal repair needs and status |
L | Legitimacy; rises when security can survive appropriate audit |
H / H_security | Hidden debt; rises when security becomes illegible |
Γ | Classifies security event, risk, evidence, rule, boundary, and repair requirement |
Π | Operationalizes security controls, records, logs, reports, review, appeals, and repair workflows |
Ξ | Inversion when security opacity hides incoherence or control |
ℛ | Repairs harm, misclassification, overreach, and hidden debt revealed by legibility |
Θ | Humility preventing secrecy from becoming self-certification |
Σ | Scope of security claim, authority, opacity, and audit access |
Ψ | Field and affected-node feedback validating security effects |
Τ | Time validation of security trace, repair, and recurrence reduction |
3. Core Mechanism
The law unfolds because security requires selective secrecy, but selective secrecy can drift into illegibility.
Coherent security-legibility pathway
security action occurs
→ sensitive details are protected
→ classification and scope remain traceable
→ action and effect are auditable
→ affected correction path exists
→ repair path activates if needed
→ recurrence decreases
→ legitimacy holds over timeIllegible security pathway
security action occurs
→ opacity expands
→ classification becomes untraceable
→ affected nodes cannot correct errors
→ repair obligations disappear
→ hidden debt accumulates
→ legitimacy collapses when exposedThe core mechanism is:
security needs secrecy at the edge, not illegibility at the coreDetailed mechanism:
- Security action occurs.
The system classifies a threat, restricts access, monitors behavior, denies action, enforces a boundary, contains risk, or responds to an incident.
- Some details may be sensitive.
Full disclosure can expose vulnerabilities, private data, adversarial detection logic, or harmed-node information.
- The system must preserve audit traces.
Even when details are restricted, there must be sufficient traceability for valid review, correction, repair, and legitimacy.
- Opacity can become self-protective.
Security may begin hiding not only sensitive pathways but also mistakes, overreach, misclassification, debt, or incoherence.
- Illegibility blocks repair.
If no one can reconstruct what happened, the system cannot repair the correct layer.
- Illegibility blocks trust.
Affected nodes cannot distinguish protection from control.
- Coherent security balances secrecy and auditability.
The system protects sensitive details while preserving sufficient effective auditability.
4. When This Law Applies
This law applies whenever a system claims security while restricting information, explaining decisions, classifying risk, enforcing boundaries, denying access, monitoring behavior, deploying controls, responding to incidents, or handling sensitive threats.
It is especially important when:
- security actions are opaque;
- users or affected nodes cannot understand what happened;
- classifications cannot be audited;
- security rules are hidden;
- AI systems refuse, moderate, rank, restrict, or score users;
- surveillance is justified by safety;
- emergency actions bypass normal review;
- compliance is treated as proof;
- dashboards obscure field effects;
- logs exist but cannot reconstruct decisions;
- sensitive details are used to block all inquiry;
- appeals are unavailable;
- correction paths are missing;
- security outcomes affect access, livelihood, reputation, identity, health, rights, or legitimacy;
- public or institutional trust depends on security claims.
The law applies strongly when:
security action affects nodes but cannot be traced or correctedor when:
opacity is used to protect security claims from auditTypical domains:
| Domain | Security Legibility Expression |
|---|---|
| AI systems | Refusals, moderation, safety scores, risk classifications, account restrictions, and guardrails need traceability, appeal, correction, and repair. |
| Cybersecurity | Detection, containment, investigation, and enforcement require logs, evidence categories, scope, and post-incident repair trails. |
| Institutions | Security decisions affecting people require intelligible process, review, and restoration pathways. |
| Governance | Public safety, emergency action, surveillance, and enforcement require proportional legibility and oversight. |
| Medicine / biology | Safety decisions require traceable diagnosis, intervention, consent, and recovery rationale. |
| Economy | Fraud, risk, credit, and compliance systems require explanation, dispute, and correction paths. |
| Culture | Protective norms and taboos need legible boundaries to avoid becoming control. |
| Media / information networks | Moderation and ranking require legibility enough to distinguish safety from narrative control. |
5. When This Law Does Not Apply
This law should not be used to demand total disclosure of sensitive security information.
Total transparency can create harm.
Some information must remain protected.
False-positive cases:
| Case | Why limited opacity may be coherent |
|---|---|
| Active exploit details would enable harm | Details may be restricted while audit trace remains |
| Private harmed-node information is involved | Privacy can limit disclosure |
| Investigation is ongoing | Temporary confidentiality may be valid if review exists |
| Threat intelligence sources need protection | Source protection may be coherent |
| Detection thresholds would be gamed | Thresholds can remain restricted |
| Critical infrastructure details are sensitive | Boundary protection may require limited access |
| Internal security logs contain private data | Logs may require controlled audit rather than public release |
Important distinction:
The law requires effective auditability, not total visibility.
The correct question is not:
Can everyone see everything?The correct question is:
Can valid auditors and affected pathways understand enough to correct, repair, and trust the security action?6. Diagnostic Signature
Canonical diagnostic:
security opacity↑ + Au_eff↓ ⇒ H↑ + L↓Security-valid diagnostic:
sensitive details protected + traceability intact + repair path active ⇒ security legibleWarning signature:
opacity_scope↑
classification_trace↓
action_trace↓
appeal_path↓
restoration_trace↓
affected-node trust↓
⇒ illegible securityCommon indicators:
| Diagnostic | Expected movement | Interpretation |
|---|---|---|
security_legibility | sufficient | Security can be understood by valid auditors or affected pathways |
traceability | ↑ | Decisions and effects can be reconstructed |
opacity_scope | bounded | Restricted visibility remains scoped and justified |
classification_trace | intact | Classification path is auditable |
action_trace | intact | Security action is reconstructable |
control_trace | intact | Restrictions and enforcement are traceable |
boundary_trace | intact | Protected membrane is identifiable |
effect_trace | intact | Consequences and affected nodes are visible enough for repair |
restoration_trace | active | Repair obligations and progress are visible to valid pathways |
appeal_path | available where applicable | Affected nodes can request review |
correction_path | available where applicable | Misclassification or overreach can be repaired |
review_path | active | Oversight exists |
sensitive_detail_protection | intact | Legibility does not expose dangerous details |
Au_eff | sufficient | Effective auditability remains |
FI | intact | Feedback can correct security action |
L | stable / ↑ if valid | Trust holds when legibility is sufficient |
H | ↑ if invalid | Hidden debt rises when security becomes illegible |
Τ | required | Time validates traceability and repair outcomes |
Additional diagnostics:
| Diagnostic | Use |
|---|---|
| Security Legibility | Tests whether security can be understood enough to steer |
| Traceability | Tests reconstruction of classification, action, and effect |
| Effective Auditability | Tests whether audit can actually operate |
| Security Claim Audit | Tests whether security claims survive inspection |
| Security Opacity | Tracks restricted visibility scope |
| Decision Legibility | Tests decision-path clarity |
| Classification Trace | Tests threat or risk classification logic |
| Control Trace | Tests restriction or enforcement path |
| Restoration Trace | Tests repair path and completion |
| Temporal Proof | Validates repair and recurrence reduction over time |
7. Failure Pattern
If ignored, this law allows security to become a black box that cannot be corrected, repaired, or trusted.
General failure pathway:
security action occurs
→ opacity expands
→ classification becomes untraceable
→ affected nodes lack appeal
→ repair path disappears
→ hidden debt accumulates
→ legitimacy declines
→ security claim fails under exposureCommon failure modes:
- Illegible Security — security action cannot be understood enough to audit or repair.
- Opaque Security Debt — opacity hides debt and misclassification.
- Security Theater — visible protection masks illegible core effects.
- Pseudo-Security — security appears strong while traceability decays.
- Audit Suppression — security blocks inspection by invoking sensitivity.
- Black-Box Enforcement — restriction or denial occurs without traceable cause.
- Untraceable Classification — nodes or signals are labeled without reconstructable rationale.
- Untraceable Denial — access, service, speech, support, or action is denied without correction path.
- Unaccountable Surveillance — sensing occurs without traceable use, scope, or repair.
- Repair Obscurity — harm is detected but repair path is unclear.
- Boundary Ambiguity — no one can tell what membrane was protected or crossed.
- Legitimacy Debt — trust decays because security cannot survive audit.
- Hidden Debt Accumulation — debt persists because security effects cannot be reconstructed.
- Trust Collapse — exposure of illegibility causes broad loss of confidence.
- Security Inversion — protection language masks incoherent control.
Compact failure signature:
security_claim + opacity↑ + Au_eff↓ ⇒ H↑ + L↓8. Restoration Implications
Restoration requires reconstructing traceability without recklessly exposing sensitive details.
The first restoration question is not:
Can we reveal everything?The first restoration question is:
What must be legible to valid auditors and affected pathways so the security action can be corrected, repaired, and trusted?Restoration priorities:
- Identify the security claim.
- Define the opacity scope.
- Separate sensitive details from audit-critical traces.
- Reconstruct classification trace.
- Reconstruct action trace.
- Reconstruct boundary trace.
- Reconstruct effect trace.
- Reconstruct restoration trace.
- Create correction, appeal, or review pathways where applicable.
- Validate repair and recurrence reduction over time.
Relevant restoration arcs:
| Restoration Arc | Why it applies |
|---|---|
| Security Legibility Restoration | Restores enough legibility to steer and trust security |
| Traceability Restoration | Rebuilds decision, action, effect, and repair trails |
| Auditability Restoration | Restores effective inspection without unsafe disclosure |
| Security Claim Audit | Tests whether security claims match field effects |
| Decision Trail Reconstruction | Reconstructs security decision sequence |
| Classification Trace Repair | Repairs untraceable or erroneous classifications |
| Boundary Clarification | Identifies what membrane was protected, altered, or crossed |
| Feedback Integrity Restoration | Allows affected correction and review |
| Restoration Trace Repair | Makes repair obligations and completion visible |
| Opacity Scope Repair | Narrows secrecy to valid sensitive detail |
| Legitimacy Repair | Restores trust after illegible security |
| Hidden Debt Reduction | Repairs debt hidden by opacity |
| Temporal Validation | Confirms traceability and repair hold over time |
Minimal restoration sequence:
identify security_claim
→ define opacity_scope
→ separate sensitive detail from audit trace
→ rebuild Γ classification_trace
→ rebuild Π action/control_trace
→ map BΣ boundary_trace + effect_trace
→ restore Au/FI/review
→ route into ℛ
→ validate L/O over ΤTemporal validation requirement:
opacity scope becomes bounded
classification trace improves
action trace improves
boundary trace improves
effect trace improves
restoration trace improves
appeal / correction paths become available where applicable
hidden debt decreases
recurrence decreases
legitimacy stabilizes
security remains coherent under forcing9. Design Rule
Protect sensitive details, but never let security become untraceable to those responsible for audit, correction, repair, and trust.
Operational design requirements:
- Define what must remain secret.
- Define who can audit.
- Define what trace must be preserved.
- Define classification categories.
- Define action logs.
- Define boundary rationale.
- Define affected-node pathways.
- Define review authority.
- Define appeal or correction where applicable.
- Define restoration obligations.
- Preserve sensitive detail protection.
- Preserve effective auditability.
- Preserve feedback integrity.
- Track legitimacy effects.
- Validate over time.
Avoid:
- “security” as a blanket refusal to explain;
- secrecy without audit;
- hidden rules with no review;
- black-box denial;
- black-box moderation;
- black-box risk scoring;
- surveillance without traceable use;
- incident response without logs;
- controls without boundary rationale;
- appeals that cannot reach evidence category;
- repair paths hidden from affected nodes;
- compliance reports that hide field effects;
- AI safety actions that cannot explain classification class or correction path;
- using sensitivity to protect mistakes, overreach, or legitimacy claims from audit.
10. Cross-Scale Expressions
| Scale / Layer | Expression of the Law |
|---|---|
| U0 — Substrate | Physical, biological, and infrastructure security must preserve enough trace to identify failure, repair, and recurrence. |
| U1 — Energy / capacity | Legibility consumes capacity; audit and review require staffing, attention, time, and tooling. |
| U2 — Boundary / interface | Security must make boundaries clear enough to respect, repair, and contest where appropriate. |
| U3 — Process / execution | Security processes require logs, review, correction, escalation, and repair workflows. |
| U4 — Classification / claim | Security claims, threat labels, and risk classes must be distinguishable from proof. |
| U5 — Time / delay | Security traces must persist long enough for audit, correction, and temporal validation. |
| U6 — Field effect | Outcomes reveal whether legible security improved coherence or only explained control. |
| U7 — Recurrence / memory | Security memory must preserve lessons without hiding debt or binding nodes permanently to error. |
| U8 — Environment / forcing | Institutions, platforms, AI systems, markets, media, and governance fields may incentivize opacity unless audit is protected. |
11. Examples
Example A — Black-Box Account Restriction
Scenario:
A platform restricts an account for “security reasons” but provides no category, no appeal, no correction path, and no traceable restoration process.
Law expression:
security denial + Au_eff↓ + appeal absent ⇒ legitimacy debtInterpretation:
Sensitive details may be restricted, but the action still needs enough legibility for review and correction.
Example B — Coherent Cyber Incident Report
Scenario:
A breach report protects exploit details but identifies the incident class, affected systems, timeline, containment, repair steps, recurrence prevention, and review plan.
Law expression:
sensitive detail protected + audit trace intact ⇒ legible securityInterpretation:
The system preserves security while remaining auditable.
Example C — AI Refusal Without Classification Trace
Scenario:
An AI system refuses a request but cannot distinguish whether the refusal came from policy, uncertainty, misclassification, user risk score, system instability, or unavailable capability.
Law expression:
AI refusal + classification_trace absent ⇒ pseudo-safety riskInterpretation:
AI security actions require at least class-level legibility and correction pathways.
Example D — Opaque Surveillance
Scenario:
A workplace or platform monitors behavior but does not disclose scope, retention, use, classification categories, appeal, or repair path.
Law expression:
surveillance_scope opaque + FI↓ ⇒ H↑ + L↓Interpretation:
Surveillance becomes illegitimate when it cannot be audited or corrected.
Example E — Emergency Security Review
Scenario:
A crisis response restricts access temporarily, then publishes a scoped review explaining the threat class, authority, duration, affected nodes, repair actions, and sunset outcome.
Law expression:
emergency Π + Au + sunset trace ⇒ L stableInterpretation:
Emergency security remains legible when scope, review, and sunset are traceable.
Example F — Security With Controlled Audit
Scenario:
A system uses restricted logs accessible only to authorized auditors, while affected nodes receive explanation class, appeal path, correction status, and restoration updates.
Law expression:
controlled opacity + Au_eff sufficient ⇒ security legibilityInterpretation:
Legibility does not require public exposure of every detail; it requires effective audit and repair.
12. Relationship to Nearby Laws
| Related Law | Relationship |
|---|---|
| LAW-001 — Coherence Priority Law | Security legibility is valid when it supports coherence |
| LAW-002 — Coherence Trajectory Law | Legibility must improve security trajectory over time |
| LAW-003 — Success Proxy Divergence Law | Security proxies must be traceable to field effects |
| LAW-004 — Stability-Coherence Separation Law | Opaque stability may hide incoherence |
| LAW-006 — Time Validation Law | Legible security requires temporal validation |
| LAW-009 — U4 / U6 Truth Law | Security claims require field-trace validation |
| LAW-010 — Hidden Debt Accumulation Law | Illegible security accumulates hidden debt |
| LAW-011 — Hidden Debt Return Law | Opaque security debt returns through failure or trust collapse |
| LAW-012 — Error Lag Law | Illegibility delays error detection |
| LAW-013 — Auditability-Debt Law | LAW-120 specializes auditability-debt for security |
| LAW-015 — Suppressed Auditability Debt Law | Suppressed security audit produces debt |
| LAW-016 — Inversion Formation Law | Security can invert into control when illegible |
| LAW-020 — Bandwidth Threshold Law | Legibility requires bandwidth for review and correction |
| LAW-031 — Observability Collapse Law | Illegibility is a controlled or accidental observability collapse |
| LAW-036 — Signal Artifact Law | Legibility helps distinguish signal from artifact |
| LAW-037 — Misclassification Law | Classification trace reduces security misclassification |
| LAW-040 — Filtering Law | Filtering must be legible enough to audit |
| LAW-041 — Boundary Membrane Law | Security must trace what membrane is protected |
| LAW-042 — Consent Structurality Law | Consent-related security requires legible scope |
| LAW-045 — Force Debt Law | Coercive security action requires traceability and repair |
| LAW-048 — Feedback Integrity Law | Legibility enables correction by feedback |
| LAW-050 — Control-Restoration Separation Law | Security must trace whether action is control or restoration |
| LAW-052 — Stability Proof Law | Legible security must survive perturbation and review |
| LAW-057 — Deception Instability Law | Deceptive security opacity is unstable |
| LAW-060 — Interface Legitimacy Law | Security interfaces require legibility |
| LAW-061 — Restoration Sequencing Law | Security legibility must reveal repair sequence |
| LAW-064 — Restoration Debt Reduction Law | Traceability supports debt reduction |
| LAW-066 — Restoration Capacity Sufficiency Law | Legibility reveals whether repair capacity exists |
| LAW-067 — Temporal Proof Law | Security trace must validate over time |
| LAW-102 — Legitimacy Audit Law | Legible security supports legitimacy |
| LAW-103 — Justice Stability Law | Justice requires security decisions to be traceable |
| LAW-105 — Repair Before Enforcement Law | Enforcement must be traceable to repair path |
| LAW-109 — High-Φ Legitimacy Scaling Law | High-influence security requires stronger legibility |
| LAW-110 — Governance Sequencing Law | Security legibility supports governance sequencing |
| LAW-111 — Meaning Audit Law | Security narratives are not audit-exempt |
| LAW-112 — Security as Sustained Coherence Law | LAW-120 defines the legibility requirement for coherent security |
| LAW-113 — Incident Lag Law | Legibility reduces incident lag by preserving traces |
| LAW-114 — Pseudo-Security Law | Legibility prevents security appearance from replacing coherence |
| LAW-115 — Surveillance–Restoration Law | Surveillance requires legible scope, use, and repair routing |
| LAW-116 — Emergency Normalization Law | Emergency security requires traceable scope and sunset |
| LAW-117 — Shadow–Light Security Law | Shadow work must remain traceable enough for Light governance |
| LAW-118 — Empathy Security Law | Empathic classification requires correction and traceability |
| LAW-119 — Basin Self-Defense Law | Basin defense becomes diagnosable through security legibility |
| LAW-121 — AI as Γ-Amplifier Law | AI-amplified classification requires stronger legibility |
| LAW-122 — AI Error Lag Law | AI errors become visible late when traces are weak |
| LAW-123 — AI U4 Truth Discipline Law | AI security claims require U6 validation |
| LAW-124 — AI Rule-Stacking Law | Rule-stacked AI safety becomes illegible without traceability |
| LAW-127 — AI Decision Pipeline Law | AI action requires legible decision pathway |
| LAW-130 — AI Membrane Triage Law | Membrane failures require traceable triage |
| LAW-131 — Cognitive Infrastructure Scaling Law | Cognitive security requires public-legible accountability |
| LAW-132 — AI Legitimacy Function Law | AI legitimacy depends on accountable, auditable, transparent-enough security |
| LAW-134 — Layered Interception Law | Layered safeguards must preserve traceability |
| LAW-135 — Guardrail Belief-Sculpting Law | Guardrails need legibility when they shape belief |
| LAW-136 — Invisible Constraint Amplification Law | Invisible security constraints require audit to prevent hidden power |
Aliases folded into this law:
- Security Legibility Law
- Security Must Be Legible Law
- Security Traceability Law
- Auditable Security Law
- Opaque Security Debt Law
- Security Claims Require Traceability Law
- Legible Security Governance Law
Deduplication note:
This law should remain the root security-legibility law. LAW-013 defines general auditability debt. LAW-112 defines security as sustained coherence. LAW-114 defines pseudo-security. LAW-115 defines surveillance-to-restoration routing. LAW-120 defines the traceability requirement that allows security claims, classifications, controls, opacity, and repair pathways to remain audit-valid.
13. Operator Mapping
| Operator | Role in this law |
|---|---|
Γ | Classifies security event, threat, evidence category, boundary, rule, opacity scope, and repair requirement |
Π | Operationalizes logs, controls, review paths, appeal paths, correction paths, reports, and repair workflows |
Ξ | Captures inversion when security opacity hides incoherence, overreach, or control |
⊗ | Security legibility governs couplings among actors, controls, logs, auditors, affected nodes, and repair systems |
ℛ | Repairs misclassification, overreach, hidden debt, boundary damage, and trust loss |
Τ | Validates traceability, repair, recurrence reduction, and legitimacy over time |
Θ | Prevents secrecy from becoming self-certifying authority |
Σ | Defines scope of security action, opacity, audit access, authority, and affected domain |
Ψ | Field and affected-node feedback validates security effects |
Λ | Tests compatibility between security opacity and whole-system coherence |
Coherent operator sequence:
security action occurs
→ Θ prevent secrecy self-certification
→ Γ classify event / boundary / evidence / opacity scope
→ Σ define who can know what and why
→ Π preserve decision, action, control, and repair traces
→ Au/FI enable audit, appeal, and correction
→ ℛ repair harm or misclassification
→ Ψ validate affected-node effects
→ Τ validate recurrence reduction and L stabilityInverted operator sequence:
security claim appears
→ opacity expands
→ Γ classification becomes untraceable
→ Π denies / restricts / monitors without review path
→ FI narrows
→ ℛ disappears
→ H↑
→ Ξ / ι↑
→ L↓14. Machine-Readable Summary
id: "LAW-120"
name: "Security Legibility Law"
type: "law"
status: "draft"
family:
- "Security Laws"
summary: "Security must be legible enough to audit, steer, repair, and trust; opaque security may temporarily protect secrets, but illegible security accumulates hidden debt and legitimacy risk."
canonical_statement: "Security must be legible enough to audit, steer, repair, and trust."
core_form: "security must be legible enough to audit, steer, repair, and trust"
proportionality_form: "security_legibility ∝ risk + authority + affected-node impact"
audit_form: "security claim valid ⇔ traceable to boundary + classification + action + effect + repair path"
opacity_boundary_form: "selective opacity valid only when Au_eff remains sufficient"
failure_form: "security opacity↑ + Au_eff↓ ⇒ H↑ + L↓"
restoration_valid_contrast: "security valid when sensitive pathways remain protected while enough trace remains for audit, correction, and repair over Τ"
variables:
primary:
- "security_legibility"
- "traceability"
- "opacity_scope"
- "security_claim"
- "classification_trace"
- "action_trace"
- "control_trace"
- "boundary_trace"
- "effect_trace"
- "restoration_trace"
- "appeal_path"
- "correction_path"
- "review_path"
- "sensitive_detail_protection"
- "Au"
- "Au_eff"
- "FI"
- "BΣ"
- "R"
- "R_eff"
- "L"
- "H"
secondary:
- "O"
- "H_security"
- "ε"
- "ι"
- "µᵢ"
- "K"
- "σ"
- "𝓑"
- "𝓓"
- "Φ"
- "Λ"
- "⊗"
- "Γ"
- "Π"
- "Ξ"
- "ℛ"
- "Θ"
- "Σ"
- "Ψ"
- "Τ"
- "MS"
diagnostics:
- "Security Legibility"
- "Traceability"
- "Effective Auditability"
- "Security Claim Audit"
- "Security Opacity"
- "Decision Legibility"
- "Classification Trace"
- "Control Trace"
- "Restoration Trace"
- "Boundary Integrity"
- "Feedback Integrity"
- "Legitimacy"
- "Hidden Debt"
- "Temporal Proof"
failure_modes:
- "Illegible Security"
- "Opaque Security Debt"
- "Security Theater"
- "Pseudo-Security"
- "Audit Suppression"
- "Black-Box Enforcement"
- "Untraceable Classification"
- "Untraceable Denial"
- "Unaccountable Surveillance"
- "Repair Obscurity"
- "Boundary Ambiguity"
- "Legitimacy Debt"
- "Hidden Debt Accumulation"
- "Trust Collapse"
- "Security Inversion"
restoration_arcs:
- "Security Legibility Restoration"
- "Traceability Restoration"
- "Auditability Restoration"
- "Security Claim Audit"
- "Decision Trail Reconstruction"
- "Classification Trace Repair"
- "Boundary Clarification"
- "Feedback Integrity Restoration"
- "Restoration Trace Repair"
- "Opacity Scope Repair"
- "Legitimacy Repair"
- "Hidden Debt Reduction"
- "Temporal Validation"
related_laws:
- "LAW-001"
- "LAW-002"
- "LAW-003"
- "LAW-004"
- "LAW-006"
- "LAW-009"
- "LAW-010"
- "LAW-011"
- "LAW-012"
- "LAW-013"
- "LAW-015"
- "LAW-016"
- "LAW-020"
- "LAW-031"
- "LAW-036"
- "LAW-037"
- "LAW-040"
- "LAW-041"
- "LAW-042"
- "LAW-045"
- "LAW-048"
- "LAW-050"
- "LAW-052"
- "LAW-057"
- "LAW-060"
- "LAW-061"
- "LAW-064"
- "LAW-066"
- "LAW-067"
- "LAW-102"
- "LAW-103"
- "LAW-105"
- "LAW-109"
- "LAW-110"
- "LAW-111"
- "LAW-112"
- "LAW-113"
- "LAW-114"
- "LAW-115"
- "LAW-116"
- "LAW-117"
- "LAW-118"
- "LAW-119"
- "LAW-121"
- "LAW-122"
- "LAW-123"
- "LAW-124"
- "LAW-127"
- "LAW-130"
- "LAW-131"
- "LAW-132"
- "LAW-134"
- "LAW-135"
- "LAW-136"
related_invariants:
- "INV-001"
- "INV-002"
- "INV-006"
- "INV-073"
- "INV-078"
operator_sequence:
coherent:
- "security action occurs"
- "Θ prevent secrecy self-certification"
- "Γ classify event / boundary / evidence / opacity scope"
- "Σ define who can know what and why"
- "Π preserve decision, action, control, and repair traces"
- "Au/FI enable audit, appeal, and correction"
- "ℛ repair harm or misclassification"
- "Ψ validate affected-node effects"
- "Τ validate recurrence reduction and L stability"
inverted:
- "security claim appears"
- "opacity expands"
- "Γ classification becomes untraceable"
- "Π denies / restricts / monitors without review path"
- "FI narrows"
- "ℛ disappears"
- "H↑"
- "Ξ / ι↑"
- "L↓"
aliases:
- "Security Legibility Law"
- "Security Must Be Legible Law"
- "Security Traceability Law"
- "Auditable Security Law"
- "Opaque Security Debt Law"
- "Security Claims Require Traceability Law"
- "Legible Security Governance Law"
deduplication_note: "Root security-legibility law. LAW-013 defines general auditability debt. LAW-112 defines security as sustained coherence. LAW-114 defines pseudo-security. LAW-115 defines surveillance-to-restoration routing. LAW-120 defines the traceability requirement that allows security claims, classifications, controls, opacity, and repair pathways to remain audit-valid."
source: "content/archive/laws/technical.md"15. Compact Card Version
LAW-120 — Security Legibility Law
Security must be legible enough to audit, steer, repair, and trust.
Core form:
security must be legible enough to audit, steer, repair, and trustProportionality form:
security_legibility ∝ risk + authority + affected-node impactPlain meaning:
Security may require selective opacity, but it cannot become totally illegible. A system must preserve enough traceability to understand what happened, what boundary was protected, what classification was made, what action occurred, who was affected, what repair path exists, and whether recurrence decreased.
Audit form:
security claim valid ⇔ traceable to boundary + classification + action + effect + repair pathFailure form:
security opacity↑ + Au_eff↓ ⇒ H↑ + L↓Primary variables:
security_legibility, traceability, opacity_scope, security_claim, classification_trace, action_trace, control_trace, boundary_trace, effect_trace, restoration_trace, appeal_path, correction_path, review_path, sensitive_detail_protection, Au, Au_eff, FI, BΣ, R, R_eff, L, H, Γ, Π, Ξ, ℛ, Θ, Σ, Ψ, Τ
Diagnostic signature:
Opacity scope expands while classification trace, action trace, appeal path, restoration trace, and affected-node trust decline. This indicates illegible security.
Failure risk:
Illegible security, opaque security debt, security theater, pseudo-security, audit suppression, black-box enforcement, untraceable classification, untraceable denial, unaccountable surveillance, repair obscurity, boundary ambiguity, legitimacy debt, hidden debt accumulation, trust collapse, security inversion.
Restoration priority:
Identify the security claim, define opacity scope, separate sensitive details from audit-critical trace, reconstruct classification, action, boundary, effect, and restoration trails; restore auditability, review, feedback, appeal, and correction pathways; repair hidden debt; and validate legitimacy over time.