← Back to catalogue
Published

Operational Log / Trace

vr.wm-rec-013 · wm-rec-013-operational-log-trace

Represent append-oriented technical or business event evidence as a governed retained record.

World Models Information and virtual systems INF.REC.LOG
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

3 bundles · 4 layers · 5 findings · 10 questions

Log source and content Where entries come from and what they contain.

Source and schema

The producing system and the structure of entries.

Producing source

The system, component or process that writes the log.

  1. Which system or process wrote the entries, and under which configuration?
  2. Which fields and event types does each entry contain?

Time and ordering

Timestamps, clock source and sequence of entries.

  1. Which clock source and time zone do the timestamps use?
  2. Can the order of entries be established reliably across sources?
Integrity and retention Whether the record can serve as evidence.

Integrity

Protection against change and loss.

Tamper evidence

Controls that show whether entries were altered or removed.

  1. Is the log protected against alteration, for example by hashing or write-once storage?
  2. Are there gaps in sequence numbers or time that suggest lost entries?

Retention

How long entries are kept and when they are destroyed.

Retention rule

The retention period and its legal or policy basis.

  1. Which retention period applies, and on what basis?
  2. Is any entry under legal hold that prevents deletion?
Access and use Who may read the log and for what.

Access control

Permissions and purpose of reading.

Read access

Who read the log and why.

  1. Who has access to the log, and is each access itself recorded?
  2. Does the log contain personal data, and is it masked where possible?

Classifiers Filled

Family
World Models
Category
Information and virtual systems
Entry kind
aggregate
Navigation path
NAV.INF.REC.LOG
Domain
INF.REC.LOG
Industry
Cross-industry
Tags
operationallogtraceinf.rec.log

What it is Filled

An operational log or trace is an append-oriented record of technical or business events, written as they happen and kept as evidence of what a system or process did. It covers log streams, audit trails and stored traces as records with retention and integrity duties; live monitoring signals used only for operations are a neighbouring subject.

In scope

  • Capture identity, provenance, entry interpretation and uncertain time.
  • Retained trace relationships, sampling and integrity evidence.
  • Record access, retention, correction lineage and controlled extracts.

Out of scope

  • Live monitoring, alert evaluation, instrumentation deployment and operational control.
  • Business transaction execution, incident response and adjudication of factual truth or legal admissibility.
  • Generic records platform implementation, storage engine and cryptographic protocol implementation.

Why it exists Filled

Represent append-oriented technical or business event evidence as a governed retained record.

Distinguishing features Filled

  • It is kept as evidence with retention and integrity duties, not only as a live signal.
  • Entries are appended in time order and are corrected by new entries, not edited.
  • It covers business audit trails as well as technical logs and stored traces.
  • Distinct from telemetry used for live monitoring, though the same entries may feed both.

What robots and AI may and may not do Filled

Must not

  • Edit or delete log entries outside the retention rules.
  • Disable logging or reduce its scope without authorisation.
  • Use logs to monitor individual employees beyond what policy and law allow.
  • Expose secrets or personal data found in log entries.
  • Delete entries under legal hold.

Only with a human decision

  • Placing or lifting a legal hold on logs.
  • Approving release of logs to external parties such as investigators.
  • Changing retention periods for audit logs.

May

  • Search and summarise log entries within granted access for a stated purpose.
  • Correlate entries across sources by time and trace identifiers.
  • Flag gaps, clock skew or signs of tampering.
  • Report on retention compliance of log stores.

Moral aspects Filled

  • Logs often contain personal data and can enable surveillance of users and staff.
  • Reliable logs are needed to establish accountability after incidents and disputes.
  • Retaining logs too long increases exposure; deleting them too early destroys evidence.

Who is affected

  • Users whose actions are logged
  • Employees and operators
  • Security and audit teams
  • Investigators and regulators

Owners Filled

Steward

The system owner, with the security or records function, answers for logging, retention and access.

Roles

record custodian
Approve scope and accountable policy bindings.
capture operator
Record collection and export quality without altering source assertions.
authorized analyst
Read purpose-limited views and label inference and uncertainty.
records reviewer
Review retention, preservation and disposition evidence.
security reviewer
Review integrity trust basis and disclosure restrictions.

