Tato Penn tatopenn-cell

Hi there I'm Tato Penn

👋 About Me

I am a Software Engineer and AI-driven scientific researcher based in Napoli, Italy.

I build software where ideas move through the complete engineering cycle:

research → design → prototype → implementation → testing → validation → documentation → release

My work sits at the intersection of:

🧑‍💻 Software Engineering
🤖 AI-assisted development
⚛️ Quantum simulation
🧮 Scientific computing
🛡️ AI runtime robustness
📈 Online machine learning
🧬 Computational biology

The goal is not simply to write experimental code, but to turn mathematical and scientific ideas into tested, reproducible and maintainable software.

I am the author of dense-evolution (PyPI 8.3.2), a JAX/XLA statevector simulator for NISQ circuits, VQE and QML; dense-armor (PyPI 1.1.33), an online-learning library for robots and LLMs with a runtime protection layer; Dense-Evolution-Discovery, the research lab where every claim is a script run and checked before it is written up; and local-quantum-rag, the local hybrid RAG that grounds the research in the actual PDFs.

Both published packages are developed as real software projects, with automated testing, CI, documentation and public releases.

🧑‍💻 How I Work

My development workflow is AI-assisted but human-supervised.

AI is used as an engineering tool — not as an autonomous decision maker.

1. 💡 Start from the problem

I begin from a concrete technical or scientific question.

The literature, mathematical model or existing implementation provides the starting point, but the final implementation is designed around the actual problem being solved.

2. 🧪 Prototype quickly

Ideas are first implemented as practical prototypes.

The objective is to discover:

what actually works;
where assumptions fail;
what needs to be redesigned;
which parts deserve production-quality implementation.

3. 🔬 Validate aggressively

A prototype is not considered successful simply because it runs.

Validation can include:

unit tests;
integration tests;
numerical checks;
statistical validation;
comparison against references;
independent implementations;
adversarial testing;
regression testing;
reproducibility checks.

When AI is involved, its output is also treated as something that must be verified rather than trusted automatically.

4. 🚀 Turn successful prototypes into software

Once an implementation proves itself, it is promoted into a proper engineering pipeline:

structured source code;
automated tests;
CI;
documentation;
package releases;
reproducible experiments;
research artifacts when applicable.

The objective is simple:

A result should be reproducible by running the software that produced it.

🔄 The Method: Four Phases

The engineering process above is written down in local-quantum-rag/docs as an explicit four-phase architecture. The four phases are not interchangeable: each has its own environment, its own success criterion, and its own model requirements.

1. Exploration. Idea to prototype. Cheap, high-context model, many iterations, execution happening outside the model's session. Divergent, conversational, no dedicated process document.

2. Verification. The question changes from does it work? to does it implement what the literature states?. A stronger model with retrieval access to the actual PDFs checks the code against the source paper, equation by equation, under a set of standing constraints on the agent's behaviour.

3. Discovery. The result moves into a public, reproducible environment where it may still be rejected. Every entry is a standalone script that produces its own result end to end; a negative result is written up with the same care as a positive one and left in place, so the next attempt does not repeat it. The single most common failure mode: a promising result that disappears under a negative control (shuffled labels, randomised baseline) was never a real effect.

4. Production. Only what survived Discovery ships to real users. The shipping list is checked against the real directory tree, the platform physically refuses a merge until the named checks are green, and publishing to the index is a separate human-confirmed step. A green checkmark is evidence toward safety, not proof of it.

Two principles run through all four phases:

Process documents are for the human, constraint documents are for the AI, and they are different documents.
A static instruction only constrains behaviour at the specific trigger points it names — everywhere else, it is invisible.

🧠 Engineering Mindset

I treat software development as an iterative engineering process.

Idea
  ↓
Prototype
  ↓
Test
  ↓
Validate
  ↓
Find weaknesses
  ↓
Redesign
  ↓
Automate regression checks
  ↓
Document
  ↓
Release
  ↓
Repeat

AI agents can accelerate individual steps, but the engineering process remains under human control.

Each agent has a specific task, its output is checked, and unexpected behaviour is investigated rather than silently accepted.

🔬 Research Interests

View full research interests

