WEB / WEB-21.S04

Audit evidence, detection and incident scope

Separate HTTP status, business audit, correlation and incident scope in a Tea note event chain.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Expected denial

Audit source selected
The application knows fixed event objects for Atlas/op-demo/tea. The audit writer has not produced allowlisted JSON lines and correlation is not computed; every step is a local record operation.
Application
Fixed event source
Audit writer
No output yet
Correlation
No correlation yet
Reviewer
Scope unknown
Allowlist output produced
The structured serializer copies only schema fields; fake session values and note bodies remain excluded.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
No correlation yet
Reviewer
Scope unknown
Compute tuple relation
Tenant, operation and object are compared together; Nova’s reused request alias does not join Atlas.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
expected-denial
Reviewer
Scope unknown
Evidence scope recorded
Missing records remain unknown; outcomes for objects or tenants beyond the known tea operation are not invented.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
expected-denial
Reviewer
tea / Atlas; others unknown
Review checkpoint boundary
New state validation leaves historical audit intact; this fixture does not start production recovery.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
expected-denial
Reviewer
Bounded checkpoint validated

Event discrepancy

Audit source selected
The application knows fixed event objects for Atlas/op-demo/tea. The audit writer has not produced allowlisted JSON lines and correlation is not computed; every step is a local record operation.
Application
Fixed event source
Audit writer
No output yet
Correlation
No correlation yet
Reviewer
Scope unknown
Allowlist output produced
The structured serializer copies only schema fields; fake session values and note bodies remain excluded.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
No correlation yet
Reviewer
Scope unknown
Compute tuple relation
Tenant, operation and object are compared together; Nova’s reused request alias does not join Atlas.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
review-required
Reviewer
Scope unknown
Evidence scope recorded
Missing records remain unknown; outcomes for objects or tenants beyond the known tea operation are not invented.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
review-required
Reviewer
tea / Atlas; others unknown
Review checkpoint boundary
New state validation leaves historical audit intact; this fixture does not start production recovery.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
review-required
Reviewer
Review-required

Missing record

Audit source selected
The application knows fixed event objects for Atlas/op-demo/tea. The audit writer has not produced allowlisted JSON lines and correlation is not computed; every step is a local record operation.
Application
Fixed event source
Audit writer
No output yet
Correlation
No correlation yet
Reviewer
Scope unknown
Allowlist output produced
The structured serializer copies only schema fields; fake session values and note bodies remain excluded.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
No correlation yet
Reviewer
Scope unknown
Compute tuple relation
Tenant, operation and object are compared together; Nova’s reused request alias does not join Atlas.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
unknown
Reviewer
Scope unknown
Evidence scope recorded
Missing records remain unknown; outcomes for objects or tenants beyond the known tea operation are not invented.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
unknown
Reviewer
tea / Atlas; others unknown

Clock uncertain

Audit source selected
The application knows fixed event objects for Atlas/op-demo/tea. The audit writer has not produced allowlisted JSON lines and correlation is not computed; every step is a local record operation.
Application
Fixed event source
Audit writer
No output yet
Correlation
No correlation yet
Reviewer
Scope unknown
Allowlist output produced
The structured serializer copies only schema fields; fake session values and note bodies remain excluded.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
No correlation yet
Reviewer
Scope unknown
Compute tuple relation
Tenant, operation and object are compared together; Nova’s reused request alias does not join Atlas.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
Clock order unknown
Reviewer
Scope unknown
Evidence scope recorded
Missing records remain unknown; outcomes for objects or tenants beyond the known tea operation are not invented.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
Clock order unknown
Reviewer
tea / Atlas; others unknown
Review checkpoint boundary
New state validation leaves historical audit intact; this fixture does not start production recovery.
Application
Fixed event source
Audit writer
Selected JSON lines
Correlation
Clock order unknown
Reviewer
Bounded checkpoint validated

ACTORS · STATE · DATA FLOW

HTTP records and business decisions

