AnalysisForge

The information may already be in the traffic. The difficult part can be constructing the analysis required to find it.

Packet captures preserve detailed evidence about network activity, but an analyst's question does not arrive in the form required by an analysis tool.

A conventional investigation may require several steps:

The analyst may therefore spend substantial effort translating:

what do I want to know?

into:

what executable analysis will investigate it?

The challenge is not necessarily missing data.

It is the distance between investigative intent and the technical mechanism required to interrogate the captured traffic.

AnalysisForge focuses on that distance.

AnalysisForge operates at two levels of research maturity: a durable research direction and a narrower question exercised by the MVP.

Broader Research Question

Can an analyst's investigative intent be translated into an appropriate executable analysis strategy and applied to captured network traffic without requiring the analyst to manually construct the underlying analysis?

This is the longer-term research direction.

It encompasses more than translating natural language into syntax for one network-analysis tool.

MVP Research Question

Can natural-language investigative requests be translated into appropriate tool invocations and filters that execute against captured network traffic and return useful analytical results?

This is the bounded question addressed by the current implementation.

The distinction matters because the working MVP demonstrates one viable analytical path, while the broader research direction considers a system capable of determining which analysis should be performed in the first place.

Separate what the analyst wants to know from how the investigation is executed.

This separation is the architectural center of AnalysisForge.

The analyst begins with investigative intent.

The system must interpret that intent, determine an executable analysis mechanism, construct the required invocation or filtering, apply the analysis to captured traffic, and return results for interpretation.

The significant abstraction is not natural-language syntax by itself.

It is the translation between:

investigative intent

and:

executable technical analysis.

That distinction allows the research to expand beyond a natural-language interface attached to a single utility.

A more capable architecture could eventually select, construct, or orchestrate different mechanisms according to the investigation being performed.

The working MVP establishes an end-to-end path from natural-language investigative intent to executable PCAP analysis.

The current implementation provides an operational path in which a natural-language investigative request can be translated into tool invocations and filters that execute against captured network traffic.

This is more than a conceptual architecture: the path is implemented sufficiently to exercise the bounded MVP research question.

But the implementation boundary is equally important.

The MVP does not mean that the broader AnalysisForge research architecture has already been implemented.

The current state and broader direction are different:

The MVP demonstrates a working route through the problem.

The research direction asks how many different routes may eventually be selected or constructed according to investigative need.

Investigative Intent → Executable Analysis

The central technical transformation is not language to text. It is investigative intent to an analysis that can actually run.

Consider an analyst asking a question such as:

What network activity is associated with X?

That request expresses investigative intent, but it does not specify the technical procedure required to answer it.

AnalysisForge must bridge several distinct layers:

Each layer has a different responsibility.

Investigative intent expresses the analyst's question in domain terms.

Interpretation determines what kind of analysis the question requires.

Analysis construction converts that interpretation into something executable.

Execution applies the constructed analysis to captured network traffic.

Analytical results return evidence that the analyst can interpret in the context of the investigation.

This separation is what makes AnalysisForge more interesting as R&D than a natural-language command wrapper.

The broader architectural question is whether the translation layer can eventually choose among different ways of performing analysis.

The longer-term problem is deciding what analysis to construct---not merely how to phrase a command.

The current MVP uses tool invocations and filters.

The broader research direction considers additional analytical mechanisms, potentially including:

• specialized analyzers;
• generated analysis code;
• models operating on packet or traffic representations;
• conventional network-analysis tools; and
• hybrid analytical workflows.

Conceptually:

These branches represent research directions, not a list of capabilities already present in the MVP.

The durable architectural idea is:

Choose the analytical mechanism because it fits the investigative problem---not because the system is required to use one particular technology.

That includes AI.

AI-assisted techniques may be useful for some parts of analysis construction or interpretation. Conventional deterministic analysis may be superior for others. A hybrid workflow may be appropriate where neither is sufficient alone.

The problem should determine the mechanism.

The MVP demonstrates that natural-language investigative intent can be transformed into executable network-analysis operations against captured traffic.

The implemented path provides evidence for the viability of:

That result supports several bounded conclusions.

Intent Can Drive Executable Analysis

The MVP establishes that a natural-language investigative request can participate in an end-to-end process that results in executable analysis rather than merely an explanatory response.

The distinction matters.

The output of the translation is not just a description of what an analyst might do. It can become an operation applied to captured traffic.

Tool Invocation and Filtering Provide a Viable Initial Mechanism

The MVP demonstrates one concrete mechanism for bridging investigative intent and network evidence: constructing appropriate tool invocations and filters.

That mechanism is the implemented starting point.

It should not be confused with the full range of analysis-construction mechanisms envisioned by the broader research direction.

The Analyst Remains Part of the Investigative Loop

AnalysisForge produces analytical results. The analyst determines their investigative significance.

