Every finding in a Wolfix report carries exactly one department badge, and which badge it gets is not a judgment call. Wolfix routes findings through a fixed set of rules so the same gap always lands under the same department on every scan. This reference explains the three things that determine where a finding ends up: where the signal came from, how regulatory mapping layers requirements on top, and how each finding is labelled by source.
Step one: signals are collected by source
A scan runs six steps in parallel — code scan, static and rendered URL scans, DNS lookups, provider checks, and regulatory mapping — and a seventh step that generates the report once every signal is in. Each raw signal knows where it came from, and that origin is the first input to routing.
From code
Read from the connected repository — stack, API routes, data types, third-party SDKs, and any hardcoded secrets. This is the only source that feeds security findings, which is why security stays unscanned on a URL-only scan.
From the live app
Observed from the deployed URL, either statically (fetch and parse of legal pages, OG tags, robots.txt) or rendered (a headless crawl that sees cookie banners and JS-loaded scripts). These feed legal, technology, brand, and growth coverage.
From DNS
Read from DNS lookups — SPF, DKIM, DMARC, and MX records. Email deliverability and domain configuration findings route here, owned by the technology department.
From registries
Verified against external registries — a state or Companies House filing, the DMCA designated-agent directory, or trademark offices. These confirm or refute whether something the project claims actually exists on record.
Step two: regulatory mapping layers requirements on top
Detection tells Wolfix what exists. Regulatory mapping tells Wolfix what should exist given your profile. An internal rules engine — keyed on geography, audience, platform, and business model — infers the requirements that apply to you and compares them against what was detected. When a required artifact is absent, the resulting finding is owned by the department that owns that requirement.
For example, if the scan detects EU-facing traffic and a payment processor but
no cookie policy, regulatory mapping fires a legal finding even though nothing
was "broken" in the code. These inferred findings are labelled from regulatory mapping so you can tell them apart from things Wolfix observed
directly.
Routing is a fixed mapping, not a guess
The mapping from signal to department is deterministic: DNS findings go to Technology, exposed secrets to Security, privacy and consent gaps to Legal, identity assets to Brand, discoverability to Growth, and business-scaffolding gaps to Operations. Cross-cutting findings that span departments default to Operations.
Step three: every finding is labelled by source
Once routed, each finding shows a source label so you know how Wolfix knows. The label is your confidence signal: a finding observed directly carries more certainty than one inferred from your profile.
| Source label | What it means |
| --- | --- |
| from code | Detected in the connected repository. |
| from live app (static) | Detected by fetching and parsing the deployed URL. |
| from live app (rendered) | Detected via a headless browser crawl of the rendered page. |
| from DNS | Detected via a DNS record lookup. |
| from regulatory mapping | Inferred from your detected profile — no direct detection. |
| from registry: <name> | Verified against an external registry, e.g. Companies House or the DMCA directory. |
A directly observed finding (from code, from live app, from DNS) is
something Wolfix saw. An inferred finding (from regulatory mapping) is
something Wolfix expects to apply but could not confirm one way or the other —
worth reviewing in context before you act on it.
Read the label before the fix
When two findings look similar, the source label disambiguates them. A
missing privacy policy labelled from live app (static) means Wolfix
looked and found none published; the same gap from regulatory mapping
means your profile requires one and Wolfix is inferring you need it. Both
route to Legal, but the first is a confirmed absence.
Why a finding might route somewhere you didn't expect
Because routing follows the owning department rather than where you noticed the symptom, a finding occasionally lands under a department you wouldn't have guessed. Email deliverability is a technology finding even though it feels like marketing; a missing DMCA section is legal even though it was triggered by a file-upload feature in your code. The badge always reflects who owns the fix, not where the trigger lived.