A Tea note HTTP access record describes the server observing a request and its response status. Business audit describes actor Duru, action rename-note, object tea, tenant Atlas, decision deny and reason owner-policy. These events serve different purposes. A public explanatory response can be 200 while rename-note remains denied; the status alone is not a business commit receipt. An event generated near the application’s policy decision has different evidential authority from an actor label inferred from an external request header.

Here operationAlias op-demo and requestAlias req-demo are correlation labels, not credentials, principals or permissions. The session correlation alias is an inert group label instead of a real session identifier. User and tenant relationships come from application context; jobAlias associates a later worker activity with the same operation. One HTTP request can contain several business actions, and an async action can create several job attempts. Event IDs, parent IDs, action/object and producer therefore express relationships more precisely than joining every record on one request string.

Baselines, missing evidence and incident bounds

The finite detector searches for deny plus committed=true within a tenant, operationAlias and object tuple. Normal deny/committed=false yields zero and a deliberately synthetic contradiction yields one. This fixture does not establish a real policy violation; it identifies inconsistent records requiring review. If tenant Nova reuses req-demo, its record is not joined to Atlas. A missing commit record is not defaulted to committed=false: the result is unknown. Expected denial, contradictory evidence and missing evidence remain distinct outcomes. When a tuple contains several records, all are evaluated; ordering or an identical event repeat cannot change the outcome. Conflicting completed decisions remain ambiguous and missing fields unknown; neither is an automatic incident judgment.

Wall-clock ordering across different producers does not establish causality. The artifact may show app time 10:00:02 and worker time 09:59:59; an explicit parent-event relationship and same-producer sequence provide narrower ordering evidence. Bound incident statements accordingly: tea and the selected operation are known in this ledger, while other objects and tenants are unmeasured. Recovery is not merely closing an alert; it requires validation of the selected owner state and a new checkpoint. Deleting or changing old records cannot strengthen history; preserve provenance, access boundaries and retention.

Read every scenario without motion

Alias scope

HTTP200 is another fact
http-demo has status 200 while decision-demo denies with committed false. Transport status establishes neither business acceptance nor Duru’s object authority.
Audit event ledger
HTTP200 / business deny/false
Tuple/producer comparison
Not yet evaluated
Scope outcome
Not yet evaluated
Composite tuple
Nova reuses req-demo and op-demo but has a different tenant. Omitting tenant/operation/object scoping can misattribute unrelated allow/true to Atlas.
Audit event ledger
HTTP200 / business deny/false
Tuple/producer comparison
Atlas tuple ≠ Nova tuple
Scope outcome
Not yet evaluated
Normal expected denial
The normal Atlas/op-demo/tea business row is deny/false and yields expected-denial. This ordinary policy result proves neither a successful attack nor malicious Duru.
Audit event ledger
HTTP200 / business deny/false
Tuple/producer comparison
Atlas tuple ≠ Nova tuple
Scope outcome
Expected denial / no incident verdict
Producer-clock difference
The job can show 09:59:59 before decision 10:00:02, with a separate declared parent relation. Cross-producer wall-clock order is unknown; timestamps do not establish global causality.
Audit event ledger
Declared parent relation / clock order unknown
Tuple/producer comparison
Atlas tuple ≠ Nova tuple
Scope outcome
Expected denial / no incident verdict
Parent-relation trust
parentEventId is a producer-declared relation, not cryptographic authenticity. Source context and completeness are separate; matching event IDs grant no user authority.
Audit event ledger
Declared parent relation / clock order unknown
Tuple/producer comparison
Declared relation ≠ authentic authorization
Scope outcome
Expected denial / no incident verdict
Keep impact scope narrow
Known scope is only Atlas and tea. Other tenants/objects remain unknown; similar aliases do not justify extending incident scope to every tenant.
Audit event ledger
Declared parent relation / clock order unknown
Tuple/producer comparison
Declared relation ≠ authentic authorization
Scope outcome
Known Atlas/tea / other scope unknown

All matching rows

