Opening a citation reveals only the exact referenced flow, preserving evidence traceability.
Architecture Spec separating browser decoding, deterministic evidence, contextual orientation and AI inference.
GPT-5.6 assessment separating observed evidence, inference, uncertainty and next investigative steps.
Professional incident report built from reviewed deterministic findings and explicitly included AI assistance.
AI-assisted assessments enter the report only after an explicit analyst inclusion decision.
Deterministic signal linked to exact flow and event evidence before any AI investigation is requested.
Command Center showing deterministic events, flows, protocol activity and investigation status from the guided sample.
7 Bounded PCAP, PCAPNG and network-export intake, with raw capture decoding kept in the browser.
Building PacketSage with Codex in VS Code during Stage 4A; the final production release later passed 333 tests.

PacketSage

An evidence-grounded network investigation workspace that helps analysts use AI without allowing inference to masquerade as observed fact.

The story started with less than 48 hours left

I discovered OpenAI Build Week with less than two days remaining before the submission deadline.

PacketSage was not a brand-new idea. I had already been building it with Codex as a network-forensics workspace with evidence import, flow analysis, protocol views, suspicious-signal review, timelines, reports and an earlier Gemini-powered analysis feature.

The easiest path would have been to connect GPT-5.6, polish the interface and submit what already existed.

Instead, I asked Codex to audit the repository as if it were reviewing a real investigation tool.

The result was uncomfortable, but useful.

The earlier version looked convincing, yet several parts were not defensible enough for a cybersecurity product:

flow identifiers were not reproducible,
some parsers invented fallback values,
raw PCAP support was only a placeholder,
demo-oriented findings could leak into real uploads,
AI failures could return canned analysis,
evidence relationships were sometimes inferred heuristically,
privacy descriptions did not fully match the processing path,
report controls implied behaviour that was not actually implemented,
and there was no automated test suite.

At that point, the challenge changed.

This was no longer about adding AI to PacketSage.

It became a race to rebuild the product around a much harder question:

How can AI assist with network evidence without being allowed to rewrite, exaggerate or impersonate that evidence?

Why I care about this problem

My interest in cybersecurity began with networking.

The more I learned about how systems communicate, the more interested I became in what happens when those systems are attacked: how suspicious behavior is identified, how an incident is reconstructed and how an analyst explains what actually happened.

That interest grew through my studies in Information System Sciences, especially courses in Computer Security and Computer Forensics, and through building products where authentication, user data, payments and third-party integrations introduced real security questions.

Shortly before Build Week, I was also admitted to pursue an MSc in Cybersecurity at Academic City.

PacketSage therefore became more than a hackathon submission. It became a practical way to prepare for the field I am entering.

Traditional packet-analysis tools are powerful, but they can overwhelm learners and junior analysts with thousands of records, protocols and conversations.

AI solves part of that problem by making technical evidence easier to understand, but it introduces another risk: a model can produce an explanation that sounds certain even when the evidence is incomplete.

I wanted PacketSage to sit between those two extremes.

It should preserve the precision of packet analysis while making an investigation easier to follow, explain and report.

What PacketSage does

PacketSage accepts authorized network and security evidence and converts it into a structured investigation workspace.

It supports:

PCAP
PCAPNG
Wireshark CSV
Suricata EVE JSON
Zeek logs
TShark JSON
strict structured-text records

For native packet captures, PacketSage performs bounded browser-side decoding for practical:

Ethernet
IPv4
IPv6
TCP
UDP
ICMP
basic DNS metadata

The workspace then presents:

normalized network events,
grouped communication flows,
DNS, HTTP and TLS records,
deterministic suspicious signals,
an incident timeline,
exact relationships between evidence records,
evidence-grounded AI assessments,
and a professional investigation report.

Raw PCAP and PCAPNG bytes are not sent to either AI model.

The core principle: evidence before explanation

PacketSage separates four different layers:

Layer	Meaning
Observed evidence	Fields supplied by or decoded from the imported evidence
Deterministic derivation	Stable IDs, flows, protocol records, signals and exact relationships
Contextual orientation	Optional broad Capture Overview
AI inference	A bounded assessment of one selected signal

The governing principle is:

