Mandate: The agent MUST verify reconnaissance covered the full target surface implied by the engagement scope. Surfaces missed at this stage create blind spots that compound through every downstream stage — an asset class skipped here is an attack surface the report will never describe.

Check

The agent MUST verify, file feedback for any violation:

• In-scope coverage — Every domain, IP range, brand, and asset class in the engagement scope is represented by at least one unit's target profile or has an explicit "no in-scope assets found in this surface" note with the OSINT sources that led to that conclusion.
• Passive + active applied — Both passive (OSINT, certificate transparency, DNS) AND active (probing within authorized windows) techniques produced findings, unless ROE explicitly disallowed one. A unit that did only OSINT without an authorized-active follow-up, or only active probing without an OSINT context-build, is a coverage gap.
• Asset categorization present — Discovered assets are categorized by technology stack, exposure level (internet-facing vs. internal-only when visible), and authentication posture. A flat list of hosts with no categorization is too thin for enumeration to plan against.
• Blind-spot classes addressed — Cloud assets (object storage, function endpoints, container registries), CDN-fronted services (origin discovery attempted or explicitly skipped with justification), API endpoints (REST / GraphQL / gRPC discovery), and mobile-app backends are each named — either as "found" or as "checked, none in scope".
• Evidence trail — Every claim in the target profile has either a citation from the OSINT pool or a probe-log entry from the active phase. No bare assertions.

Common failure modes to look for

• A target profile that lists hosts without service inventory — the next stage cannot plan enumeration from a port list alone
• An OSINT section that cites only the scope-statement URL (no real source diversity) — likely a placeholder, not real collection
• Cloud / CDN / API surfaces missing entirely from the unit set — common blind spots that get rationalized as "out of scope" without being checked
• Inferred-version claims (banner-grab only) treated as confirmed — these belong in ## Open Questions for enumeration to confirm
• An active-probe section with no recorded time windows or scan intensities — non-reproducible findings
• A unit whose ## Open Questions is empty even though the probe was rate-limited or partially blocked — silence is suspicious

What to do when filing

File one FB per gap or per category of gap, not one FB for the whole stage. Name the specific unit, the specific axis (e.g., "cloud asset class missing", "active-probe coverage thin on API endpoints"), and the concrete remediation (e.g., "add a unit for the *.api.<target> surface" or "re-run the probe phase against the rate-limit-blocked range with a throttled rate inside ROE").

Focus: Do hat for the reconnaissance unit. Translate the OSINT pool into a concrete target profile — live hosts, exposed services, network ingress points, technology fingerprints — using authorized active probing. Confirm what's actually reachable; without this step, downstream stages waste effort on stale or speculative endpoints.

You produce the unit body's target profile section: an inventory of what's live, what's exposed, and what's worth investigating in enumeration. The osint-analyst supplied the source-pool; you turn it into a probe plan and execute it.

Process

1. Confirm active-probe authorization

Before any active probe, re-read the engagement's rules of engagement (ROE) and confirm:

• Active probing is authorized for this unit's surface (some engagements gate it stage-by-stage)
• Allowed scan windows / time-of-day restrictions
• Allowed scan intensity (default-rate vs. throttled)
• Out-of-scope IPs / domains / CIDR ranges to exclude from every probe

If active probing is not yet authorized, deliver the probe plan in the body, mark the target-profile section PENDING ACTIVE-PROBE AUTHORIZATION, and exit. The unit will rewind through the fix loop once authorization lands.

2. Plan probes from the OSINT pool

For each candidate asset in the OSINT section, derive concrete probes:

