Know what's there. Know what's open. Know what moved.

What this server declares

which vhosts, docroots, handlers and route mappings does this config actually resolve to?

Blastline reads the nginx and Apache configuration the way the webserver does — following nginx include directives rather than guessing — and builds the inventory of what is actually declared: server names, listen directives, document roots, aliases, FastCGI and proxy targets, try_files, deny_all, internal, directory listing, and the handler each route maps to. Every record carries its own provenance, so a docroot that was inherited is never presented as one that was declared.

This axis has no headline number, and that is the honest position: the inventory ships to us as counts per category, never as your raw routes. What it does publish is the shape of its own blind spots.

route_coverage: partial means an include was seen and not followed — the config continues somewhere this pass did not go. directory_listing: unknown is a separate state from disabled, and the two are never merged.

What the app's own OS user can reach

can principal P read, write or execute path X — along the whole path, not just the leaf?

This is the arithmetic the kernel runs, run deliberately. For each path and each principal Blastline resolves the POSIX mode bits, the principal's supplementary groups, and any POSIX ACL — including the mask:: entry, which silently narrows every named user and group entry and is the single most common source of a wrong answer in tools that skip it.

Traversal is resolved along the whole path rather than at the leaf: for a principal with no other route in, a file at 0644 inside a directory at 0700 it does not own is not reachable, and saying otherwise is a false positive. Results are reported per principal, not per endpoint — every endpoint running as the same user shares the same reach, so reporting it per endpoint would multiply one fact into a hundred.

117 queries on one live host — 17 reachable, 100 closed, 0 undetermined on this run, every one at high confidence. Among the reachable: .git/config, wp-config.php, .env. 0 undetermined is a result on this host; on one with an exotic filesystem or an unresolvable identity, it will abstain.

What moved since the last pass

did anything appear, vanish, come back, or change how it would be handled?

Blastline does not scan your disk for changes. It watches only the slots the reach measurement already says something could be written into — a narrow, derived surface rather than a filesystem crawl — and compares it between hourly passes. On the measured host that meant 8 slots watched of 50 evaluated, the other 42 excluded because nothing could be placed there. Three consecutive runs produced zero noise.

It reports appeared, disappeared, modified, and — the one worth knowing about — reappeared, a file that came back after being removed. It also reports interpreter drift: became_executable and no_longer_executable, when the webserver's decision to run rather than serve a location changes underneath you.

8 watched, 42 excluded — from a separate 50-slot run to the one in axis IV; the two are never added together. Recursive coverage inside the watched roots measured 1,926 of 1,926 files. Detection is ctime_ns equality on stat metadata: the agent never opens the file.

Where code could be placed

could this slot carry executable code — W write, R reach, I interpret?

The sharpest case of axis II, and the one where abstention does the most work. Three legs have to hold at once: can this user write here, can anything outside reach the path, and would what lands there be interpreted as code. They combine under three-valued Kleene logic, where unknown ∧ allow is unknown and never allow. Nothing in the engine rounds an unresolved leg up to a conclusion, because a conjunction with a missing term is not a weaker claim — it is no claim.

The R leg is not signed in this release. Whether something outside can reach a given path is a question this version has no evidence source for, on any host, so it is reported as unknown rather than assumed in either direction — and that single missing leg is why the verdict below is what it is.

15 slots evaluated on one host. By rung: no_path 3, insufficient_evidence 4, placement_path_exists 6, execution_likely 2. The sealed verdicts were {unknown/low: 12, deny/high: 3} — not one allow/high, because the external-reachability leg was never observed.

1. 6 execution_confirmed Something was seen running. no evidence source in this release
2. 5 execution_likely Placed code would be handled as code. Reached by 2 slots — and still not a verdict.
3. 4 externally_reachable Something outside can reach the path. no evidence source in this release
4. 3 suspicious_change The watched surface moved. no evidence source in this release
5. 2 placement_path_exists The user can write into the slot. Reached by 6 slots.
6. 1 insufficient_evidence Asked, not settled. Reached by 4 slots.
7. 0 no_path No placement path for this principal. Settled for 3 slots.

The rungs this engine can produce are a set, not a prefix. Three of the seven are struck through above because no version of this release can compute them, on any host — each needs an evidence source the agent does not have. A ladder that filled from the bottom would paint them as climbed. We would rather show you the holes.