Observed evidence, deterministic derivation, external context and AI inference must remain visibly separate.

Every important record receives a deterministic identity, including:

events,
flows,
DNS records,
HTTP records,
TLS records,
suspicious signals,
and the imported evidence itself.

Repeated visible records remain individually distinguishable through deterministic occurrence indexing.

This means the same evidence can be parsed again without producing completely different references.

It also means PacketSage can enforce a strict rule:

If the evidence referenced by a finding cannot be located, PacketSage shows no evidence. It does not substitute another flow, guess a relationship or invent a replacement.

What I changed during Build Week

1. Rebuilt the evidence foundation

The first priority was removing anything that could make PacketSage appear more certain than the evidence allowed.

I replaced unstable and random identifiers with deterministic IDs across events, flows, protocol records, signals and evidence imports.

I removed:

demo-signal leakage into user evidence,
fabricated PCAP placeholder findings,
invented parser fallbacks,
canned AI failure responses,
heuristic evidence substitution,
and unsupported compromise language.

If parsing or AI analysis fails, PacketSage now fails honestly.

2. Added bounded native PCAP and PCAPNG decoding

The original application claimed support for packet captures, but the implementation did not truly decode them.

During Build Week, I added bounded browser-side metadata decoding for PCAP and PCAPNG files.

The privacy boundary is intentional:

Processing step	Location
Raw capture selection	Browser
PCAP/PCAPNG decoding	Browser
Normalized metadata generation	Browser
Selected-signal AI request	Server
Raw capture sent to OpenAI	No
Raw packet payload sent to OpenAI	No

PacketSage does not claim full packet dissection, decryption, TCP stream reassembly or payload reconstruction.

Its native decoder is deliberately bounded and metadata-focused.

3. Built an evidence-grounded GPT-5.6 investigation path

The most important Build Week addition was the new Evidence-grounded Investigation workflow.

The analyst first selects a deterministic signal.

PacketSage then constructs a bounded evidence packet containing only:

the selected signal,
exact related flows,
exact related events,
relevant protocol records,
evidence identities,
and explicit port provenance.

The verified runtime model is gpt-5.6-sol.

The model does not receive:

the raw capture,
packet payloads,
packet information strings,
unrelated flows,
or the full investigation workspace.

Its response must follow a strict structure:

Assessment summary
Observed evidence
Analyst inference
Uncertainty / missing evidence
Recommended next investigative steps

Returned citations are checked against the evidence IDs that were actually supplied to the model.

Unsupported citations are removed. PacketSage does not replace them with guessed evidence.

4. Kept Gemini as a separate contextual layer

The earlier PacketSage experience used Gemini for broad capture analysis.

Rather than remove that capability, I repositioned it as an optional Capture Overview.

The Capture Overview provides orientation across the loaded capture, but it remains:

separately bounded,
citation-free,
contextual rather than evidential,
unable to create or modify deterministic findings,
and excluded from reports by default.

This avoids presenting two models as if they were voting on the truth.

GPT-5.6 handles the selected-signal investigation.

Gemini provides optional whole-capture context.

They serve different purposes and do not share assessment state.

5. Made report inclusion an analyst decision

AI output never enters the report automatically.

After reviewing the assessment and opening its exact citations, the analyst must explicitly choose:

Include AI-assisted assessment in report

Deterministic findings, GPT assessments and Capture Overview notes each have separate review and inclusion controls.

One shared report model then powers:

the on-screen report,
Preview,
Markdown output,
and Print/PDF export.

The report retains evidence identity, timestamps, exact references, model provenance, labelled inference and known limitations.

6. Added explicit port provenance

One of the most subtle challenges came from transport ports.

An omitted source port had previously been represented numerically as zero. But zero can also be a real observed value from a transport header.

Treating both states as identical would misrepresent evidence.

PacketSage now distinguishes:

observed
unknown
not-applicable

For example:

an observed port 443 is displayed as 10.0.0.15:443,
an observed literal zero remains 10.0.0.15:0,
an omitted port becomes 10.0.0.15:unknown,
and portless protocols receive no fabricated suffix.

This provenance follows the evidence through deterministic identities, the interface, GPT evidence packets and reports.

The challenge of building under the deadline

The biggest challenge was time.