First matching row
The comparator does not stop at the first business row. lateContradiction has two unique rows and a later deny/true contradiction; row order should not change the result.
Audit event ledger
Inspect all matching business rows
Tuple/producer comparison
Not yet evaluated
Scope outcome
Not yet evaluated
Explicit contradiction
Any unique deny/true requires review, while ambiguity stays visible. This synthetic contradiction is not presented as an actual policy violation or actor-intent proof.
Audit event ledger
Inspect all matching business rows
Tuple/producer comparison
Deny/true → review-required / ambiguity retained
Scope outcome
Not yet evaluated
Duplicate semantics
An identical duplicate has two matching rows but only one unique row. Counting a complete repeated record as two business effects invents incident magnitude.
Audit event ledger
Inspect all matching business rows
Tuple/producer comparison
Deny/true → review-required / ambiguity retained
Scope outcome
Matching2 / unique1 / expected-denial
Conflicting complete records
Different complete outcomes and changed fields under the same event ID are ambiguous. Changed fields are not an identical repeat, and the detector retains that difference.
Audit event ledger
Complete conflict / changed ID fields ambiguous
Tuple/producer comparison
Deny/true → review-required / ambiguity retained
Scope outcome
Matching2 / unique1 / expected-denial
Incomplete priority
laterIncomplete has one incomplete row and unknown result. Without explicit contradiction, defaulting missing commit to false weakens evidence completeness.
Audit event ledger
Complete conflict / changed ID fields ambiguous
Tuple/producer comparison
Incomplete evidence → unknown
Scope outcome
Matching2 / unique1 / expected-denial
Review-verdict boundary
The comparator selects attention and uncertainty in a finite supplied ledger. It runs no SIEM, identity verification or production recovery; review-required is not automatic user blocking or attack declaration.
Audit event ledger
Complete conflict / changed ID fields ambiguous
Tuple/producer comparison
Incomplete evidence → unknown
Scope outcome
Finite review classification / no incident verdict

ASSUMPTION · BOUNDARY · CONTROL

When correlation is mistaken for authority

Normal logging makes an application decision understandable later. Its trust assumption binds an event to the correct source, identity context and operation. Reused request labels or a missing tenant can make unrelated work appear to be one chain. The impact may be incorrect attribution or an unnecessarily broad incident scope; matching a label never proves a user’s authority over an object. Composite correlation, source context and unknown handling for missing fields block that mistaken inference. The branch is tested with fixed Atlas/Nova rows and generates no live requests.

A denial/commit disagreement matters when authoritative records describe the same operation. An unverified client report, an older projection or a different retry attempt does not carry the same evidential weight. ParentEventId is a producer-declared relationship; it does not independently provide cryptographic authenticity or non-repudiation. The fixture explicitly supplies its source model. Calling a discrepancy a successful attack before reviewing context and provenance adds assumptions instead of explaining the actual impact.

Logs are also data requiring protection

Copying an entire request into logs can include session values, tokens, personal information or note bodies alongside the few fields needed for correlation. The ordinary purpose is to explain an action’s result; that broad copy is unnecessary for this purpose. An allowlist and minimization provide the control. The source fixture contains fake Authorization, a fake sessionIdentifier and ordinary noteText, but audit output contains none of them. Review access is limited to needed event fields; using hashes or aliases does not automatically remove linkability risk.

A log viewer or export format is itself an interpreter. Use structured serialization for the chosen schema rather than concatenating free text into record boundaries; delimiters and newlines remain encoded data. This example processes JSON lines and constructs no malicious log input. Mandatory business audit and optional diagnostics require distinct failure policies; silently writing no records is not evidence of a clean system. Protect the ledger with separately authorized read/write access, recognition of a missing collector and controlled disposal at the end of retention.

Read every scenario without motion

Audit controls

