Glossary
The docs and the screens use a few precise words on purpose — append-only, hash chain, MIT-bound — because in a trust tool the exact meaning is what makes the proof hold. If a term on the Trust Report, in the Audit Log, or on a settings page ever looks like jargon, this page is the plain-language answer. Each entry says what the term means first, then the exact mechanism behind it.
The docs and the screens use a few precise words on purpose — append-only, hash chain, MIT-bound — because in a trust tool the exact meaning is what makes the proof hold. If a term on the Trust Report, in the Audit Log, or on a settings page ever looks like jargon, this page is the plain-language answer. Each entry says what the term means first, then the exact mechanism behind it.
Terms are roughly alphabetical so you can scan to the one you need. Where a term has a page of its own, there is a link to follow.
Append-only log
A record you can add to but never quietly change. The audit journal
(network.egress_log) accepts new rows but rejects every attempt to edit (write) or
delete (unlink) a row — including attempts made with elevated sudo rights. The single
exception is the retention vacuum, which can only trim old rows under
strict conditions. Append-only is also enforced at the database level where the module is
deployed, so it is not merely a rule in the screen. See The audit log.
Attribution
The answer to "which Odoo module made this call?". For every captured network operation the
module walks the live call stack to find the originating code, then maps it to an
ir.module.module record. So a row in the log does not just say "something connected
somewhere" — it names the addon, its author, and the call site responsible. Attribution is
what turns a list of destinations into proof about who is talking to whom. See
How it works.
Chain seq
The position of a row in the hash chain — a database-unique serial number
(chain_seq) that strictly increases. Because it is unique and sequential, a gap reveals a
missing row, and the signed head records the highest chain_seq that has been
sealed. It appears on the Forensic Record form under Tamper-evident chain and bounds an
export as chain_seq_min / chain_seq_max.
Channel
A family of network operations the module hooks, named by the library or protocol it covers —
for example requests, httpx, imap, smtp, pop3, raw ssl, and socket. Each channel
is one wrapped egress path. You can turn channels off individually with
Disabled channels in settings (for example socket,smtp); an
empty list means every channel is captured.
Egress
Traffic leaving your Odoo instance — an outbound network call. The whole module is built around making egress visible: every outbound operation is intercepted, attributed to the module that made it, and recorded as metadata so you can see where your instance is reaching out, without storing what it sent.
Egress component
An entry in the seeded catalogue (network.egress.component) of known destinations that the
module uses to decide whether a call is MIT-bound or third-party.
You can review it under Configuration → Egress Components. It is the lookup behind the
is_mit_bound classification on every destination.
Fingerprint (salted)
A one-way value that lets you tell two calls apart without keeping what they contained. Instead of storing a body, the module keeps a salted HMAC fingerprint — a keyed hash. Identical payloads produce the same fingerprint, but the fingerprint cannot be reversed back into the original content, and the per-database salt means it cannot be matched against a precomputed table. It is how the log stays useful for correlation while remaining body-free. See redaction.
Forensic body capture
The one feature that does store request and response bodies — kept deliberately separate,
gated, and off by default. Only a Network Forensic Officer can enable it, it is meant
for legal cases, and every read of a captured body is itself logged to the append-only
journal. Captured bodies live in their own model (network.egress_body) with a separate
officer-only permission. If you never turn it on, no body is ever stored. See
Security.
Hash chain
The technique that makes the log tamper-evident: each row carries the hash of the row before it, so the rows are linked in one unbroken chain. Change or remove any row and every later row's hash stops matching — the break is detectable, and Verify chain names the first row that does not add up. The chain is built from the row hash / prev hash and the chain seq. See Verify & export.
Ingress / inbound
Traffic arriving at your Odoo instance — an inbound HTTP request. The module captures it with a pure WSGI middleware injected into Odoo's HTTP layer, so inbound calls are recorded with the same metadata-only discipline as egress. In the log, the direction field tells inbound and outbound apart.
Masked headers
Request and response header names are kept, but their values are masked at the moment of
capture. So the log shows that an Authorization header was present, without ever recording
the token it carried. Masked headers appear on the Forensic Record form. With
strict redaction on, even more is masked.
MIT-bound
A destination classified as belonging to MIT — that is, the small license-validation
metadata traffic the commercial modules send to MIT. The Trust Report shows MIT-bound
destinations in their own panel, separately from third-party ones. The whole
point of the tool is that this list should be short and expected: license checks, and nothing
more. Classification comes from the egress component catalogue
(is_mit_bound).
Prev hash
See row hash / prev hash.
Redaction / strict redaction
Redaction here is structural, not a setting you have to trust: the captured event has no body field at all, so there is nowhere for your data to be stored in the first place. The log keeps only metadata — direction, destination, sizes, timing, masked headers, and a salted fingerprint.
Strict redaction is the optional setting that goes further: with it on, the module keeps only host, IP, port and sizes, and masks everything else at capture time. Turn it on in Configuration → Settings when you want the leanest possible record.
Retention vacuum
The one job allowed to remove rows from the otherwise append-only log — and
only old ones, never recent. It is governed by Audit retention (days) in settings: 0 means
keep everything, and the vacuum never deletes at or after the signed head, so
it can never erase a row the signed proof still vouches for. See
Configuration → Settings.
Rollup
A pre-aggregated summary table (network.egress.rollup) refreshed by a scheduled job. It lets
the Trust Report and the Traffic Summary views show totals and trends quickly, without
re-reading every individual row in the journal. The numbers come from the rollup; the proof comes
from the chain.
Row hash / prev hash
The two fields that link one log row to the next. Each row's row hash (row_hash) is a
SHA-256 hash computed over that row's content together with the previous row's hash. Each row also
stores that previous value as its prev hash (prev_hash). Together they form the
hash chain: tamper with one row and its row_hash no longer matches what the next
row recorded as prev_hash. Both appear on the Forensic Record form under Tamper-evident
chain.
Self-egress
Network calls made by the audit module itself — of which there should be exactly zero. The
module is designed to make no outbound calls of its own, so it can never be the thing leaking your
data. The Trust Report shows a Self-egress trust chip, and if it ever attributes a call to
mit_network_audit, the verdict raises an alarm. See Verdicts.
Signed head
A daily HMAC signature of the current top of the hash chain, stored as a
configuration parameter (mit_network_audit.signed_head) in the form chain_seq:row_hash:hmac.
Because the signed head lives outside the log rows and is signed with a per-database secret, it
outlives any deleted rows — so even truncating the log (cutting off the end) is detectable,
not just editing a row in place. It travels inside the signed proof
export.
Third-party
A destination that is not MIT — your own providers and services: your Gmail/IMAP server, your own OpenAI or other LLM key, your Microsoft 365 tenant, and so on. The Trust Report lists third-party destinations in their own panel. Seeing your other modules talk to your providers here, and to MIT only on the MIT-bound side, is exactly the result the tool is meant to prove.