Processing runtime
PacketSafari’s ingest runtime is staged, generation-aware, and adaptive. Instead of recomputing every expensive artifact during the first import, it persists canonical derived outputs and reuses them whenever possible.
What the runtime is doing
At a high level, the runtime separates:
- foundational ingest work such as metadata, duplicates, connections, and packet stats
- derived analyzer work such as protocol post-index, security, network context, and infrastructure
- optional heavy artifacts such as file-object inventory or deeper follow-up analysis
This lets PacketSafari open the capture earlier and spend heavy compute only where it adds value.
Persisted artifacts
Derived outputs are written into canonical persisted artifact slots. That matters because:
- analyzer pages can reuse them instead of recomputing them
- AI and context builders can read the same canonical artifact identity
- later reads can be served from cache-backed persisted data instead of starting new heavy runs
Examples of persisted artifacts include:
- packet stats summaries
- protocol hierarchy and protocol statistics
- security summaries
- network context
- infrastructure summary
- file-object inventory
Coverage levels
Heavy derived units can expose different coverage levels:
- preview: a fast, intentionally reduced first-pass result
- sampled: a bounded but still useful result
- full: authoritative persisted coverage
PacketSafari surfaces these states so users and operators can tell whether a result is already final or still eligible for upgrade.
Adaptive materialization
PacketSafari chooses different materialization strategies depending on capture size and cost:
- small captures can run more work eagerly
- medium captures may keep some deeper analysis bounded
- large captures can defer expensive optional work and materialize it only when needed
The runtime can then:
- reuse persisted results immediately
- materialize inline when the work is cheap enough
- queue a background job when the work is too expensive for the request path
What this means in practice
File-object inventory
Export-object and related file inventory can be expensive. PacketSafari can now:
- serve persisted file inventory from cache-backed artifacts
- defer large-capture builds until a user or tool actually asks for them
- queue or reuse a heavy request instead of spawning duplicate work
Infrastructure summary
Infrastructure analysis can begin with a bounded first pass and later deepen:
- small captures can often finish enough infrastructure eagerly
- larger captures can expose usable first-pass context while deeper work remains optional
- reruns and follow-up work write back into the same canonical infrastructure artifact family
Heavy protocol post-index families
Some processor families are expensive enough to be deferred on larger captures. PacketSafari can expose those as queued follow-up or on-demand work rather than forcing them into the initial hot path.
Operator visibility
Admins and advanced operators can inspect the runtime in several places:
- Ingestion performance for stage timing and follow-up cost
- Upload insights for live per-capture progress
- Post-indexers / derived graph for registry units, dependency edges, and adaptive policy
- Upload diagnostics for queued follow-up and unit-level status on a specific capture
Why this matters
Without adaptive runtime behavior, large captures pay the full cost of every heavy path before the analyzer is useful. PacketSafari’s runtime avoids that by combining:
- readiness milestones
- canonical persisted artifacts
- adaptive eager vs lazy execution
- explicit preview / sampled / full coverage reporting
That gives better first-open UX while keeping deeper analysis transparent and auditable.
See also: