EO Engineering Learning OS
CORE FOUNDATION · F03
Back to map ↑
NON-NEGOTIABLE FOUNDATION · TARGET L3 · 5–7 days
F03

Application fundamentals

Understand enough application behavior to deploy, secure, observe and troubleshoot it responsibly.

01 / CONCEPT MAP

Know what the parts mean.

Learn each concept deeply enough to recognize it, place it in the system and reason about normal and failed behavior.

01

Frontend, backend and API boundaries

Define it · locate it · observe it · explain its failure mode.

02

HTTP methods, status codes and headers

Define it · locate it · observe it · explain its failure mode.

03

REST resources and JSON

Define it · locate it · observe it · explain its failure mode.

04

Dependencies and application server

Define it · locate it · observe it · explain its failure mode.

05

Authentication vs authorization

Define it · locate it · observe it · explain its failure mode.

06

Tokens, sessions and expiry

Define it · locate it · observe it · explain its failure mode.

07

Database connections and transactions

Define it · locate it · observe it · explain its failure mode.

02 / SYSTEM FLOW

Trace it end to end.

Browser→JavaScript request→FastAPI route→Validation→Business logic→SQL transaction→JSON response

For every transition: identify input, output, identity, protocol, state, trust boundary, evidence and owner.

03 / GUIDED BUILD

Build, observe and explain.

Documentation and AI are allowed. The engineer must review every output and demonstrate the result from direct evidence.

  1. 01Trace one request from browser to database
  2. 02Document request and response schemas
  3. 03Add structured error handling
  4. 04Move configuration out of code
  5. 05Protect one route with JWT
  6. 06Record correlation across the request
  7. 07Explain three failure layers
04 / INCIDENT

Login succeeds but protected requests return 401. Inject clock skew, wrong signing secret and malformed Authorization header.

Required investigation

State impact → collect evidence → form competing hypotheses → test the cheapest discriminator → isolate root cause → contain → correct → verify.

Evidence pack

Timeline, relevant logs/metrics, failed assumptions, root cause, correction, verification and one prevention action.

AI ownership

AI may suggest causes and commands. The engineer must explain why each check is safe, what result is expected and how the result changes the hypothesis.

05 / DESIGN CHALLENGE

Defend the decision.

Define application boundaries and contracts that operations can deploy and observe without reading every line of code.

06 / VERIFY, SUBMIT & REVIEW

Submission evidence

Architecture review

  • Explain application fundamentals without relying on memorized commands.
  • Draw the flow and name what crosses every arrow.
  • Identify the most likely, highest-impact and hardest-to-detect failure.
  • Show the evidence that proves the solution works.
  • Defend one security, reliability and cost trade-off.

Definition of Done

  • Acceptance criteria pass
  • Flow is drawn and explained
  • Security implications considered
  • Logs/metrics checked
  • Failure is tested
  • AI output is understood
  • Runbook is reusable
  • Mentor review passes
07 / MENTOR GUIDE

Do not score memory. Score the engineer’s ability to form a model, collect evidence, make a safe change and defend the trade-off.

1 Cannot explain2 Understands with gaps3 Implements and troubleshoots4 Designs and reviews