-
-
INPUT → DETECT → MAP → SIMULATE → HUMAN REVIEW
-
INPUT → DETECT → MAP → SIMULATE → HUMAN REVIEW
-
INPUT → DETECT → MAP → SIMULATE → HUMAN REVIEW
Inspiration
Most detection tools stop at classification: suspicious or safe, good or bad, approved or rejected. That is useful, but incomplete.
A suspicious link is not automatically a scam. A delayed administrative decision is not automatically misconduct. A single marker should begin an investigation, not end one.
HunterPiggy grew from two years of research into manipulation, algorithmic influence, child-safety risks, institutional processes, and explainable AI. The central principle is simple:
Detect the signal. Reconstruct the mechanism. Do not issue a verdict.
The project combines two connected perspectives:
- detecting correlated signals of scams, manipulation, suspicious links, obfuscation, and structural anomalies;
- reconstructing how multiple mechanisms may interact over time and produce a durable outcome.
This makes HunterPiggy useful not only for scam and manipulation detection, but also for examining institutional and administrative sequences without classifying people or making automated accusations.
What HunterPiggy does
HunterPiggy is an explainable signal-to-trajectory engine.
Its first layer, ThreatSignalRouter, detects transparent markers including:
- manipulative or scam-style language;
- shortened and verification-style URLs;
- obfuscated contact details;
- urgency formatting;
- encoded or high-entropy structures;
- sensitive contexts;
- structural anomalies;
- correlations across multiple signal categories.
Individual markers remain weak evidence. Correlation increases review priority, but never becomes a legal or moral verdict.
Its second layer examines institutional mechanisms. SignalRouter extracts relevant markers, while the PICBosonAdapter maps them to Ian Tasker’s Political–Institutional Contingency framework:
- PIC–S: Structural Design;
- PIC–C: Cultural Norms;
- PIC–P: Procedural Action;
- PIC–F: Fiscal Prioritisation;
- PIC–J: Jurisdictional Boundary-Setting;
- PIC–T: Temporal Constraint.
The PIC framework is used with its author’s permission.
Finally, the CairoResonanceTrajectoryEngine models possible growth and shadow trajectories. The result includes signals, confidence, uncertainty, key levers, counter-hypotheses, limitations, and an audit trail.
Conceptually:
$$ \text{signals} + \text{interacting mechanisms} + \text{time} \rightarrow \text{possible trajectories} $$
These trajectories are explainable hypotheses—not predictions of fact.
What existed before Build Week
Before OpenAI Build Week, HunterPiggy existed inside the wider Python Zero / Kai256 research system as a transparent signal router.
It could detect and prioritise URL, linguistic, contextual, structural, and reputation markers associated with scams, manipulation, and anomalies. Its operating rule was already:
“I see a signal. I do not issue a verdict.”
However, it was not an independently installable product and could not reconstruct how interacting mechanisms developed across time.
What I built during OpenAI Build Week
Between 13 and 21 July 2026, I used Codex and GPT-5.6 to turn the existing research component into a standalone, runnable project.
The new Build Week work includes:
- extracting HunterPiggy from the monolithic Python Zero / Kai256 system;
- introducing the Cairo Resonance Trajectory Engine as a causal trajectory layer;
- repairing invalid and duplicated prototype structures;
- changing simulation output from repeated final-state values to genuinely evolving time steps;
- adding bounded, seeded simulation for reproducible results;
- building the PIC–Boson Adapter;
- integrating scam detection and institutional mechanism analysis into one pipeline;
- adding counter-hypotheses and explicit uncertainty;
- creating a neutral demonstration;
- creating an automated test suite;
- documenting provenance, attribution, limitations, and the exact division between prior and new work.
The dated repository history and BUILD_WEEK_CHANGELOG.md document this contribution.
How I collaborated with Codex and GPT-5.6
I made the research, product, safety, architecture, and framework-integration decisions. Codex and GPT-5.6 acted as technical collaborators.
They helped me:
- audit the 19 July trajectory prototype;
- identify duplicated source, invalid data-model ordering, non-evolving output, and non-reproducible simulation;
- translate the research architecture into a clean Python package;
- implement and connect the routers, PIC adapter, trajectory engine, and public pipeline;
- create deterministic tests and a runnable demo;
- challenge unclear assumptions;
- distinguish the pre-existing foundation from the Build Week implementation.
Codex accelerated implementation, debugging, restructuring, documentation, and verification. The central human-led decision remained unchanged: HunterPiggy must analyse signals and systems without classifying people or automating consequential decisions.
Challenges
The first challenge was conceptual. Scam detection and institutional analysis appear unrelated until both are treated as sequence-reconstruction problems. In each case, isolated markers are insufficient; meaning emerges from correlations, context, mechanisms, and time.
The second challenge was technical. The original trajectory prototype contained duplicated source, invalid data structures, non-deterministic behaviour, and a simulation that repeated final states instead of exposing an evolving trajectory. These issues had to be found and repaired before the project could become testable.
The third challenge was explainability. HunterPiggy needed to expose why a signal mattered while clearly separating:
- marker from evidence;
- correlation from causation;
- simulation from fact;
- review priority from verdict.
What I learned
The most important lesson was that uncertainty is not a weakness in a detection system. Properly represented uncertainty is part of its safety architecture.
I also learned that the same explainable pipeline can connect cybersecurity-style signal detection with institutional mechanism analysis. The common unit is not the person being evaluated. It is the trajectory created by interacting signals, constraints, resources, decisions, and time.
Current limitations and next steps
HunterPiggy currently analyses text deliberately submitted to it. Its routers are transparent baselines rather than trained classifiers, its reputation list contains demonstration data, and false positives and false negatives are expected. Human review is mandatory.
Next steps include:
- configurable domain and signal sources;
- structured evidence ingestion;
- interactive trajectory visualisation;
- comparison of alternative intervention points;
- stronger evaluation datasets;
- educational integration with KidsPiggy;
- privacy-preserving local deployment.
HunterPiggy does not answer, “Who is guilty?”
It asks a more useful and responsible question:
What signals and interacting mechanisms could have produced this trajectory, and what evidence would distinguish one explanation from another?
Log in or sign up for Devpost to join the conversation.