Evidence and audit logs

Evidence explains why a decision or result should be trusted. An audit event records that an activity occurred. Ethen exposes evidence, logs, traces, receipts, and audit-oriented surfaces, but their data sources and persistence differ.

The /audit-log route is explicitly Private Alpha and Sample, and it reads fixture entries. The sections below show how to interpret those records without presenting a demonstration table as a durable production audit trail.

Evidence types

Evidence can include input validation results, policy decisions, approval context, provider attempts, request identifiers, traces, errors, run receipts, artifacts, repository references, or generated diffs. Each type answers a different question.

A receipt can summarize an operation. A trace can connect nested work. An artifact is an output or file. A finding points to a candidate issue. None of those terms should be used as a generic synonym for “audit log.”

Evidence should carry provenance: the subsystem, data source, owner, time, and correlation identifier. Fixture and demo records must remain labeled.

Evidence quality dimensions

Evidence quality depends on more than the number of fields. Evaluate:

• provenance: which runtime or store created the record;
• correlation: whether it links to the request, actor, resource, or provider;
• integrity: whether the record can be changed and by whom;
• completeness: which steps or fields are omitted;
• freshness: whether the record reflects the relevant time;
• persistence: whether it survives restarts and deployments;
• access: who can read or export it;
• honesty state: live, bridged, fixture, sample, demo-only, or unavailable.

A screenshot may preserve what a reviewer saw, but it can lose machine-readable identifiers and does not prove backend integrity. A trace may show execution order while omitting the approval evidence. Use the record that answers the investigation question instead of preferring one generic “audit” source.

Evidence versus assertion

A configuration page can assert that a provider is ready; a successful provider response is stronger operational evidence for that capability. A policy description can assert that approval is required; a correlated pending decision and absence of the side effect demonstrate the boundary more directly.

Rank evidence according to the claim being made. Use interface labels for product state, backend records for persistence, provider identifiers for external execution, and deployment configuration for infrastructure controls. Avoid asking one record to prove a boundary it does not observe.

Audit events

A useful audit event identifies the actor, action, resource, outcome, and time. Additional fields may include policy result, approval state, provider, project, request ID, or error code where the producing runtime supplies them.

The current audit interface demonstrates an intended view with sample fixtures. It does not establish durable ingestion from every Gateway request, workflow, provider call, project change, or security review.

Do not infer event completeness from the table columns. A fixture can populate a field even when no production emitter writes it.

Event design example

A provider-request event might record an Ethen request ID, actor or API-key identifier, project, requested model, selected provider, outcome, latency, and error code. It should not record the raw API key or provider credential. A policy event can record the evaluated action, resource, decision, and reason. An approval event can record the proposal, reviewer, decision, and time.

These examples describe useful event shapes, not guaranteed platform-wide emissions. The current sample audit route may display similar columns without receiving events from all runtimes.

Avoid combining several stages into one ambiguous event. A request accepted by Ethen, provider attempt, and final response can have different outcomes and times.

Required and optional events

A deployment should define which events are required for its operating model. Credential creation or revocation, policy changes, approval decisions, project access changes, and provider-route changes often carry more governance value than ordinary page views.

Required-event coverage should be tested by performing a safe action and confirming the expected record in the intended durable store. The sample audit route cannot serve as that test because its entries are fixtures.

Event clocks and ordering can differ across the browser, Ethen server, database, and external provider. Preserve timestamps with their source and timezone where available. Do not infer exact causal order from close timestamps when no shared trace connects the events.

A durable audit design should also handle retries and duplicate delivery without turning one action into several misleading events. That ingestion behavior is not yet verified platform wide.

Access

Audit and evidence records can expose sensitive information about users, repository paths, provider accounts, prompts, errors, and internal structure. Access should be narrower than general product access and should be tied to the record’s owner.

A complete audit-reader role or organization model is not verified. Administrators should review the actual route and backend authorization before using the surface for customer data.

Avoid copying raw credentials, full prompts, or unnecessary content into an audit event. Correlation identifiers and concise summaries are usually safer for investigation.

Sensitive fields and redaction

An error or trace can contain prompt fragments, file paths, repository names, model identifiers, provider account details, or internal stack information. Evidence access should be reviewed with the same care as the source data.

