A visual, evidence-aware cyberengineering atlas.
Learn the systems behind secure software, trustworthy hardware, resilient networks, and responsible security research.
Start learning • Open NIGHTSHIFT • Explore research • Browse all missions
Launch NIGHTSHIFT on GitHub Pages ↗
A research portfolio, not a deployed defense product. Every exercise and proposal is scoped to owned, synthetic, or explicitly authorized systems. The work documents models, methods, and evaluation plans; it does not claim field effectiveness.
A custom static web experience with a visual profile, searchable missions and tools, a local field notebook, hardware models, conference coverage, and a diagram gallery. |
Real hardware photographs sit beside conceptual architectures for device trust, RF work, firmware recovery, and reproducible bench measurements. |
Use real device imagery as a starting point for questions about interfaces, signals, firmware boundaries, and evidence limits. |
See how radio and RFID research is framed as authorized, reproducible observation rather than a collection of unexplained commands. |
Every field-guide entry explains its input, transformation, output, operating limit, and the manual or primary source behind it. |
Hardware photographs are credited in the image ledger. They illustrate supported learning concepts; the repository does not provide unauthorized device-operation instructions.
01 FOUNDATION Build vocabulary, inspect local systems, and learn to read manuals.
|
02 OBSERVATION Understand packets, devices, logs, and the limits of each measurement.
|
03 ENGINEERING Model trust, provenance, recovery, identity, and resilient operations.
|
04 EVALUATION Define a falsifier, measure a result, record uncertainty, and stop safely.
|
05 RESEARCH Connect a bounded mission to its evidence, sources, and graduate challenge.
| Flight phase | What you will be able to explain | Launch point |
|---|---|---|
01 FOUNDATION |
The difference between an interface, protocol, service, process, packet, and claim | MERCURY Foundations |
02 OBSERVATION |
What a tool or device actually measures, and what it cannot establish | Tool field guide |
03 ENGINEERING |
How security constraints are designed into software, hardware, and operations | Mission Systems & Architecture |
04 EVALUATION |
How to turn a concept into an authorized, falsifiable experiment | Research method |
05 RESEARCH |
How advanced missions connect to models, resources, and open challenges | Research Flightbook |
| Begin with a question | Click through |
|---|---|
| I am new to IT or security. Learn the vocabulary, local HTTP, teams, tools, manuals, and six safe labs. | MERCURY Foundations |
| I want to understand a device trust model. Follow physical systems from PCB design through firmware recovery and provenance. | Hardware & firmware trust |
| I need an advanced research problem. Use a falsifiable proposal with its data plan, guardrails, and evaluation criteria. | Research Flightbook |
| I want a guided assessment progression. Move from core concepts through authorized assessment engineering and graduate exercises. | Assessment Flightbook |
| I want the complete map. Browse every original mission in permanent reading order. | 150-mission index |
HELIOS Systems Digital Twin — a Blender/Fusion-style reference model for the connected engineering layers in this atlas. Open the visual log →
HELIOS Chain of Trust — a 3D engineering reference that makes every trust claim traceable from silicon to recovery. Open the hardware bench →
Click the model to open the visual gallery.
The atlas connects evidence, uncertainty, dependencies, and decision-making instead of treating cybersecurity as a disconnected tool list:
flowchart LR
A["Observe<br>systems, signals, and constraints"] --> B["Model<br>evidence, dependencies, and uncertainty"]
B --> C["Test<br>on owned, synthetic, or authorized systems"]
C --> D["Decide<br>with safety limits and measurable outcomes"]
D -. revise with new evidence .-> B
Explore the visual models: network observability | supply-chain provenance | firmware trust | recovery engineering | full gallery
| Portfolio | What it contains | Proof-oriented approach |
|---|---|---|
| 15 cyberengineering domains | Architecture, formal assurance, hardware, provenance, networks, forensics, identity, cloud, AI, OT, RF, people, resilience, authorized exposure, and measurement | Every idea includes a mechanism, data plan, falsifier, and guardrail |
| 150 original mission proposals | Ten permanently numbered missions per domain | Open the indexed map |
| 180 research dossiers | The original missions plus thirty NASA-inspired proposals, domain models, resource contracts, and graduate challenges | Open the Research Flightbook |
| 150 assessment modules | A basic-to-advanced path for authorized red/blue-team assessment engineering | Open the Assessment Flightbook |
| Custom learning software | Search, filtering, bookmarks, browser-local notes, responsive layouts, and a document reader | Explore NIGHTSHIFT |
Choose a system area, then drill into ten linked proposals. Mission numbers are permanent, so the atlas can be read linearly or entered from the domain closest to your work.
| Orbit | Domain | Missions |
|---|---|---|
| 01 | Mission Systems & Architecture | 001–010 |
| 02 | Formal Software Assurance | 011–020 |
| 03 | PCB, Hardware & Firmware Trust | 021–030 |
| 04 | Supply Chain & Provenance | 031–040 |
| 05 | Network Observability | 041–050 |
| 06 | Forensic Science and Evidence Integrity | 051–060 |
| 07 | Identity, Consent and Authority | 061–070 |
| 08 | Cloud, Workload and Recovery Systems | 071–080 |
| 09 | AI Systems and Bounded Automation | 081–090 |
| 10 | Cyberphysical and Operational Resilience | 091–100 |
| 11 | RF, space, and remote systems | 101–110 |
| 12 | Human factors and security learning | 111–120 |
| 13 | Incident response and resilience | 121–130 |
| 14 | Authorized exposure and intelligence governance | 131–140 |
| 15 | Measurement, governance, and futures | 141–150 |
| If you need to... | Start here | First credible result |
|---|---|---|
| Model what fails next | Function-First Risk Atlas and Blast-Radius Digital Twin | An owned-service dependency model that predicts held-out incident consequences better than an asset-only baseline |
| Make hardware trust visible | Trust-Visible PCB and CAD-to-Fab Provenance Chain | A bench prototype with testable layout review, fabrication lineage, and interrupted-update recovery |
| Communicate uncertainty honestly | Memory Snapshot Confidence Map and Evidence-Bound Security Assistant | A synthetic case that distinguishes observed facts, unobservable gaps, and unsupported inference |
| Design for isolation or link loss | Island-Mode Mission Test and CubeSat Update Survival Model | An emulator or bench exercise measuring essential-function survival, rollback, and signed evidence delivery |
| Engineer measurable privacy | Private Correlation Token and Data-Minimization Twin | An approved data-flow experiment that quantifies retained utility against collected identity data |
- Proposal, not result. Citations ground design constraints; they are not evidence of achieved performance.
- Authority is explicit. RF, OT, spacecraft, and external-exposure studies require review before active trials.
- Data stays controlled. The repository excludes raw captures, memory dumps, executables, OSINT material, and personal records.
- Failure matters. Evaluations record false alarms, missing observations, operational cost, privacy impact, and stop conditions.
| Need the details? | Link |
|---|---|
| Research method and evidence threshold | Editorial research method |
| System campaign model | System architecture |
| Source scope and provenance | Source ledger |
| Contribution standards | Contributing guide |
| Delivery register | Delivery status |
| Community and public-source directory | ORION directory |
| Bounded public intelligence research | Public Intelligence desk |
NIGHTSHIFT is a static site with no analytics, live hardware connection, or remote tool execution. It is published automatically to GitHub Pages from main. Its notes, theme preference, and bookmarks stay in the current browser through local storage.
python scripts/build_site.py
python -m http.server 3000 --bind 127.0.0.1 --directory siteThen open http://127.0.0.1:3000. Use HTTP rather than file:// so the local catalogs and document reader can load.
Validate the atlas and portal with:
python scripts/build_atlas.py --check
python scripts/build_site.py --check
python scripts/check_site.py