Research-Backed Source Architecture and Method

1. Purpose of This Section

Before continuing into detailed domain roadmaps, the plan needs a researched foundation.

The previous section established the identity and philosophy of the plan: become a person who deeply understands, builds, experiments, writes, researches, reflects, publishes, and serves across many domains. That remains correct.

However, the plan should now be strengthened with researched sources, not just general reasoning.

This section defines the source architecture for the entire master plan.

The rule is:

Every domain must be guided by reliable sources, but proven through practical output.

Reliable sources prevent shallow internet wandering.

Practical output prevents passive academic fantasy.

The plan is based on the life direction you gave: software, AI, operating systems, cybersecurity, philosophy, electrical and electronic engineering, research, math, physics, quantum computing, design, and building/doing as a way of life.

2. The Source Hierarchy

Not all resources should be treated equally.

A YouTube tutorial, a university course, an official standard, and a random blog post are not the same kind of source.

The plan should follow this hierarchy.

Tier 1 — Primary and Official Sources

These are the highest-value sources.

They include:

• official documentation
• standards
• original papers
• textbooks by recognized publishers
• official course materials
• official tool documentation
• official certification/exam pages
• official project repositories
• datasheets
• RFCs
• academic encyclopedias
• primary philosophical texts

Examples:

• MDN for web platform documentation
• React documentation for React
• Node.js documentation for Node
• PostgreSQL documentation for PostgreSQL
• Docker documentation for Docker
• Kubernetes documentation for Kubernetes
• MIT OpenCourseWare for math and physics
• OpenStax for structured textbooks
• PyTorch and TensorFlow documentation for deep learning
• KiCad documentation for PCB work
• OWASP and PortSwigger for web security
• Stanford Encyclopedia of Philosophy for philosophy
• PhilPapers for philosophy literature search

MDN describes itself as a comprehensive resource for HTML, CSS, JavaScript, Web APIs, and other web technologies, while React’s official documentation is the correct starting point for learning React concepts and reference material. (MDN Web Docs)

The reason Tier 1 matters is simple:

If I want to become serious, I must become comfortable reading the sources serious people use.

Tier 2 — University Courses and Open Textbooks

These sources provide structured learning.

They are not always enough by themselves, but they are excellent for rebuilding foundations.

Examples:

• MIT OCW
• OpenStax
• university lecture notes
• course assignments
• public exams
• problem sets

MIT OCW’s Mathematics for Computer Science course explicitly covers discrete mathematics for computer science and engineering, including proof methods, induction, sets, graph theory, asymptotic notation, counting, and discrete probability. OpenStax provides free structured textbooks such as Calculus Volume 1 and University Physics. (MIT OpenCourseWare)

The standard for these sources is:

Do not only watch lectures. Do the assignments, solve the problems, and produce notes or implementations.

Tier 3 — Books and Canonical Texts

Books are essential when the topic requires depth.

This applies especially to:

• operating systems
• computer systems
• algorithms
• quantum mechanics
• quantum computing
• electronics
• philosophy
• deep learning
• mathematics
• physics

Examples already in the plan:

• Fundamentals of Physics by Halliday, Resnick, and Walker
• Introduction to Quantum Mechanics by Griffiths
• Quantum Computation and Quantum Information by Nielsen and Chuang
• Electronic Devices and Circuit Theory by Robert L. Boylestad and Louis Nashelsky
• Operating System Concepts by Silberschatz, Galvin, and Gagne
• Computer Systems: A Programmer’s Perspective by Bryant and O’Hallaron
• The Rust Programming Language
• Deep Learning with Python
• Hands-On Large Language Models

For quantum computing, Cambridge’s page for Nielsen and Chuang describes the book as a comprehensive textbook covering fast quantum algorithms, teleportation, cryptography, and quantum error correction. Pearson’s page for Boylestad and Nashelsky presents Electronic Devices and Circuit Theory as a comprehensive survey of electronic devices and circuit applications. (Cambridge University Press & Assessment)

The rule for books:

A book is not completed when it is read. It is completed when its ideas have been solved, built, derived, tested, explained, or applied.

Tier 4 — Roadmaps and Community Guides

Roadmaps are useful, but they are not the curriculum.

They help answer:

• What exists in this field?
• What order might topics follow?
• What skills do people commonly expect?
• What am I missing?
• What tools are common?

roadmap.sh is useful because it provides community-created developer roadmaps, study plans, paths, and resources, including role-based and skill-based roadmaps. (roadmap.sh)

But roadmap.sh should not be treated as scripture.

It should be treated as:

A map for orientation, not a substitute for projects, documentation, books, or real practice.

Tier 5 — Tutorials, Videos, Blogs, and Clone Courses

These are useful when they help with momentum, intuition, or practical exposure.