Allowlisted field set
The schema selects necessary event/tenant/operation/object and decision/commit fields. Fake Authorization, session identifier and note text stay out of output; whole-request logging is unnecessary.
Allowlisted audit records
Allowed metadata / excluded fake sensitive fields
Correlation/completeness review
Not yet evaluated
Scope and checkpoint
Not yet evaluated
Tuple-correlation control
Atlas/op-demo/tea business rows are separated from Nova. Job alias extends the relation only when a job record exists; missing records do not imply execution.
Allowlisted audit records
Allowed metadata / excluded fake sensitive fields
Correlation/completeness review
Composite tuple / observed job relationship
Scope and checkpoint
Not yet evaluated
All-row outcome control
Normal denial, deny/true review, identical repeats and missing-commit unknown are compared. Reordering inputs must not introduce first-row bias.
Allowlisted audit records
Allowed metadata / excluded fake sensitive fields
Correlation/completeness review
Composite tuple / observed job relationship
Scope and checkpoint
All-row priority / repeat/order controls
Source and time coverage
Same-producer sequence can establish order while cross-producer clock order stays unknown. Declared parent relations do not automatically establish root-cause certainty.
Allowlisted audit records
Producer sequence / clock trust separate
Correlation/completeness review
Composite tuple / observed job relationship
Scope and checkpoint
All-row priority / repeat/order controls
Recovery is a new checkpoint
Restored owner Duru and validated true describe a new supplied state while historical events remain. Recovery does not erase past records, and productionRestore is false.
Allowlisted audit records
Producer sequence / clock trust separate
Correlation/completeness review
New validated state / historical ledger retained
Scope and checkpoint
All-row priority / repeat/order controls
Bounded review receipt
Review retains Atlas/tea scope with confidence and unknowns. Minimized structured records need no private body; finite comparison is not expanded into actual incident detection.
Allowlisted audit records
Producer sequence / clock trust separate
Correlation/completeness review
New validated state / historical ledger retained
Scope and checkpoint
Known scope + uncertainty / no production claim

Audit gap

Missing business event
No matching business row exists; missing result is unknown with null commit. HTTP200 or empty detector output cannot establish healthy policy enforcement.
Allowlisted audit records
Business observation absent / committed unknown
Correlation/completeness review
Not yet evaluated
Scope and checkpoint
Not yet evaluated
Collector-coverage gap
Absence could reflect no event, lost fields or collector failure. The normal deny/false row is not copied as an authoritative decision for an incomplete event.
Allowlisted audit records
Business observation absent / committed unknown
Correlation/completeness review
Absent evidence ≠ verified negative event
Scope and checkpoint
Not yet evaluated
Impact uncertainty
Actor intent, commit and other tenant/object impact remain UNKNOWN. Extending known scope requires separate context; a user alias alone does not complete attribution.
Allowlisted audit records
Business observation absent / committed unknown
Correlation/completeness review
Absent evidence ≠ verified negative event
Scope and checkpoint
Commit/intent/other-scope impact UNKNOWN
Required source bindings
Required schema, producer context, composite tuple and collector coverage are needed. Every matching row needs completeness checks; first-match shortcuts cannot answer this.
Allowlisted audit records
Needed: source/schema/tuple/coverage/all rows
Correlation/completeness review
Absent evidence ≠ verified negative event
Scope and checkpoint
Commit/intent/other-scope impact UNKNOWN
Narrow selector knowledge
XPath selects deny/true in one XML document; missing documents may yield zero. That zero proves neither real SIEM event absence, complete retention nor pipeline reliability.
Allowlisted audit records
Needed: source/schema/tuple/coverage/all rows
Correlation/completeness review
Zero matches ≠ adequate evidence coverage
Scope and checkpoint
Commit/intent/other-scope impact UNKNOWN
Boundary for new review
New evidence must complete known-tuple and collector context separately. This missing record remains unknown and triggers no automatic incident verdict, user disabling or recovery.
Allowlisted audit records
Needed: source/schema/tuple/coverage/all rows
Correlation/completeness review
Zero matches ≠ adequate evidence coverage
Scope and checkpoint
Retain unknown / scoped human review evidence

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Selector results and evidence sufficiency