Prefer identifiers and structured reasons over full content. Where content is necessary, restrict the viewer and document why it is included. Redaction should happen before the record reaches a general log store because later masking does not remove earlier copies.

The lack of a complete audit-reader role means administrators must inspect the actual route and data query. Do not assume that an “operator” audience label enforces access.

Investigation access

Incident responders may need temporary access to records that ordinary operators should not see. No dedicated investigative role or just-in-time access process is verified. Customers should define that process outside Ethen if necessary and record when the temporary access ends.

Exporting or copying sensitive evidence into another system creates a new data-handling and retention boundary. Limit the copied content to what the investigation requires.

Review evidence access after organizational or project changes. A person who no longer operates a product may still retain access to sensitive historical logs unless the data route and backend ownership are updated together.

Retention

No fixed retention period is defined for audit events, logs, traces, or evidence. Fixture records do not demonstrate retention at all, and bridged observability data may depend on the underlying runtime.

A production decision should specify which events are required, where they are stored, how long they remain, and how deletion or legal preservation is handled. Audit retention should be separate from prompt, output, backup, and provider retention.

Do not call a record immutable when the backing store and write controls have not been verified.

Retention by investigation value

Authentication events, provider attempts, cost estimates, content-bearing errors, approval decisions, and security findings can require different retention. A single period can either keep sensitive content too long or remove high-value decision evidence too early.

Define the purpose and deletion trigger for each event class. If a legal or incident preservation requirement applies, record the exception and end condition. No central legal-hold workflow is established.

Fixture entries should be excluded from retention reporting because they are not customer history. Bridged records inherit constraints from their source system.

Exports

Production audit export is not verified. The presence of a table or query layer does not establish CSV, PDF, SIEM, webhook, or API export.

If an investigation requires data outside the current surface, use the supported record source and an approved operational procedure. Manual copying can lose provenance and should not be represented as a product export feature.

Any future export must preserve access control, redaction, ordering, identifiers, and data-source labels.

Export readiness requirements

A trustworthy export needs stable field definitions, ordering, pagination or completeness guarantees, authorization, redaction, time boundaries, and a way to identify its source. It also needs a format that preserves correlation identifiers without leaking secrets.

None of those guarantees follows from a rendered table. Before calling a future capability an audit export, verify that it includes all selected events, labels fixture or bridged data, and records who created the export.

Manual screenshots or copied rows can support a small review, but label them as manual evidence rather than a product-generated export.

Exports also create a new copy with its own access and retention. Even after an export feature is implemented, the operator must control the destination and avoid using an unrestricted file as a substitute for governed audit access.

Operational use

Use audit-oriented records to answer a scoped question: who changed a setting, why a policy blocked a request, which provider attempt failed, or whether a proposed action received approval. Begin with the product record most closely tied to the event.

Check the data-honesty label before drawing conclusions. Fixture data is suitable for interface evaluation; unavailable data indicates a coverage gap; bridged data depends on the source runtime.

For incident work, preserve identifiers and timestamps without claiming completeness. If no durable record exists, document that limitation in the incident timeline.

Investigation workflow

Begin with the symptom and time window. Locate the closest live product record, then follow request, trace, run, provider, policy, or approval identifiers into related records. Note where the chain ends because a runtime did not emit data.

Compare application records with external provider or identity-provider records where relevant. A provider can confirm that a credential was used even when Ethen lacks a durable credential-access event. An identity provider can confirm a session while the product store explains which project was read.

Conclude with both findings and evidence gaps. A report that states “no evidence available” is more accurate than one that treats fixture data as proof.

Coverage report

Periodically compare important actions with the evidence they should produce. Record whether the event is live, bridged, fixture, or unavailable and whether actor, resource, outcome, and correlation fields are present.

This coverage report turns “audit logging exists” into a set of testable statements. It also identifies which products require additional emitters or durable storage before they can support production investigations.

For recurring operational reviews, select a small set of high-value actions and test their evidence paths after major releases or backend changes. Credential revocation, policy denial, approval requirement, and project access change are useful examples because they cross several control layers.

Document failures as coverage gaps. Do not populate a missing event manually in a way that makes it appear system generated.