IntSpekta / PC1

Development biography · earlier archive

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

IntSpekta / PC1

Project biography

IntSpekta, carried in the PC1 Xcode project, addresses a practical difficulty in technical investigation: observations arrive through different instruments and are often inspected in disconnected tools. A packet window, an RSSI change, a Bluetooth observation and an RF measurement can describe related activity, yet each has its own timing, representation and limitations. PC1's source brings those research surfaces into one desktop application. Its documented direction is a local workstation in which a person can inspect observations, connect evidence and decide what to investigate next. A personal founding story or original launch date was not established; the source and integration documents support this technical purpose without requiring an invented origin narrative.

The intended audience is technically capable researchers, network analysts, developers and operators working with authorized systems and captures. The application is organized as multiple windows instead of a single dashboard. The current entry point declares Entropy Capture, RSSI Dashboard, RSSI Live, HackRF Monitor, SDR Analysis, Analysers, Forensics Utilities, Bluetooth and several Wi-Fi surfaces. It also declares Packet Investigation, Network Reasoning, Endpoint Control, Workload Control, MCP Bridge, Gateway Enforcement and DH Case Operations. These are source-visible entry points. Their presence establishes authored UI integration, not that every connected instrument or operational workflow was exercised during this inspection.

A concrete visitor-friendly journey begins with an existing capture file. The analyst opens Packet Investigation, supplies the file for passive analysis, and follows packets into the associated evidence and report views. The integration documentation describes packet/evidence navigation and signed JSON/HTML archive export. The underlying investigation packages provide file analysis and verification interfaces. This makes a useful website narrative because it follows a visible task from input to evidence. It should be labelled as the intended source-implemented workflow until a separately cleared, installed-product recording demonstrates the interaction. No app was opened to create such a recording for this profile.

Other windows broaden the workstation around that central evidence workflow. RSSI and Wi-Fi surfaces expose wireless observations; Bluetooth has its own window; HackRF and SDR surfaces connect to radio-oriented work. The project guide describes CMAC, the Cross-Matrix Analytics Coordinator, as a local/offline advisory layer combining available evidence and readiness information into suggestions and runbooks. That is a design direction and governed assistance boundary, not permission for autonomous intrusive operations. Passive observation and evidence preservation are the preferred starting points; active or privileged tooling requires its own target authorization and audit controls.

The architecture is deliberately split across local packages. PacketCapture supplies packet-facing services, ForensicsCore supplies legacy hash/entropy facilities and the newer ForensicReasoning product, and PacketAnalytics supplies research and investigation APIs. The current project file also references SpectralProcessor, Imager, SemanticControlCore, SemanticCompute and ResearchControls. A dependency being linked does not prove that every one of its features is exposed or accepted in the app. Generated protocol metadata forms another substantial resource layer and is distinct from the hand-authored UI and package logic.

Maturity needs to be expressed at the level of each claim. The research documentation records successful historical signing-disabled PC1 builds and package tests. It also explicitly says installed interaction and live research-window delivery are unverified. The latest scoped research checkpoint records 150 bounded finite facets, 67 capture-integration facets and 67 scoped external-reference facets, with zero full scientific gates. Those are qualified research results, not a count of finished product features or a real-world detection-accuracy score. Subsequent L6/L13 contract, oracle and launch-authority work remains preparation-only. The most credible public account is therefore a substantial, source-implemented research workstation with retained validation evidence and clearly identified acceptance gaps.

The workstation also has a substantial generated-resource layer. Protocol metadata is copied into application resources by the project, while operational views and package adapters remain authored source. The project distinguishes that resource inventory from demonstrated protocol coverage and from accepted analytical results.

Features, foundations and maturity

Roadmap: installed passive-workflow acceptance; reproducible package/runtime closure; instrument-specific readiness and live validation; stronger helper, policy and audit boundaries. A trusted launch gate remains a researched requirement, not a shipped capability.

FAQs

• Is this a Wireshark replacement? No equivalent-coverage claim is established. It is a broader research workspace with its own capture, evidence and reasoning integrations.
• Does it automatically attack or contain devices? The documented boundary requires explicit governance for intrusive or privileged operations. Do not market advisory output as autonomous execution.
• Can every research layer be called scientifically validated? No. Full scientific acceptance remains zero in the retained checkpoint.
• Can visitors download it? No verified public release or download endpoint was established.

