System Classes

BlueWave distinguishes between fundamentally different classes of information systems. These classes do not differ primarily by features. They differ by how authority, identity, duty, and escalation are structured.

Foundational Principle

Every information system belongs to a structural class. Class is not branding. Class is behavioral geometry.

Class determines:

• What information may exist
• Whether identity is inferred
• Whether correlation asserts personhood
• Whether escalation is embedded
• Whether duty accumulates
• Where authority resides

Class is declared before functionality. Function without declared class is architectural negligence.

Why Classification Is Non-Optional

Modern systems tend to drift. Drift occurs when features accumulate, alerts are layered in, visibility expands, correlation widens, or escalation pathways multiply.

Without classification, drift is invisible. With classification, drift is measurable. Class integrity prevents silent duty expansion.

Class A: Identity-first

Definition

Identity-First systems are structured around identifying or correlating individuals. Identity inference is core logic, not incidental capability.

Structural Properties

• Person-centric correlation
• Facial similarity or biometric comparison
• License plate or persistent identifier recurrence
• Cross-incident person linkage
• Investigative case aggregation

Identity is not avoided. It is architecturally central.

Duty Geometry

Identity inference introduces knowledge accumulation, foreseeability expansion, monitoring expectation, and investigative authority assumption.

When a system can connect a person across events, duty shifts. Identity-First systems therefore require:

• Explicit operator-of-record designation
• Defined investigative authority
• Audit logging
• Threshold discipline
• Clear escalation boundaries

Identity systems cannot masquerade as neutral tools. They are investigative by structure.

Appropriate Environments

• Licensed investigative operations
• Authorized security environments
• Loss prevention contexts
• Professional compliance domains

These systems are not appropriate where authority is ambiguous.

Failure Modes

• Lowering similarity thresholds under emotional pressure
• Expanding visibility to unauthorized roles
• Adding automated alerts without governance
• Allowing cross-sector identity blending without formal review

Each failure alters liability posture.

Class B: Privacy-first

Definition

Incident-First systems are structured around events. They preserve observation before identity. They correlate incidents, not people. Identity may exist within narrative but is not algorithmically inferred.

Structural Properties

• Time-stamped incident records
• Secure record preservation
• No automatic identity correlation
• No persistent person profile construction
• Deliberate, human-initiated escalation

These systems accumulate documentation without creating monitoring posture.

Duty Geometry

Incident-First systems reduce implied monitoring, avoid automatic identity assertion, preserve ambiguity, and allow deliberate authority transfer. Duty does not expand through correlation. It remains event-bounded.

Appropriate Environments

• Hospitality
• Ambiguous safety contexts
• Environments with limited authority
• Scenarios requiring preservation without escalation

Failure Modes

• Adding person-based recurrence logic
• Adding alerts that imply oversight
• Converting documentation into enforcement triggers

Any of these converts the system into Identity-First architecture. Class conversion must be explicit.

Class C: Passive Signal Infrastructure

Definition

Passive systems allow input without operational obligation. They do not alert. They do not escalate. They do not compel response. They do not bind identity. They do not accumulate investigative knowledge.

Structural Properties

• No dashboards implying oversight
• No automatic notifications
• No escalation triggers
• No response mandates
• Aggregated pattern visibility only

Signals exist without obligation.

Duty Geometry

Passive systems are designed to avoid duty creation entirely. They do not:

• Create monitoring expectation
• Generate response pressure
• Produce identity inference
• Trigger institutional compulsion

They are infrastructure, not intervention.

Failure Modes

• Adding alerts
• Adding host visibility
• Adding law enforcement hooks
• Adding identity tagging

Each transforms the system class. Passive systems must remain passive.

Class Conversion Doctrine

If a feature adds identity correlation, adds alerts, adds monitoring, adds escalation compulsion, or adds persistent identity storage, the system changes class. Class change is not incremental. It is categorical.

Categorical changes require:

• Governance review
• Explicit reclassification
• Rearticulation of duty posture
• Public clarity

Silent class drift is unacceptable.

Class as Liability Control

System classes allow carrier underwriting clarity, NGO boundary validation, counsel defensibility, and investor category understanding.

Without classification, systems appear flexible. Flexibility is interpreted as unpredictability. Unpredictability increases risk pricing. Class clarity stabilizes geometry.

The Structural Rule

A system may not behave like Class I while claiming to be Class II. A system may not behave like Class II while marketed as Class III. Blend alert logic with passive infrastructure, or blend identity inference into documentation systems—you violate structure.

Each system must be honest about its geometry. Architecture enforces honesty.

Final Canonical Principle

System class is the most important architectural declaration. Before a system can be evaluated ethically, legally, or operationally, it must be classified. Classification defines authority, duty, exposure, expectation, and constraint.

When classes remain clean, geometry holds. When geometry holds, systems survive pressure.