Knowledge · Architecture

    Audit Attribution and Correlation IDs

    An audit trail that records what changed but not who caused it, or that cannot connect related writes, is a list of events rather than an explanation.

    What makes an audit trail actually useful?

    Three things: attribution, so every entry names the actor that caused it; completeness, so privileged and destructive operations cannot happen without an entry; and correlation, so the writes belonging to one logical operation share an identifier and can be read as a single story rather than scattered rows.

    Key takeaways

    • Attribution without correlation gives you events but not causes.
    • One logical operation should thread one correlation identifier through every child write.
    • Audit writes must not silently fail, and must not block the operation either.
    • Secrets and tokens are redacted before anything is stored.
    • An audit trail nobody can query is documentation, not a control.

    The question an audit trail has to answer

    Not 'what changed' — the record already shows that. The real question is 'why does this record look like this', and answering it requires knowing who acted, on whose authority, as part of which operation, and what else that same operation touched. A deletion is only explicable next to the escalation that preceded it.

    What a correlation identifier buys you

    • A single operation that touches six tables reads as one event, not six.
    • A failure halfway through is visible as a partial operation rather than an inconsistency.
    • Requests can be traced across function boundaries and back to the caller.
    • Automated activity can be reconstructed after the fact without guessing.

    Auditing must not become a failure mode

    There is a genuine tension: an audit write that fails should not roll back the business operation it was recording, but silently swallowing it leaves a hole. The resolution is to isolate the side effect so a logging failure cannot destroy a core write, and to treat missing audit coverage as a defect found by inspection rather than by incident.

    Where URBLD fits

    URBLD threads a correlation identifier across every child write in one logical operation and echoes it on function responses. Destructive and privileged mutations write an audit record carrying the resolved actor, actor type, authorizing person, entity type and identifier, and metadata; database triggers write a baseline entry for mutations on core records, and agent activity additionally records a per-step execution trace. Secrets and tokens are redacted before storage, and auxiliary logging is isolated so it cannot fail a core write.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Architecture

    How information should move through a business.

    Browse Architecture
    Share this page