The detector schema requires eventId, tenant, operationAlias, object, decision and committed. The comparator inspects every business row in the same tuple rather than stopping at the first match. An identical repeated eventId with identical fields counts as one piece of evidence. Any unique deny/true row yields review-required. Differing completed outcomes in the tuple, or differing fields under the same eventId, also retain an ambiguity flag; without explicit deny/true the result is ambiguous. Missing commitment remains unknown. This finite Python comparison proves neither a real policy violation nor SIEM deployment. XPath separately selects deny/true business rows within one XML document: negative yields zero, positive one, and missing data zero; the last result is not a healthy baseline.

Reduce false conclusions by considering older revisions, different tenants, explained retries and ordinary policy denial. Job correlation extends the chain only when a worker event exists; its absence cannot establish job execution. Record clock confidence and producer identity separately. Same-producer sequence may establish order while order across clocks remains unknown. The key question is both how many rows were selected and whether the required evidence set actually exists; missing-field and collector-health evidence therefore remain separate.

Bounding incident and recovery decisions

A review note first states the observation: the selected decision and commit records disagree for Atlas/op-demo/tea. It then adds confidence and provenance: fixed fixture, supplied producer context and clock uncertainty. Bound impact to that evidence; neither all tenants being affected nor Duru being malicious follows. NIST incident guidance emphasizes analysis, magnitude assessment and evidence provenance. This example neither blocks users automatically nor starts recovery operations; it presents the known and unknown fields to the decision owner.

Recovery evidence uses a new checkpoint to validate owner state and the expected business invariant; the historical contradiction remains. In the finite example restoredOwner Duru and validated=true describe a selected state check, not restoration of an external application, backup or production service. Durable hardening preserves the source schema, unknown behavior on field loss, audit-pipeline failure checks and purpose-limited reviewer access. The next regression review can compare this known tuple again, but cannot silently pass systems outside its scope.

NOW APPLY IT TO THE CASE

Do 200, parent relation or equal aliases prove an incident?

Atlas/op-demo/tea has HTTP200, business denial with committed false and a worker job record. Nova reuses the request alias but belongs to another tenant. The job clock looks earlier than its parent; producer clocks do not establish global order. The comparator inspects every business row in the tuple.