Quantum Phase Transitions & Order Parameters • Molecular VQE & Potential Energy Curves • Quantum Defect Mapping • Crystalline Lattice Dispersion & Tight-Binding • Strained-Silicon & GaAs Bandstructure Engineering • Quantum Lattice Thermodynamics (Phonon Scattering & Decoherence) • Zero-Noise Extrapolation (Stochastic Richardson, ZNE-before-PSR, Photonic Predictive) • Loschmidt Echo & Channel Non-Commutativity • Topological Mott Insulators • Quantum Error Correction (Steane [[7,1,3]] on Real Hardware Calibration) • Traversable-Wormhole SYK Teleportation • Online Machine Learning • AI Runtime Robustness • Robust Statistics • Computational Biology • Multi-Agent AI Pipelines

⭐ Featured Projects

⚛️ Quantum Simulation & Chemistry

🧮 dense-evolution

A JAX/XLA statevector simulator for NISQ circuits, VQE and QML.

The project combines high-performance numerical computing with quantum chemistry functionality, including:

stride-sliced kernel fusion;
JAX/XLA execution;
a native Hartree-Fock engine;
Obara-Saika recursion;
real molecular Hamiltonians;
Jordan-Wigner mapping;
Zero-Noise Extrapolation;
Richardson extrapolation;
Composer web UI;
MCP server for agent-driven control.

The project is distributed as a real Python package and includes public documentation, CI and research artifacts.

Concepts: Obara-Saika Recursion • Jordan-Wigner Mapping • Richardson Extrapolation • Kernel Fusion • JAX/XLA

🌀 Dense-Evolution-Discovery

The research and experimental layer built on top of Dense-Evolution.

It contains documented computational experiments, with results re-measured when changes to the underlying simulator or noise model could affect previous conclusions.

The goal is to keep the experimental process reproducible rather than treating research results as static numbers. Every claim is a script, run and checked before it is written up, with the negative results kept alongside the positive ones.

Current experiments include:

MPS GPU Optimization — the matrix-product-state simulator backend, made faster on GPU (2.16×, real API, real hardware), with the three real bugs found along the way;
Dense-Armor: Robot Safety Monitoring — drift/fault detection and safety filtering validated on real IMU, Lidar, and robot-arm (LeRobot) data;
Dense-Armor: Security Telemetry & AI Input Shield — real MITRE ATT&CK APT29 attack detection on genuine Sysmon telemetry, plus Orca protecting a real scikit-learn model from adversarial input corruption;
Quantum Simulation & Physics — TFIM phase transitions, VQE, ZNE, tight-binding materials, and a critical replication of the traversable-wormhole teleportation protocol;
Diagnostics & Healing — density-matrix noise diagnostics (Rényi divergence, magic entropy) and vector-healing bug fixes shipped back into Dense-Evolution;
Dynamic Vacuum Pressure Theory — a cosh-shaped vacuum regularization derived from three independent directions, checked against real EHT/LIGO/NICER data, with a dense_evolution-verified Z₂ symmetry linking cosh, the Bell state and Taoist duality.

Concepts: Parameter-Shift Rule • Born-Rule Kraus Sampling • Statistical Re-Verification • Negative Controls

🐙 Dense-Armor

An online-learning library for robots and LLMs. One sample at a time, inside a control-loop budget, with a runtime protection layer.

Learns one sample at a time. Every estimator has learn_one, predict_one, score_one. No retraining, no batch.
Fits a control loop. budget_s and RealtimePipeline refuse an estimator that does not fit the period.
Protects itself while it learns. Protected and SafeEstimator wrap any model; a drift detector, an anomaly detector or the Orca runtime shield can flag and fall back.
One base for everything. Classifiers, regressors, transformers, anomaly and drift detectors all inherit from dense_armor.roles. An estimator for a robot is also an estimator an LLM can call as a tool.

What is inside

Thirty families under dense_armor/utility/: linear models, naive Bayes, k-NN, incremental trees and forests, ensembles, factorization machines, recommenders, bandits, multiclass and multi-output; the full neural stack (dense, convolution, RNN/GRU/LSTM, multi-head attention, transformer blocks, plus mlp, resnet_mlp, cnn, recurrent_net, transformer_encoder); streaming statistics and sketches; CUSUM, Page-Hinkley, ADWIN, KSWIN, BOCPD; fourteen anomaly detectors; twenty online metrics; online vision; kinematic control and CBF filters.