A returned result does not automatically establish what happened, why it happened, whether activity is malicious, or what response should follow.

The system assists in constructing and executing analysis.

Human expertise remains responsible for interpreting evidence in investigative context.

One demonstrated query was estimated to represent approximately 30--40 hours of conventional junior-staff or consultant analysis.

During evaluation, a former FBI Special Agent in Cyber Response estimated that reproducing one demonstrated AnalysisForge query through conventional junior staff or consultant analysis could require approximately 30--40 hours of effort.

That observation is meaningful because it suggests that the intent-to-analysis approach may provide substantial analytical leverage for some investigations.

It is also deliberately bounded evidence.

The estimate represents one evaluator's assessment of one demonstrated query. It is not a general measure of AnalysisForge time savings across network investigations.

The MVP does not establish a universal productivity multiplier, average labor reduction, or guaranteed savings.

The observation should therefore be treated as evidence from an external evaluator about a specific demonstration---not as a generalized performance claim.

A working MVP establishes feasibility of the implemented path. It does not establish universal analytical capability.

The current work does not demonstrate that:

• every investigative question can be translated automatically;
• every constructed analysis is correct;
• every result is complete;
• network-analysis expertise is unnecessary;
• AI can replace the analyst;
• every envisioned analytical mechanism is implemented;
• the system already performs general analysis-strategy orchestration; or
• the evaluator's 30--40 hour estimate generalizes to other queries or investigations.

These distinctions protect the meaning of MVP maturity.

AnalysisForge has moved beyond a purely conceptual or architectural state: an end-to-end analytical path works.

But the implemented path is still narrower than the durable research question.

The next research step is to move from constructing one kind of executable analysis toward selecting and orchestrating the analysis appropriate to the investigator's question.

The durable question progresses from:

Can natural language produce an executable network-analysis operation?

toward:

Given an investigator's question, what analysis should be constructed and which capabilities should be orchestrated to execute it?

A broader analytical architecture could look like:

Potential future investigation includes:

• specialized network analyzers;
• generated analysis code;
• models operating on packet or traffic representations;
• conventional analysis tools;
• hybrid conventional/AI workflows;
• analysis-strategy selection;
• orchestration across analytical capabilities; and
• iterative refinement based on intermediate results.

The key research problem is not accumulating mechanisms.

It is determining how the system should choose among them.

The appropriate analytical mechanism should follow the investigator's question and the evidence required to answer it.

AnalysisForge is directly concerned with reducing the translation burden between a network investigator's question and the technical analysis required to explore captured traffic.

Potential application areas include:

• packet-capture investigation;
• incident-response analysis;
• network-security research;
• threat-hunting workflows;
• network troubleshooting;
• exploratory analysis of captured traffic; and
• analyst-assistance systems.

The current MVP should not be interpreted as a complete operational solution for every one of these environments.

They are contexts in which the underlying R&D direction may apply.

A broader transferable engineering concept also emerges:

Translate domain-expert intent into executable analytical strategies.

Many technical domains contain a similar gap between what an expert wants to investigate and the specialized technical work required to construct the analysis.

That idea may transfer beyond network traffic.

AnalysisForge itself, however, remains network-analysis R&D rather than a claim of a domain-general analytical platform.

The MVP demonstrates one working intent-to-analysis path. The next research challenge is broader strategy construction and orchestration.

Maturity:	MVP
Domain:	Captured network traffic / PCAP analysis
Current state:	Working MVP
Current implemented focus:	Natural-language investigative requests translated into executable tool invocations and filters
Current analytical target:	Captured network traffic
Evidence-bearing work:	End-to-end MVP executing constructed analysis against PCAP data
External evaluation evidence:	One evaluator estimated approximately 30--40 hours of conventional junior-staff or consultant effort for one demonstrated query
Explicit boundary:	That estimate is specific to one evaluator and one demonstrated query and is not a general time-savings claim
Human role:	Analyst interprets results and determines investigative significance
Research direction:	Broader analysis-strategy construction and orchestration across conventional, specialized, generated, AI-enabled, and hybrid analytical mechanisms
Next maturity question:	Can the working intent-to-analysis model expand into reliable strategy selection and orchestration across multiple analytical mechanisms while preserving appropriate analyst oversight?

Some difficult technical problems are not blocked by a lack of data.

They are blocked by the effort required to turn a domain expert's question into the technical analysis capable of interrogating that data.

AnalysisForge demonstrates an Applied Software R&D progression from that problem to a bounded working system:

The MVP is valuable not because it closes the research program.

It establishes enough of the core idea to make the next questions more concrete:

What analysis should be constructed?

Which capabilities should perform it?

How should they be orchestrated?

That progression---from difficult question, to working evidence, to a better-defined next investigation---is the purpose of Applied Software R&D.

Have a technical problem where the right analytical approach isn't obvious?

Bring Us a Difficult Problem