Separate decisions for verified actor, tenant relation and requested action in the case. Do not substitute authentication or proof success for object permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Tea note audit and scope ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "schemaFields": [
    "eventId",
    "parentEventId",
    "kind",
    "tenant",
    "requestAlias",
    "operationAlias",
    "sessionCorrelationAlias",
    "userAlias",
    "jobAlias",
    "actor",
    "action",
    "object",
    "decision",
    "reason",
    "committed",
    "producer",
    "sequence",
    "time",
    "status"
  ],
  "ledger": [
    {
      "eventId": "http-demo",
      "kind": "http",
      "tenant": "Atlas",
      "requestAlias": "req-demo",
      "operationAlias": "op-demo",
      "object": "tea",
      "status": 200,
      "producer": "app",
      "sequence": 1
    },
    {
      "eventId": "decision-demo",
      "parentEventId": "http-demo",
      "kind": "business",
      "tenant": "Atlas",
      "requestAlias": "req-demo",
      "operationAlias": "op-demo",
      "sessionCorrelationAlias": "session-group-demo",
      "userAlias": "Duru",
      "actor": "Duru",
      "action": "rename-note",
      "object": "tea",
      "decision": "deny",
      "reason": "owner-policy",
      "committed": false,
      "producer": "app",
      "sequence": 2,
      "time": "10:00:02"
    },
    {
      "eventId": "job-demo",
      "parentEventId": "decision-demo",
      "kind": "job",
      "tenant": "Atlas",
      "operationAlias": "op-demo",
      "jobAlias": "job-demo",
      "object": "tea",
      "producer": "worker",
      "sequence": 1,
      "time": "09:59:59"
    },
    {
      "eventId": "nova-demo",
      "kind": "business",
      "tenant": "Nova",
      "requestAlias": "req-demo",
      "operationAlias": "op-demo",
      "object": "tea",
      "decision": "allow",
      "committed": true,
      "producer": "app",
      "sequence": 3
    }
  ],
  "excludedSeed": {
    "Authorization": "FAKE-AUTH-ALIAS",
    "sessionIdentifier": "FAKE-SESSION-ALIAS",
    "noteText": "Tea note\nSecond line"
  },
  "correlationKeys": [
    "tenant",
    "operationAlias",
    "object"
  ],
  "normal": {
    "result": "expected-denial",
    "contradictions": 0
  },
  "contradiction": {
    "decision": "deny",
    "committed": true,
    "result": "review-required",
    "contradictions": 1,
    "syntheticNotActualPolicyViolation": true
  },
  "missing": {
    "result": "unknown",
    "committed": null
  },
  "clock": {
    "parentRelation": "decision-demo → job-demo",
    "crossProducerWallClockOrder": "unknown"
  },
  "scope": {
    "knownObjects": [
      "tea"
    ],
    "knownTenants": [
      "Atlas"
    ],
    "otherObjects": "unknown",
    "otherTenants": "unknown"
  },
  "recovery": {
    "restoredOwner": "Duru",
    "validated": true,
    "historicalEventsRetained": true,
    "productionRestore": false
  },
  "selector": {
    "xml": "<audit><business decision=\"deny\" committed=\"false\"/></audit>",
    "xpath": "count(/audit/business[@decision=\"deny\" and @committed=\"true\"])",
    "expected": 0,
    "positiveFixtureXml": "<audit><business decision=\"deny\" committed=\"true\"/></audit>",
    "positiveExpected": 1
  },
  "comparatorPolicy": {
    "scopeKeys": [
      "tenant",
      "operationAlias",
      "object"
    ],
    "inspect": "all matching business rows",
    "identicalRepeat": "deduplicate complete identical event record",
    "changedEventIdentityFields": "ambiguous",
    "resultPriority": [
      "explicit deny/true → review-required",
      "missing/incomplete evidence → unknown",
      "conflicting complete records → ambiguous",
      "only deny/false → expected-denial",
      "other complete observations → other-observed"
    ],
    "notActualIncidentVerdict": true
  },
  "multipleRows": {
    "lateContradiction": {
      "result": "review-required",
      "matchingRows": 2,
      "uniqueRows": 2,
      "duplicateRows": 0,
      "contradictions": 1,
      "incompleteRows": 0,
      "ambiguous": true
    },
    "identicalDuplicate": {
      "result": "expected-denial",
      "matchingRows": 2,
      "uniqueRows": 1,
      "duplicateRows": 1,
      "contradictions": 0,
      "incompleteRows": 0,
      "ambiguous": false
    },
    "differentCompleteOutcomes": {
      "result": "ambiguous",
      "matchingRows": 2,
      "uniqueRows": 2,
      "duplicateRows": 0,
      "contradictions": 0,
      "incompleteRows": 0,
      "ambiguous": true
    },
    "sameIdDifferentFields": {
      "result": "ambiguous",
      "matchingRows": 2,
      "uniqueRows": 2,
      "duplicateRows": 0,
      "contradictions": 0,
      "incompleteRows": 0,
      "ambiguous": true
    },
    "laterIncomplete": {
      "result": "unknown",
      "matchingRows": 2,
      "uniqueRows": 2,
      "duplicateRows": 0,
      "contradictions": 0,
      "incompleteRows": 1,
      "ambiguous": false
    }
  }
}

ledger: Fixed source-context fields, not live logs.
correlationKeys: Tenant/operation/object relationship, not a credential.
excludedSeed: Fake sensitive fields are not copied to output.
scope/recovery: Known scope and a new checkpoint; no production restoration.
selector: Denial/commit disagreement within one XML document; missing is unknown.

Synthetic event ledger and finite local comparator. No real log collector, identity verifier, SIEM, global clock or production recovery is executed.

Two reality checks

HTTP 200 proves the business action committed.

Status describes response semantics; action decisions and persistence evidence are separate.