PacketCapture

Project biography

PacketCapture is the acquisition and packet-services layer in this family of projects. Its README describes a modular pipeline in which packet sources emit events, an orchestration manager controls source lifecycles, and subscribers consume traffic for analysis or presentation. This separation addresses an important engineering problem: applications need to work with live traffic, saved captures and synthetic inputs without duplicating every downstream analysis path. The documented motivation is practical reuse across PC1 and command-line network diagnostics. A legacy coordination workspace records a 7 October 2026 plan to improve the package and CLI for PC1 and ccx; that workspace is supporting project history, not a separate released product.

The current manifest defines several distinct products. PacketCapture is the main library. PacketCaptureKit contains CLI-facing diagnostic and capture-file services. PacketEvidence is the focused research-evidence product. The package also declares the pccap command-line executable and PacketCaptureApp. These products serve different audiences: application developers can link libraries, technical operators can use a CLI workflow, and research code can depend on explicit packet evidence without assuming a desktop UI. No executable was run during this profile, so examples should describe the interface rather than imply a newly observed terminal demonstration.

The main README presents libpcap, RVI, AWDL, replay and mock-source concepts, a PacketEvent representation, and a central event bus. That README is an architectural overview and contains broad language about concurrency and performance. Those statements should not be turned into a measured throughput claim. The source tree and manifest provide stronger evidence for the current product boundaries: PacketCaptureKit contains interface inventory, diagnostics, live-capture services, offline PCAP I/O, traffic analysis, decoding, schemas and evidence adapters. PacketCapture links native and Swift dependencies for packet capture, networking, cryptography and optional radio support.

A concrete user journey begins with readiness and an existing capture. A developer or analyst identifies the intended interface or file, uses diagnostic services to understand availability, processes frames through the relevant packet APIs and produces a structured report. The report can then be consumed by PC1 or by the investigation layer. Live acquisition is a separate action with interface permissions and environmental requirements. An offline research adapter does not silently start capture: its documented role is to convert actual CapturedFrame or PacketEvent values into typed research evidence supplied with capture ID, sensor ID, ordinal and timestamp uncertainty.

The evidence integration is a distinctive part of the package's current direction. PacketEvidence contains wire-evidence records, reassembly alternatives, bounded protocol decoders, packet lineage, integrity/completeness reporting and timestamp-alignment contracts. The integration document describes QUIC Initial decryption and explicitly limits later key spaces and migration claims. It also warns that a borrowed-byte decoder interface is not end-to-end zero-copy acquisition. The adapter refuses missing DLT or wire-length metadata instead of inventing defaults. For a website, these are useful examples of engineering choices that preserve the distinction between original observations and interpretation.

Native dependencies are material to the experience. CPcap uses SDK-provided libpcap, while HackRF/libusb support can require additional native dependencies and hardware. The manifest has a portable mode that drops those radio modules and an opt-in HackRFSupport target described as mid-refactor. These boundaries should remain visible in developer documentation. The package declares iOS as a platform, but that alone does not establish that every macOS capture source, external utility or hardware path works on an iPhone or iPad.

Current maturity is mixed by component and evidence epoch. The research integration documentation reports official-vector testing for QUIC Initial decryption; the shared validation ledger records historical package tests and PC1 builds. Neither is a fresh acceptance test of every PacketCapture backend. The README's aspirational breadth, retained test results and active package source should be presented together, with no invented version, public binary or performance guarantee. The package's value is its reusable architecture and evidence-aware interfaces; its roadmap is to make backend readiness, portability, operational validation and independent capture lineage progressively more explicit.

Roadmap and limits: backend-specific runtime acceptance; portable/native dependency documentation; continued bounded decoder validation; stronger acquired-capture provenance; finish or isolate optional HackRF support. No automatic dependency installation or hardware operation is implied.

FAQs

• Is PacketCapture the PC1 app? It is a library/tool family used by PC1; the desktop workstation is a separate project.
• Does PacketEvidence acquire packets? Its adapter converts supplied frames/events. Conversion itself does not start capture.
• Is everything zero-copy? No. The documented borrowed interface does not eliminate allocations across the complete pipeline.
• Is the legacy the project archive workspace another product? No separate product was established; its roadmap is supporting coordination history.