They are especially useful for:

• getting unstuck
• seeing workflow
• learning tool setup
• watching someone debug
• observing project structure
• getting initial intuition

But they are dangerous if they become the main learning method.

The rule:

    Tutorials are allowed only if they lead to an independent build.

After watching a tutorial or clone course, the required next step is:

1. Close the tutorial.
2. Rebuild something similar from memory.
3. Change the requirements.
4. Add missing features.
5. Deploy it.
6. Document what was learned.
7. Explain the architecture. Otherwise, it becomes passive copying.

3. Research-Backed Resource Spine by

Domain This section defines the source spine for each domain.

This is not yet the full detailed roadmap. That comes after this.

This is the researched resource foundation that the roadmaps will use.

DOMAIN 1 — Software Development, Product Engineering, and Design Core Research Sources The software development path should be based primarily on official documentation and production practices.

The key sources are:

• roadmap.sh for orientation
• MDN for HTML, CSS, JavaScript, Web APIs, HTTP, accessibility, and browser technologies
• React official docs for React
• Node.js official docs for backend JavaScript
• PostgreSQL official docs for relational databases
• Git official documentation and Pro Git
• Docker official docs for containers
• Kubernetes official docs for orchestration
• cloud provider documentation later
• testing framework documentation
• security documentation from OWASP MDN is the correct spine for web platform fundamentals because it covers HTML, CSS, JavaScript, HTTP, APIs, accessibility, and related open web technologies. React’s official docs should be used for React itself, and Node’s official documentation describes Node.js as a cross-platform JavaScript runtime suitable for servers, web apps, command-line tools, and scripts. (MDN Web Docs)

For production backend and infrastructure work, PostgreSQL, Docker, Kubernetes, and Git should be learned from their official documentation. PostgreSQL’s documentation tracks current supported versions, Docker’s docs provide getting-started and workflow material, Kubernetes describes itself as a portable open-source platform for managing containerized workloads and services, and Pro Git is available free through the official Git site. (PostgreSQL)

Practical Interpretation Software development should not be learned as “frontend then backend then done.”

It should be learned as the ability to create and maintain systems.

The project ladder should include:

1. Static website
2. Interactive frontend
3. API-backed app
4. Database-backed app
5. Authenticated app
6. Tested app
7. Dockerized app
8. Deployed app
9. Monitored app
10. Scaled app
11. Secure app
12. Multi-service system
13. Real SaaS-style product

The proof is not “I know React.”

The proof is:

I can build a product that survives contact with users, data, failure, deployment, and future changes.

DOMAIN 2 — AI Engineering and AI Research Core Research Sources AI must be split into practical AI engineering and deeper ML/deep-learning research.

The source spine:

• PyTorch tutorials and documentation
• TensorFlow tutorials and documentation
• LangChain documentation for agent/application engineering
• DSPy documentation and paper for programming language-model pipelines
• academic papers
• model cards
• evaluation frameworks
• Hugging Face documentation later
• OpenAI, Anthropic, Google, Meta, and DeepSeek research papers where relevant
• NIST AI Risk Management Framework for trustworthy AI thinking
• UNESCO/OECD resources for responsible AI in education and society

PyTorch’s beginner material introduces a complete ML workflow including data, models, optimization, and saving trained models. TensorFlow’s tutorials recommend Keras for beginners and include basic ML tasks. LangChain describes itself as an open-source framework with agent architecture and integrations, while DSPy describes itself as a declarative framework for modular AI software and “programming—not prompting—LMs.” (PyTorch Documentation)

The AI usage philosophy in this master plan should also be informed by responsible-AI sources. NIST’s AI RMF focuses on managing AI risks to individuals, organizations, and society, and identifies trustworthiness characteristics such as validity, reliability, safety, security, resilience, accountability, transparency, explainability, interpretability, privacy enhancement, and fairness. UNESCO’s guidance for generative AI in education and research emphasizes a human-centred vision and human capacity development. (NIST)

Practical Interpretation AI should be learned in layers.

Layer 1: Use AI tools effectively. Layer 2: Build AI applications. Layer 3: Build agents and RAG systems. Layer 4: Evaluate outputs. Layer 5: Train small models. Layer 6: Fine-tune models. Layer 7: Optimize models. Layer 8: Reproduce papers. Layer 9: Publish experiments.

The proof is not “I can prompt ChatGPT.”

The proof is:

    I can build, evaluate, debug, improve, and explain AI systems.

DOMAIN 3 — Mathematics Core Research Sources Math must be rebuilt systematically.

The source spine:

• Khan Academy for intuition and early repair
• OpenStax for structured textbooks
• MIT OCW for university-level courses and problem sets
• 3Blue1Brown for intuition where useful
• proof-based textbooks later
• problem books
• programming implementations for applied math