I found the hackathon late, and the initial audit showed that the strongest submission would require much more than a model integration.

I also exhausted my Codex usage limit during the process (Eventually found out I had some codex resets I hadn't used).

That forced me to work differently.

Instead of attempting every possible feature, I narrowed the project to one complete and defensible path:

Load evidence → review a deterministic signal → run a bounded investigation → inspect exact citations → explicitly include the assessment → generate a report.

While waiting for access to reset, I used the time to:

review the repository manually,
define trust boundaries,
document the current and future architecture,
break the work into smaller verifiable stages,
and decide which features should not be built before the deadline.

That constraint improved the project.

It prevented me from adding a generic chat interface, multi-agent orchestration, automatic findings, model consensus or other impressive-sounding features that would have weakened the evidence model.

How I used Codex

Codex became an engineering and review partner throughout Build Week.

I used it for:

repository and architecture analysis,
implementation planning,
deterministic identity work,
parser and decoder corrections,
GPT-5.6 request architecture,
citation validation,
request cancellation and stale-response isolation,
regression testing,
accessibility and responsive checks,
adversarial reviews,
production verification,
and documentation reconciliation.

Some of the most important improvements came from asking Codex not just to implement features, but to challenge them.

That process exposed issues such as:

fabricated fallback evidence,
misleading capture handling,
unrelated-flow navigation,
clipped PDF output,
inaccurate guided-path completion,
stale asynchronous responses,
unknown port rendering,
and the difference between an observed port zero and an unknown port.

Codex is not part of PacketSage’s runtime analysis and does not process user evidence inside the application.

What I learned

The biggest lesson was that evidence-grounded AI requires structural controls, not only good prompts.

A trustworthy investigation workflow needs:

deterministic evidence before AI involvement,
exact relationships instead of heuristic matching,
bounded model inputs,
strict response schemas,
citation validation,
clear separation between observation and inference,
explicit human review decisions,
and honest failure instead of fabricated fallback output.

I also learned that small implementation details can have serious meaning in an evidence product.

A random ID can break reproducibility.

A convenient fallback can become fabricated evidence.

A stale model response can overwrite the wrong investigation.

A numeric zero can erase provenance.

A report checkbox can imply trust that the analyst never granted.

What I am proud of

PacketSage finished Build Week with:

deterministic evidence identities,
exact parser-established relationships,
bounded PCAP and PCAPNG decoding,
strict structured-text parsing,
evidence-grounded gpt-5.6-sol investigation,
validated exact citations,
cancellation and stale-response isolation,
a separate Gemini Capture Overview,
explicit report inclusion,
a full assessment workspace,
a guided investigation journey,
professional Preview, Markdown and PDF reporting,
responsive and keyboard-accessible workflows,
and explicit three-state port provenance.

The regression suite grew from no tracked tests at the pre-Build Week baseline to 333 passing tests.

The final production release also passed:

lint,
production build,
two npm audits with zero vulnerabilities,
PDF verification,
responsive browser checks,
exact-citation navigation,
live GPT-5.6 verification,
and browser credential scans.

What comes next

The next phase of PacketSage will continue the same evidence-first principle.

Near-term directions include:

bounded Evidence Query,
exact cited answers,
provenance-labelled external context,
case persistence,
authentication and access control,
and durable audit history.

Later directions include:

collaboration and review workflows,
SIEM and SOC integrations,
scalable capture processing,
custom deterministic rules,
cross-capture correlation,
private deployment,
and enterprise chain-of-custody workflows.

These are roadmap directions, not claims about the current product.

Every future capability must preserve the rule that shaped Build Week:

Observed evidence, deterministic derivation, external context and AI inference remain visibly separate.

Final reflection

I entered Build Week with an existing product, very little time and an exhausted Codex limit.

I finished with something more valuable than a larger feature list.

PacketSage now has a clearer purpose, a stronger evidence model and a workflow I can defend technically:

Help analysts use AI on network evidence without allowing inference to masquerade as observed fact.

Built With

analysis
api
cybersecurity
dns
evidence
express.js
forensics
gpt-5.6
incident
ipv4
ipv6
network
node.js
openai
pcap
pcapng
react
response
responses
security
tailwind
tls
typescript
vercel
vite