ForensicsCore and ForensicReasoning

Project biography

ForensicsCore addresses the representation and integrity side of investigation. Once an application has bytes or observations, it needs a way to identify them, describe their provenance and distinguish later transformations from the original material. The preserved library contains hash/entropy and CBOR-related facilities. Its newer ForensicReasoning product is deliberately separate from the legacy API, allowing research-oriented evidence and inference types to evolve without presenting every historical implementation as one uniform product. The inspected sources document this additive relationship; they do not establish a personal origin story or a public release history.

The newer evidence model gives records explicit categories: observed, derived, inferred, external, unknown and unsupported. Packet references include capture identity, sensor identity, ordinal and a digest of the bytes. Artifact references identify non-packet material. Evidence records can name parent records, methods, versions and parameters. This structure gives a consuming application a way to show where a statement came from and how it was produced. It also makes a useful public explanation: the library is concerned with preserving the path from observation to claim, not simply producing an impressive-looking confidence number.

Time is another distinctive boundary. EvidenceTime stores a value and uncertainty, validates the input and compares intervals with an indeterminate outcome when ordering is not established. The original sensor time is not overwritten by alignment. That choice matters when records from different instruments are combined. An application should not quietly convert uncertain timestamps into a definite sequence. The library's types and constraints give callers a way to retain ambiguity and explain why a conclusion is weaker than a neat timeline might suggest.

A representative developer workflow starts by constructing references to supplied packet or artifact bytes, then adding evidence records with declared methods and dependencies. The application can build a graph, attach observations or propositions and ask bounded reasoning APIs to operate on that declared support. Reports can then retain references back to the source records. This is a compositional workflow: acquisition, case policy and UI remain outside the library. It is not a background collector and does not establish that the bytes were obtained from an authentic, independent sensor merely because their digest matches.

The integration document describes evidence hash chaining, replay verification, dependency DAGs, confidence dimensions, cross-domain observations and a unified evidence graph. It also describes hypothesis competition and information gain. The source explicitly labels conditional independence as a caller assumption and posterior output as model-conditional rather than calibrated. Likewise, constraint entailment is relative to declared premises and timing bounds. These qualifications are central to the project biography: formal structure, statistical support and truth about the external world are different claims, and the library is designed to keep them distinguishable.

Persistence adds another layer. EvidenceLedger is described as append-only in memory, while DurableEvidenceStore adds disk persistence, raw blobs, quotas, signed manifests and verification against pins. The documentation expressly leaves independent trust and external retention of manifests/keys to the caller. A website should therefore avoid describing this as an immutable evidence platform or a legally certified chain-of-custody service. The library supplies mechanisms for an application to use; the storage threat model, authentic acquisition and independent custody still require a larger operational design.

There are two preserved ForensicsCore trees. The current PC1 project file points to the Xcode checkout, matching PacketCapture's dependency. The research integration document says this resolved a duplicate identity/product conflict without merging or deleting the other tree. The older project guide still describes the earlier conflict, so it should not be copied unchanged into the website. The active Xcode manifest exposes both ForensicsCore and ForensicReasoning; the inspected SanDisk manifest exposes only ForensicsCore. This is a concrete example of why source location and evidence epoch matter.

The appropriate maturity label is implemented research infrastructure with retained component/integration validation, not blanket scientific or production acceptance. Historical validation records can support specific builds and tests. They do not establish every trust boundary or all 150 scientific gates. The next development themes are independent provenance, operational persistence/retention, clearer integration contracts and model calibration where a consuming application makes statistical claims. No public package release, standalone download or installed UI was established for this profile.

FAQs

• Does a hash prove authentic acquisition? No. It binds bytes; acquisition authenticity needs independent evidence.
• Are posterior probabilities calibrated? Not automatically. The implementation labels them model-conditional and leaves model assumptions explicit.
• Is the evidence store immutable? The documentation does not make that blanket claim; trust and external retention remain caller obligations.
• Which checkout should the site describe? The current Xcode checkout for the additive reasoning product, with the preserved SanDisk tree identified as related history.

PacketAnalytics / Packet Investigation — related substantial research layer

Project biography

PacketAnalytics occupies the analytical layer between packet acquisition and an investigator's report. PacketCapture supplies packet-facing services and evidence adapters; ForensicReasoning supplies typed support and inference primitives. PacketAnalytics composes those foundations into research sessions, multi-flow investigations and file-oriented workflows. Its README states that the active target is Sources/PacketAnalyticsResearch. Earlier sketches under Sources/PacketAnalytics are preserved outside that target. This matters for a website because the repository's history should not be mistaken for a single, uniformly active implementation.

The package declares PacketAnalytics and PacketInvestigationIO libraries, plus packet-investigate and packet-research-demo executables. PacketInvestigation processes bounded multi-flow windows. ResearchSession is a smaller one-flow interface. ClosedLoopInvestigation accepts grounded cross-domain observations, while PacketInvestigationIO provides file analysis, signed export and verification. These entry points give developers different levels of composition. They do not mean every model or cross-domain integration is automatically selected for arbitrary input. The README explicitly asks callers to supply validated observations and model parameters where required.

A concrete investigation journey begins with an existing packet file. The file layer reads it into the supported investigation path, preserving packet/evidence references. The analyst inspects supported decodings and derived records, then exports or verifies an archive. In PC1 this is represented by the Packet Investigation window and its packet/evidence navigation. Command-line users have a separate file-oriented entry point. This profile does not claim the installed window was exercised, and it does not provide a fabricated terminal recording. The source and integration documents support the workflow; runtime interaction needs a separately captured demonstration.

The research direction is broader than packet parsing. Documentation describes graph/twin observations, sensing suggestions, audit/reporting and a 58-topic specification. The synthetic demo prints research outputs without capture, network calls or tool execution. That makes it a developer example, not an accuracy benchmark. The package also retains a protocol/packet weight catalogue, but catalogue definitions are not a count of validated detections. The governing idea is to make explicit the evidence, assumptions and limits under which an analytical result is meaningful.

The L1–L150 programme provides a detailed maturity framework. The latest retained completion checkpoint, dated 10 October 2026, records 150 bounded finite facets, 67 capture-integration facets and 67 scoped external-reference facets, with zero full scientific acceptance. Its comparison work supports agreement over declared retained artifacts and fixtures. It does not establish hidden-world recovery, general detection accuracy or complete implementation acceptance for every layer. Historical test counts and build results belong to their source snapshots. They must not be added together across overlapping groups or relabelled as a fresh test of the current checkout.

Later work on L6 and L13 has prepared contracts, oracle expectations, serialization witnesses, supervisor source and authority designs. Those additive packets were independently reviewed at their stated preparation scopes. Execution remains on hold, and the reserved Phase4 material remains unread. The recent macOS feasibility review concluded that useful helper/journal components exist but the strict trusted launch/guardian composition is not established by the reviewed evidence. None of that preparation increases capture, reference or scientific gate counts. It is supporting research discipline, not a new public feature claim.

Two PC1 review capsules preserve controlled source-review context: the finite-expansion capsule and the establishment capsule. They are supporting research snapshots, not separate applications, live demos or media assets. Their historical receipts must remain tied to their original qualification and source bindings. The current editorial account should point to the later completion checkpoint for current scoped counts and use the capsules only to explain how source review and evidence preservation were organized.

The roadmap is to close acquisition, calibration, integration and runtime acceptance gaps through concrete reviewed work, preserving failed attempts and original evidence. A public-facing page can explain these goals without implying that deferred computational theory or scientific stages are complete. No public release URL or supported download was verified. The package is best presented as an active research foundation and developer toolchain with unusually explicit evidence boundaries, rather than a production detector with a single global confidence score.

FAQs

• What does 150 mean? Bounded finite implementation facets in a scoped research framework, not 150 scientifically validated detectors.
• Does the demo capture traffic? Its README says the synthetic demo performs no capture, network calls or tool execution.
• Does a scoped reference check prove real-world accuracy? No. It supports the declared retained-artifact comparison only.
• Are the review capsules separate products? No; they are preserved supporting review snapshots.