Master systems

  • Log management platforms
  • Security information and event management systems
  • Audit trail stores

Links to other meta-models Filled

aligned

  • WM-REC-001 - Candidate registry parent alignment; pin a reviewed record profile before inheritance.
  • W3C Trace Context - Optional trace identifier projection, with explicit version and trust-boundary policy.
  • OpenTelemetry logs and traces - Optional mappings with field loss and revision pins; no implementation conformance implied.
  • IETF syslog - Optional message and signed-evidence profiles; transport and cryptographic deployment remain external.
  • W3C PROV-O - Optional provenance vocabulary for derivatives and attribution.

references

  • WM-SFT-017 - Optional source signal reference; no monitoring lifecycle is imported.
  • WM-ACT-020 - Optional incident reference for evidence use and preservation; no incident response execution.

neighbor

  • WM-REC-001 Document / Record - Registry parent is a candidate generic record alignment; this proposal specializes append-oriented evidence without assuming a validated inherited schema.
  • WM-SFT-017 Telemetry / Operational Signal - Telemetry may feed this record; the retained capture has explicit membership, custody and disposition. Live signals and monitoring behavior stay external.
  • WM-ACT-020 Cyber Incident - Incident references can explain preservation purpose, but classification and incident response are not owned here.
  • Producer, actor and business operation masters - Record assertions and references only; a span status or log message does not change the referenced operation.

parent

  • WM-REC-001

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • A log is identified by its source system, stream or file name and the time range covered.
  • Entries carry timestamps and, where available, sequence numbers and trace or request identifiers.

Direct properties not applicable Not applicable

Not applicable

An operational log is an information record with no physical properties to measure.

Recognition optional Filled

  • A log has timestamped, append-only entries from a named source under a retention rule.
  • Often confused with live metrics dashboards, configuration records or ordinary documents.

Capabilities and actions required Filled

  • Entries can be collected, indexed, correlated, archived and destroyed on schedule.
  • Logs can be sealed or hashed to provide tamper evidence.

Hazards and failure modes required Filled

  • Leakage of credentials or personal data written into logs.
  • Loss or tampering that removes evidence after an incident.
  • Misleading conclusions from unsynchronised clocks across sources.

Standards and interfaces required Filled

  • IETF RFC 5424 Syslog Protocol.
  • W3C Trace Context for trace identifiers.
  • OpenTelemetry log and trace data models.

Context of use required Filled

  • Used in IT operations, security monitoring, financial audit and regulatory compliance.
  • Retention and access are shaped by data protection law and sector record-keeping rules.

Sources Filled

  1. Logs Data Model - OpenTelemetry project
  2. Tracing API - OpenTelemetry project
  3. Trace Context - World Wide Web Consortium
  4. RFC 5424: The Syslog Protocol - Internet Engineering Task Force
  5. SP 800-92: Guide to Computer Security Log Management - National Institute of Standards and Technology
  6. RFC 5848: Signed Syslog Messages - Internet Engineering Task Force
  7. PROV-O: The PROV Ontology - World Wide Web Consortium
  8. Tracing SDK - OpenTelemetry project
  9. NIST SP 800-92 Guide to Computer Security Log Management (NIST)

Open questions

  • Pin source revisions and compatible log, trace and propagation profiles; review errata and current integrity requirements.
  • Develop nested schemas and fixtures for delayed entries, missing parents, duplicate IDs, sampled spans, redaction, partial export and disposition across copies.
  • Obtain independent external review and qualified sector policy review before promotion beyond reviewable-draft.
  • No independently reviewed external-provider result.
  • Direct HTTP checks are not executed in the blocked sandbox; source versions, errata and immutable living-document pins remain open.
  • Candidate object groups are not executable nested instance schemas; adapters, scale testing and adversarial fixtures remain future work.
  • Sector-specific audit obligations, privacy applicability and business audit semantics require qualified profile review.
  • Historical integrity references do not establish current algorithm suitability.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-rec-013-operational-log-trace/spec.yaml, ver-cy/world-models/card-supplements/wm-rec-013-operational-log-trace.json