Khan Academy’s official mission is to provide a free, world-class education, and its math library covers arithmetic through early college-level material. OpenStax provides free calculus textbooks, and MIT OCW provides rigorous course material such as Mathematics for Computer Science. (Khan Academy)

Practical Interpretation Math should be treated as a skill built through problem-solving.

The ladder:

1. Arithmetic repair
2. Pre-algebra
3. Algebra I
4. Algebra II
5. Trigonometry
6. Pre-calculus
7. Calculus I
8. Calculus II
9. Calculus III
10. Linear algebra
11. Discrete mathematics
12. Probability
13. Statistics
14. Differential equations
15. Numerical methods
16. Optimization
17. Proof

The artifact types:

• solved problem sets
• handwritten derivations
• proof notebooks
• Python visualizations
• algorithm implementations
• mathematical essays
• simulation notebooks

The proof is not “I watched a math playlist.”

The proof is:

    I can solve, derive, prove, model, and apply.

DOMAIN 4 — Physics, Quantum Mechanics, and Quantum Computing Core Research Sources Physics should begin with accessible structure and move toward rigorous university-level material. The source spine:

• OpenStax Physics / University Physics
• Halliday, Resnick, and Walker
• MIT OCW 8.01 Classical Mechanics
• MIT OCW 8.02 Electricity and Magnetism
• MIT OCW 8.04 Quantum Physics I
• Griffiths for quantum mechanics
• Nielsen and Chuang for quantum computing and information
• research papers later

MIT OCW’s 8.01SC introduces classical mechanics, including core concepts such as space, time, mass, force, momentum, torque, and angular momentum. MIT’s 8.02 focuses on electricity and magnetism, and MIT’s 8.04 introduces quantum mechanics through experimental basis, wave mechanics, and Schrödinger’s equation. (MIT OpenCourseWare)

Nielsen and Chuang should remain the long-term quantum computing target because it is a comprehensive textbook covering major quantum information topics such as algorithms, teleportation, cryptography, and error correction. (Cambridge University Press & Assessment)

Practical Interpretation Physics must not become “interesting videos.”

The ladder:

1. Basic scientific reasoning
2. O-Level / high-school physics
3. Algebra-based mechanics
4. Calculus-based mechanics
5. Waves
6. Electricity and magnetism
7. Thermodynamics
8. Optics
9. Modern physics
10. Classical mechanics
11. Quantum mechanics
12. Quantum computing
13. Quantum hardware
14. Research papers

The artifact types:

• solved physics problems
• derivation notebooks
• simulations
• lab-style writeups
• quantum circuit notebooks
• explanations
• paper reproductions

The proof is:

I can derive, calculate, simulate, explain, and connect theory to physical reality.

DOMAIN 5 — Electrical and Electronic Engineering Core Research Sources EEE must be practical from the beginning.

The source spine:

• Electronic Devices and Circuit Theory by Robert L. Boylestad and Louis Nashelsky
• circuit theory textbooks
• All About Circuits textbook
• KiCad documentation
• LTspice documentation
• datasheets
• application notes
• microcontroller documentation
• semiconductor device resources
• PCB manufacturer design rules

Pearson describes Boylestad and Nashelsky’s Electronic Devices and Circuit Theory as a comprehensive survey of electronic devices and circuitry applications. KiCad’s documentation describes it as an open-source suite for schematics, PCB design, and associated part descriptions. Analog Devices describes LTspice as a high-performance SPICE simulation tool with schematic capture and waveform viewing for analog circuit simulation. (Pearson)

All About Circuits is also useful as a free multi-volume electronics textbook covering electricity and electronics. (All About Circuits) Practical Interpretation EEE must be learned through a loop:

1. Theory
2. Simulation
3. Breadboard
4. Measurement
5. Debugging
6. PCB
7. Documentation
8. Iteration

The artifact types:

• SPICE simulations
• breadboard circuits
• measurement logs
• oscilloscope screenshots
• KiCad schematics
• PCB layouts
• BOMs
• datasheet notes
• embedded systems code
• teardown reports

The proof is:

    I can design it, simulate it, build it, measure it, debug it, and explain it.

DOMAIN 6 — Cybersecurity Core Research Sources Cybersecurity should follow your stated path, but reinforced with authoritative sources.

The source spine:

• Hack The Box Academy Penetration Tester path
• HTB CPTS
• OffSec PEN-200 / OSCP
• OWASP Web Security Testing Guide
• OWASP Top 10
• PortSwigger Web Security Academy
• real bug bounty program rules
• CVE/NVD references later
• responsible disclosure policies