The protection layer (protect/): Armatura (a Phi_AB coherence trigger on 1D signal streams) and Orca (an adaptive stabilizer with a Collatz-based damping gate). Thresholds adapt with Jensen-Shannon divergence on the local window. Adversarial robustness is measured against the same engine the system uses, not a separate benchmark; weak cases are reported, not hidden.

Optional bridges, installed as extras: [river], [llm], [quantum], [vision], [drone], [ros], [finance-stream], [data], [audio], [mcp].

Documentation: 35 sections on the site, including docs/drones/ (13 pages), docs/finance/ (17 pages), docs/shields/ (5 pages) and docs/compare/ where each batch class of the machine-learning task is compared, on the same data and metric, with its online counterpart.

Concepts: online learning · one sample at a time · control-loop budget · JAX/XLA · finite-difference gradient checks · CUSUM · ADWIN · BOCPD · prequential evaluation · Jensen-Shannon adaptive threshold

🤖 Retrieval-Augmented Research

🔍 local-quantum-rag

A small, local, hybrid RAG tool for grounding technical conversations in your own PDFs and notes, so an AI assistant cites what a document actually says instead of what it remembers.

A CLI (query.py) covers everyday use; an optional local FastAPI server (server.py) keeps the embedding and reranker models warm across repeated queries, with endpoints /search, /search_exact and /collections, an in-process mtime-invalidated cache and token auth (QUANTUM_RAG_TOKEN).

The four-phase methodology described above lives here, together with a case study of a context-reload trigger gap found and fixed.

Concepts: hybrid retrieval · cross-encoder reranking · PDF grounding · FastAPI · token auth · mtime cache

🧬 Computational Biology

🧫 Dense-Evolution-Molecular-Pipeline

🚧 Work in progress — repository currently private.

A hybrid bio-quantum computational pipeline for Chronic Myeloid Leukemia treatment optimization.

The current architecture combines:

JAX-accelerated genetic algorithms;
BCR-ABL1 kinase-domain sequence exploration;
Meta ESMFold API;
protein structure generation;
JAX-native molecular docking;
computational optimization.

The project will be featured publicly once the implementation is ready to share.

📊 Engineering Signals

The projects are intended to demonstrate not only research ideas, but the ability to turn those ideas into software artifacts.

Project	Package	CI	Tests	Documentation	Research Artifact
Dense-Evolution	✅ PyPI 8.3.2	✅	✅	✅	✅ DOI
Dense-Armor	✅ PyPI 1.1.33	✅	✅	✅	✅ DOI
Dense-Evolution-Discovery	🔬 Research repo	✅	🔬	🔬	✅ DOI
local-quantum-rag	🔬 CLI + FastAPI server	✅	🔬	🔬	✅ DOI

The important distinction is between an experiment that runs once and software that can be tested, reproduced, documented and released.

🛠️ Technical Stack

⚛️ Quantum & Scientific Computing

🧪 Testing & Code Quality

📊 Data & Figures

🧠 Deep Learning & Adversarial

🧬 Bio-Computational

🔍 RAG & AI Tooling

📄 Research Tooling

📦 Release & Publishing

🤖 Multi-Agent & Knowledge Tooling

🧑‍💻 Development Environment

⚙️ Tools & Workflow

🔄 From Research to Software

Scientific / Technical Idea
            │
            ▼
       Literature
            │
            ▼
        Prototype
            │
            ▼
     Practical Testing
            │
            ▼
   AI-Assisted Validation
            │
            ▼
   Independent Verification
            │
            ▼
    Automated Regression
            │
            ▼
      Documentation
            │
            ▼
       Package / Release
            │
            ▼
    Reproducible Artifact

The objective is to make the entire chain traceable.

Idea → implementation → test → result.

💡 Philosophy

A paper becomes math, math becomes code, and every claim — quantum, statistical, or biological — ships next to the script that produced it.

Good research should be reproducible.

Good software should be testable.

And when the two meet, the implementation should make the reasoning easier to inspect rather than harder.

📬 Get in Touch

Questions, ideas, or a paper worth implementing?

tatopenn@gmail.com · LinkedIn · Dense-Evolution issues → · Dense-Armor issues →