Zero selected rows establish that no incident exists.

Missing fields, a collector or scope can produce the same zero; without adequate evidence the conclusion is unknown.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

For the same tenant/operation/object, the first business row is deny/false and a later row deny/true. What does the comparator return?

expected-denial; the first row overrides every later record.
review-required; the explicit contradiction takes priority.

Read the explained answer

review-required; the explicit contradiction takes priority. — lateContradiction contains a deny/true row. An expected first row does not erase the later contradiction; the result requires review, not a real incident verdict.

HTTP 200 and Atlas business deny/false appear in one trace. A Nova allow/true row shares the aliases. Can we conclude Atlas committed?

Selected lesson artifact fields; teaching example

ledger[0]: {"eventId":"http-demo","kind":"http","tenant":"Atlas","requestAlias":"req-demo","operationAlias":"op-demo","object":"tea","status":200,"producer":"app","sequence":1}
ledger[1]: {"eventId":"decision-demo","parentEventId":"http-demo","kind":"business","tenant":"Atlas","requestAlias":"req-demo","operationAlias":"op-demo","sessionCorrelationAlias":"session-group-demo","userAlias":"Duru","actor":"Duru","action":"rename-note","object":"tea","decision":"deny","reason":"owner-policy","committed":false,"producer":"app","sequence":2,"time":"10:00:02"}
ledger[3]: {"eventId":"nova-demo","kind":"business","tenant":"Nova","requestAlias":"req-demo","operationAlias":"op-demo","object":"tea","decision":"allow","committed":true,"producer":"app","sequence":3}
correlationKeys: ["tenant","operationAlias","object"]

No. Atlas has committed=false; Nova is a different scope.
Yes. A shared alias or 200 combines commit outcomes across tenants.

Read the explained answer

No. Atlas has committed=false; Nova is a different scope. — HTTP 200 is not a business commit. With tenant, operationAlias and object in the correlation key, Nova is not merged into Atlas’s decision.

Why do identical duplicates, changed fields under one ID and a later incomplete row differ? What does causal order say when the job wall clock appears earlier than its parent?

Read the explained answer

A completely identical event record is deduplicated. Changed fields under one event ID can be ambiguous; a missing required row preserves unknown. ParentEventId provides a causal relation but does not establish cross-producer wall-clock order. The review scope is limited to Atlas/tea, with other tenants/objects unknown. Recovery validation retains historical events and is not proof of production restoration.

□ I separated duplicate, conflicting and incomplete evidence.

□ I did not treat a causal parent relation as cross-producer clock order or wider incident scope.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

OWASP — Logging Cheat SheetEvent data sources · Event attributes · Data to exclude · Event collection · Verification · Operation · Protection · Which events to log
NIST SP 800-61 Rev. 3, April 2025RS.AN-03, printed p.28 / PDF p.36 · RS.AN-06 and RS.AN-07, printed p.29 / PDF p.37 · RS.AN-08, printed p.29 / PDF p.37 · RC.RP-02 through RC.RP-05, printed p.34 / PDF p.42

YOUR NOTES / THIS BROWSER

Audit evidence, detection and incident scope

1. Core · Mechanism

Expected denial

Event discrepancy

Missing record

Clock uncertain

HTTP records and business decisions

Baselines, missing evidence and incident bounds

2. Red · Trust & Impact

Alias scope

All matching rows

When correlation is mistaken for authority

Logs are also data requiring protection

3. Blue · Secure development & defense

Audit controls

Audit gap

Selector results and evidence sufficiency

Bounding incident and recovery decisions

Do 200, parent relation or equal aliases prove an incident?

Two reality checks

For the same tenant/operation/object, the first business row is deny/false and a later row deny/true. What does the comparator return?

HTTP 200 and Atlas business deny/false appear in one trace. A Nova allow/true row shares the aliases. Can we conclude Atlas committed?

Why do identical duplicates, changed fields under one ID and a later incomplete row differ? What does causal order say when the job wall clock appears earlier than its parent?

Sources and scope