HTB describes CPTS as a highly hands-on certification assessing penetration testing skills, and its Penetration Tester path includes fundamentals and modules such as network enumeration with Nmap. OffSec describes PEN-200 as its foundational pentesting course for learning and practicing techniques toward OSCP/OSCP+. OWASP’s WSTG is a comprehensive guide to testing web applications and web services, and PortSwigger’s Web Security Academy is free training for web application security. (academy.hackthebox.com)

Practical Interpretation Cybersecurity should be learned legally and professionally.

The ladder:

1. Linux and networking basics
2. Web basics
3. Security fundamentals
4. HTB Academy modules
5. HTB boxes
6. PortSwigger labs
7. OWASP WSTG methodology
8. CPTS
9. OSCP
10. Bug bounty
11. Tool creation
12. Research/writeups

The artifact types:

• lab notes
• methodology checklists
• exploit writeups
• scripts
• recon templates
• vulnerability reports
• responsible disclosure reports
• defensive recommendations

The proof is: I can find, verify, document, and explain vulnerabilities ethically and professionally.

DOMAIN 7 — Operating Systems, Linux, C, Rust, and Low-Level Programming Core Research Sources Low-level work should be based on books, official docs, and building.

The source spine:

• Operating System Concepts by Silberschatz, Galvin, and Gagne
• Computer Systems: A Programmer’s Perspective
• The Rust Programming Language official book
• Linux From Scratch
• Linux manual pages
• GNU documentation
• POSIX materials where needed
• source code from real open-source projects

Wiley’s page for Operating System Concepts says the 10th edition was revised to remain current with contemporary examples of operating systems. Pearson describes Computer Systems: A Programmer’s Perspective as showing how understanding computer-system elements helps programmers create better programs. The official Rust book is the maintained first-principles path for Rust, and Linux From Scratch gives step-by-step instructions for building a custom Linux system from source. (Wiley)

Practical Interpretation The goal is not merely to know that operating systems exist.

The goal is to build pieces of the machine.

The ladder:

1. Linux command line
2. C fundamentals
3. Pointers and memory
4. Processes and files
5. Shell scripting
6. Systems programming
7. Rust fundamentals
8. Networking
9. Concurrency
10. Memory allocators
11. Shell implementation
12. Filesystem experiments
13. Compiler/interpreter projects
14. Kernel-level experiments
15. Linux From Scratch
16. Open-source contribution

The artifact types:

• shell in C
• malloc implementation
• TCP server
• file parser
• process scheduler simulation
• Rust CLI tools
• toy compiler
• interpreter
• Linux From Scratch build log
• kernel module experiment

The proof is:

    I can build tools and systems at the level most developers only consume.

DOMAIN 8 — Philosophy Core Research Sources Philosophy should be source-driven and essay-driven.

The source spine:

• Stanford Encyclopedia of Philosophy
• Internet Encyclopedia of Philosophy
• PhilPapers
• Oxford Bibliographies
• primary texts
• original papers
• careful translations
• academic lectures where useful

The Stanford Encyclopedia of Philosophy organizes scholars to maintain an up-to-date philosophy reference work. PhilPapers is a comprehensive index and bibliography of philosophy maintained by the philosophy community. Oxford Bibliographies provides authoritative research guides developed cooperatively with scholars. (Stanford Encyclopedia of Philosophy)

Practical Interpretation Philosophy must not be aesthetic consumption.

The ladder:

1. Introductory maps
2. SEP/IEP articles
3. Primary text excerpts
4. Argument maps
5. Mini essays
6. Objections and replies
7. Comparative essays
8. Source-paper reading
9. Philosophy of science links to physics/AI
10. Long-form position papers

The artifact types:

• argument maps
• mini essays
• objection/reply documents
• concept dictionaries
• worldview reflections
• primary text notes
• philosophy of science essays
• long-form position papers

The proof is: My arguments become sharper, my worldview becomes more examined, and my life changes because I understood something.

4. AI Usage Principles

AI should not be used to bypass learning.

AI should be used to improve learning, testing, verification, feedback, and creative exploration.

The external guidance matters because serious AI use is not only about convenience. NIST frames AI risk management around validity, reliability, safety, security, resilience, accountability, transparency, explainability, privacy, and fairness; UNESCO frames generative AI in education around human-centred use and human capacity development. (NIST AI Resource Center)

Therefore, the corrected rule is:

  AI is allowed to accelerate the loop, but not replace the loop.

The loop is:

1. Try myself.
2. Use AI to clarify.
3. Verify from source.
4. Build or solve.
5. Test the result.
6. Explain it in my own words.
7. Publish the artifact.

Bad AI use:

• “Do this for me so I don’t have to understand it.”

Good AI use:

• “Challenge me, review me, explain alternatives, test me, debug with me, and help me verify my work.”

The key line:

  AI may reduce friction, but it must not remove contact with reality.