HARS-ELA · Evidence Layer Audit · v1.1

HARS-ELA

An evidence layer audit. Surfaces observable system structure. Produces verifiable artifacts. Does not certify, score, or interpret.

What HARS-ELA Is

HARS-ELA is an evidence layer audit that operates on source code and project structure. It runs static analysis across multiple detection layers and produces structured artifacts documenting what is structurally present.

It occupies a defined position in the analysis stack: below interpretation, above raw code. It does not reason about behavior or assign meaning to findings. It records what is observable and documents it in a traceable, hash-sealed artifact.

HARS-ELA is not a certification. It produces evidence.

What It Is For

HARS-ELA makes system structure visible before assumptions accumulate and before formal audit begins.

  • —Make system surface observable — what constructs are present, where, and in what structural context.
  • —Reduce inference — replace assumption with documented pattern detection.
  • —Produce traceable artifacts — hash-sealed, timestamped, chain-linked records of scan findings.
  • —Separate evidence from interpretation — the artifact documents structure; analysis belongs to the reader.

What It Produces

Each scan produces a structured Evidence Layer Artifact: a plain-text document partitioned into observation modules, sealed with a SHA-256 hash, and linked to the HARS audit chain. An Amber Ticket — a machine-readable JSON provenance record — is written alongside every artifact.

The artifact contains pattern detections, not conclusions. Each module records what was found, where, and in what structural context. No module produces a score, a risk level, or a recommendation.

#ModuleLayer
01

Observed Claim Surface

Detects authority-bearing constructs across all scanned layers. Identifies language that asserts identity, assigns roles, evaluates users, or frames system relationships. Classified by severity tier and surface layer.

core
02

Infrastructure Observations

Surfaces infrastructure code patterns relevant to external service bindings, network calls, and dependency configurations. Records structural indicators — not operational state.

core
03

Security Observations

Detects security-relevant code patterns: authentication logic, permission constructs, cryptographic references, and access control surface. Documents pattern presence, not implementation correctness.

core
04

Timeline Integrity Notes

Records the artifact's position in the HARS-ATC audit chain. Cryptographic hash linking to prior entries. Static metadata only — no live event correlation.

core
05

Sensitive Data Surface

Scans source files for indicators of sensitive data class references: identity, financial, diagnostic, therapeutic, clinical, and authentication constructs. Records presence per file and line — not data state.

HDE
06

Data Handling Pathways

Detects co-occurrence of sensitive data class references and data handling actions within a configurable line window. Documents structural proximity — not intent or execution.

HDE
07

Security Control Presence

Identifies protection constructs proximate to sensitive data class references. Records adjacency as a structural observable. Presence is not protection.

HDE
08

Exposure-Relevant Patterns

Detects structural patterns associated with potential data exposure: inline credential references, logging constructs near sensitive class indicators, serialization paths. Pattern is not breach.

HDE
09

Retention and Deletion Evidence

Surfaces code-level indicators of retention and deletion logic: hard delete operations, soft delete markers, TTL references, right-to-erasure handlers, and no-delete declarations. Structure is not retention state.

HDE
10

Runtime Conditions

Documents scan envelope metadata: engine version, protocol, active scope, file surface, exclusion configuration, and detection layer status at artifact generation time.

core

HDE — Human Data Evidence layer. Five additive modules that surface sensitive data constructs, handling pathways, protection proximity, exposure patterns, and retention signals. Included in full-scope scans. Evidentiary proximity tiers replace severity tiers in HDE sections.

How It Works

HARS-ELA performs static source analysis. Files in the target directory are read, pattern detection is applied across configured evidence modules, and findings are classified into structural categories. No code is executed. No network calls are made.

→

File surface scan

All in-scope files are read line-by-line. Exclusion directories and file size ceilings are applied before scanning begins.

→

Detection layers

Each active module applies its indicator set to the file surface. Co-occurrence windows, proximity rules, and context filters govern classification within each module.

→

SAL-X contextual review

Speech Act Layer Extended applies downgrade rules to findings matching developer-context signals — comments, tests, configuration-only paths, type annotations. Downgrades are logged explicitly.

→

Artifact generation

Findings are formatted into a structured plain-text artifact partitioned by module. A SHA-256 hash is computed over artifact content and written to the Amber Ticket.

→

Chain entry

The artifact is registered in the HARS Audit Trail Continuity chain. Each entry is hash-linked to the prior entry. Chain integrity is verifiable at any time.

How It Is Used

Developers

  • Internal visibility — inspect what constructs are present before deployment.
  • Surface debugging — locate authority, credential, or sensitive data indicators by file and line.
  • Pre-audit inspection — understand what a formal HARS audit will encounter.
  • Scope targeting — run individual evidence modules against specific directories.

Organizations

  • External artifact sharing — ELA artifacts are shareable, hash-verifiable records of system surface.
  • Transparency layer — document observable constructs in a deployed system.
  • Audit preparation — identify gaps before a formal HARS certification engagement.
  • Ongoing evidence — re-scan on any commit to maintain a traceable artifact history.

Observational Boundary

HARS-ELA documents structure. It does not document outcomes, intent, risk, or compliance state. The following are non-negotiable properties of what this system is.

Presence is not protection.

A security construct appearing in code does not establish that it is correctly implemented, actively enforced, or effective against any threat model.

Absence is not proof of absence.

Constructs outside the scan boundary — runtime-injected controls, infrastructure-level configurations, or code not reached by static analysis — are not represented in any artifact section.

Pattern is not breach.

An exposure-relevant pattern does not establish that a breach occurred, that data was unlawfully disclosed, or that any individual was affected.

Structure is not retention state.

Retention or deletion constructs in source code do not establish the actual retention state of data in any storage system at any time.

Reference is not data presence.

A reference to a sensitive data class does not establish that data of that class exists in any system, was collected, or was processed.

These statements appear verbatim in every HDE artifact section. They are not disclaimers. They are definitional constraints on what the output of this system means.

Relation to HARS

HARS-ELA and HARS are distinct instruments. They share an audit chain, a detection engine, and a file surface. They produce different outputs with different authority.

HARS-ELA

Evidence layer

Developer-facing

Exploratory

Non-certifying

Produces artifacts

Entry point

HARS

Full audit

Auditor-facing

Determinative

Certifying

Produces verdicts

The standard itself

A passing HARS-ELA scan does not indicate HARS compliance. HARS-ELA does not assess the Five Gates, does not evaluate behavioral constraints, and does not issue or imply a Seal. ELA artifacts are evidence inputs — not certification outputs.

Organizations may use ELA artifacts as part of audit preparation or share them as structural transparency records. They may not represent ELA artifacts as HARS certification or as evidence of HARS compliance.

Artifact Integrity

Every ELA artifact is assigned a unique audit ID and registered in the HARS Audit Trail Continuity chain — the same chain used by the HARS certification audit. Each entry is hash-linked to its predecessor. The chain is publicly verifiable.

Artifact

HARS_ELA_ARTIFACT_<target>_<ts>.txt

Amber Ticket

HARS_AMBER_TICKET_<target>_<ts>.json

Chain entry

HARS_AUDIT_<YYYYMMDD>_<HHMMSS>.json

Integrity

SHA-256 hash over artifact content

Positioning

HARS-ELA does not replace HARS. It supports visibility before formal audit. It is a structural inspection tool, not an authority instrument.

Organizations seeking certification engage the HARS certification process directly. HARS-ELA may precede that process. It cannot substitute for it.

Not a score. Not a verdict. Not a claim of safety or compliance.
An artifact of what is structurally present.