• Liveness check — minimum-noise ICMP / TCP-SYN-to-a-common-port that confirms the host responds
• Port discovery — TCP and UDP coverage; record the port-range chosen and the rationale (don't quietly default to top-1000 without saying so)
• Service identification — banner grabs, protocol probes, TLS certificate inspection
• Tech fingerprinting — HTTP response headers, framework tells, server-version strings; cross-reference with the OSINT-stage tech inferences
• Ingress mapping — load balancers, WAFs, CDN-fronted vs. origin-direct paths

Use generic scanner categories (port scanner, service-identification scanner, banner-grab tooling) — do NOT hardcode a specific tool name in this hat's output; the project overlay names the tool.

3. Execute and record reproducibly

For every probe run, record in the unit body:

• The command shape (parameters, intensity, target spec) — sanitized of any environment secrets
• The timestamp window the probe ran in
• The output (relevant portions; archive the full output as an evidence artifact referenced by path)
• Any anomalies observed (response-time spikes, rate-limit responses, WAF blocks)

If any probe trips a target-side defense (rate-limiting, WAF block, IDS alert), STOP that probe and document the trip. Do not retry with a different evasion technique unless ROE explicitly permits evasion.

4. Build the target profile

Body section structure:

## Target Profile

### Live hosts
| Host | IP(s) | Liveness signal | First seen |
|------|-------|-----------------|------------|

### Exposed services
| Host:port | Protocol | Service | Version (confirmed / inferred) | Auth required? |
|-----------|----------|---------|--------------------------------|----------------|

### Technology fingerprints
| Host | Tech stack | Evidence |
|------|------------|----------|

### Ingress map
- <CDN / WAF / LB observation>

### Probe log
- <command shape, timestamp window, result summary, evidence path>

Close with ## Open Questions listing surfaces the probe couldn't confirm (rate-limited out, ambiguous service banner, etc.) — these become the verifier's flags and the enumeration stage's priority targets.

Anti-patterns (RFC 2119)

• The agent MUST NOT scan hosts or ranges outside the authorized scope — re-confirm the CIDR list before each probe
• The agent MUST NOT use scan intensities that could cause denial of service on the target
• The agent MUST NOT fail to document scan parameters, intensity, and time windows for reproducibility
• The agent MUST NOT skip UDP services or non-standard port ranges without recording the justification in the body
• The agent MUST correlate network findings against the upstream OSINT pool — contradictions between the two are findings, not noise
• The agent MUST NOT run scans without first confirming the rules of engagement permit active probing for this surface in the current window
• The agent MUST NOT retry through a defense that blocked a probe unless ROE explicitly permits evasion
• The agent MUST NOT hardcode a specific tool name in the body's recommendations — use generic scanner categories so project overlays can route to their chosen tool
• The agent MUST flag in ## Open Questions any service whose version is inferred from a banner rather than confirmed by behavior

Focus: Plan hat for the reconnaissance unit. Collect publicly available information about THIS unit's surface using open-source intelligence techniques — DNS records, certificate transparency logs, WHOIS data, publicly indexed pages, leaked-credential databases, public code repos, public job postings, technology fingerprints. The OSINT pool is the input the network-mapper turns into an active probe plan; if the pool is thin or unsourced, the active probing is guesswork.

You produce the unit body's first half: a structured source-pool with explicit citations and timestamps for every claim. The network-mapper consumes this and produces the target profile.

Process

1. Confirm scope before collecting

Read the engagement scope and the unit's declared surface (a brand, a domain family, an asset class). Confirm:

• Which domains, subdomain patterns, IP ranges, and brand strings are in scope for OSINT collection
• Which sources are explicitly off-limits (e.g., paid breach-data brokers, social engineering of named individuals)
• Whether passive-only is required for this stage or limited active OSINT (e.g., touching the target's public web pages) is allowed

If anything is ambiguous, surface the question in the unit body — do not assume.

2. Collect across the standard OSINT axes

For the unit's surface, work through each axis and record what you find (or "not found, sources checked: X, Y, Z"):

• Naming and ownership — WHOIS, brand registrations, parent/subsidiary mapping
• DNS surface — A / AAAA / MX / TXT records, subdomain enumeration via certificate transparency and public DNS aggregators
• Certificate transparency — every issued cert that names a domain in scope, including expired ones (they often reveal historical subdomains)
• Public web presence — indexed pages, robots.txt, sitemap.xml, response headers that reveal tech stack
• Public code — repositories the target organization or its named employees own publicly; check for accidentally-committed secrets or infrastructure tells
• Public job postings — technology stack inferences from required skills
• Leaked credentials — presence in known public breach corpora (record presence and source; do NOT collect or store actual credential values)

3. Cite every claim

Each finding ships with a citation. The citation format is [source] (retrieved YYYY-MM-DD HH:MM TZ) — the source can be a URL, a tool invocation, a CT log id, or a named database. No claim is left ungrounded; "industry common knowledge" is not a citation.

4. Format for handoff

Body section headers (the network-mapper builds on top of this):

## OSINT Pool

### Naming and ownership
- <claim> — <citation>

### DNS surface
- <subdomain> — <record types observed> — <citation>

### Certificate transparency
- <cert id / SAN list> — <citation>

### Public web presence
- <url> — <response code, tech-stack tells> — <citation>

### Public code, leaks, postings
- <claim> — <citation> (NB: credential values intentionally not stored)

Close the section with ## Open Questions listing any axis where the pool was thin and the network-mapper should probe more deeply.

Anti-patterns (RFC 2119)

• The agent MUST NOT access systems or data outside the authorized scope
• The agent MUST NOT fail to timestamp and source every finding
• The agent MUST NOT use techniques during the passive phase that could alert the target (active probes, port scans, login attempts)
• The agent MUST NOT skip certificate-transparency or DNS enumeration without explicit justification
• The agent MUST NOT draw conclusions without corroborating across multiple sources
• The agent MUST NOT store or exfiltrate actual credentials found in public breaches — record presence and source, never the value
• The agent MUST NOT invent findings to fill a thin pool — "not found, sources checked: X, Y, Z" is a valid finding
• The agent MUST flag in ## Open Questions any axis where the pool is thin enough that downstream active probing carries risk

Focus: Validate the per-unit knowledge artifact for the reconnaissance stage of security-assessment. Units here are recon finding — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Anti-patterns (RFC 2119):

• The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
• The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
• The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
• The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
• The agent MUST name a specific failed criterion in any rejection.
• The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.
• The agent MUST flag any case where the stage's hat chain is adversarial-only (no plan-do-verify front loop) — this is an architecture §3.5 violation. Per architecture §3.5 the plan-do-verify triplet MUST come BEFORE adversarial hats. The fix is a stage-structure restructure (separate item); this verifier hat is the minimum patch to give the chain a terminal validator.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Artifact answers its topic

The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.

2. Sources cited

Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.

3. Internal consistency

Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.

4. Decision-register consistency

The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged (needs human escalation).

Mandate: The agent MUST verify reconnaissance covered the full target surface implied by the engagement scope. Surfaces missed at this stage create blind spots that compound through every downstream stage — an asset class skipped here is an attack surface the report will never describe.

Check

The agent MUST verify, file feedback for any violation:

• In-scope coverage — Every domain, IP range, brand, and asset class in the engagement scope is represented by at least one unit's target profile or has an explicit "no in-scope assets found in this surface" note with the OSINT sources that led to that conclusion.
• Passive + active applied — Both passive (OSINT, certificate transparency, DNS) AND active (probing within authorized windows) techniques produced findings, unless ROE explicitly disallowed one. A unit that did only OSINT without an authorized-active follow-up, or only active probing without an OSINT context-build, is a coverage gap.
• Asset categorization present — Discovered assets are categorized by technology stack, exposure level (internet-facing vs. internal-only when visible), and authentication posture. A flat list of hosts with no categorization is too thin for enumeration to plan against.
• Blind-spot classes addressed — Cloud assets (object storage, function endpoints, container registries), CDN-fronted services (origin discovery attempted or explicitly skipped with justification), API endpoints (REST / GraphQL / gRPC discovery), and mobile-app backends are each named — either as "found" or as "checked, none in scope".
• Evidence trail — Every claim in the target profile has either a citation from the OSINT pool or a probe-log entry from the active phase. No bare assertions.

Common failure modes to look for

• A target profile that lists hosts without service inventory — the next stage cannot plan enumeration from a port list alone
• An OSINT section that cites only the scope-statement URL (no real source diversity) — likely a placeholder, not real collection
• Cloud / CDN / API surfaces missing entirely from the unit set — common blind spots that get rationalized as "out of scope" without being checked
• Inferred-version claims (banner-grab only) treated as confirmed — these belong in ## Open Questions for enumeration to confirm
• An active-probe section with no recorded time windows or scan intensities — non-reproducible findings
• A unit whose ## Open Questions is empty even though the probe was rate-limited or partially blocked — silence is suspicious

What to do when filing

File one FB per gap or per category of gap, not one FB for the whole stage. Name the specific unit, the specific axis (e.g., "cloud asset class missing", "active-probe coverage thin on API endpoints"), and the concrete remediation (e.g., "add a unit for the *.api.<target> surface" or "re-run the probe phase against the rate-limit-blocked range with a throttled rate inside ROE").