LOCKEDIN / FORWARD-DEPLOYED ENGINEERING 101
Understand it.
Then build it.
You can be an experienced engineer and still be new to agents. Start with what each thing is and how it helps a person do useful work. Explore 58 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
A place to start.
Choose a short reading route, or look up a concept below.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
Data a program can read and check
What are JSON and schemas?
JSON (JavaScript Object Notation) is a text format for exchanging data between programs. An object pairs field names with values, like a small form with named boxes. JSON Schema describes rules for those values. Neither is an AI model, and JSON works with many programming languages.
An API response, an agent's tool arguments and a model's structured answer often arrive as JSON. Before connecting them, an FDE needs to read the fields, recognize their types and explain why readable data can still be wrong for the task.
UNDERSTAND THE SYSTEM
From a text message to a usable value
A fictional note says Pump P7 is running at revision 3. Follow the response through three different checks. Parsing reads its syntax; field rules and source comparison ask different questions.
Read the connections in plain English
- 01JSON text → Parser
JSON has its own formatting rules. A trailing comma stops this example before any field checks.
- 02Parser → Field rules
The number 3 and the string 3 can look similar, but they are different value types.
- 03Field rules → Compare evidence
Continue only when required fields, their types and allowed values fit.
- 04Source note → Compare evidence
A valid positive revision may still be older than the current note.
- 05Compare evidence → Draft or hold
Report a supported fixture draft or explain the mismatch; do not treat data as an instruction to act.
Check your understanding: If a response is valid JSON, is it ready to use?
No. It may have the wrong shape, omit a required field, cite an old revision or contradict its source. Parsing, validation, evidence and action authority answer different questions.
CONNECT IT TO WHAT YOU KNOW
Start with something familiar.
Think of a small form handed from one program to another. Field names are the labels; values fill the boxes. A schema resembles the form's rules: this box is required, this one needs a number, and this one accepts only a short list of choices.
The form analogy explains structure, not truth. A completed form can contain a false statement. JSON is data, not an instruction to execute; a schema does not verify every claim or grant permission.
Words worth knowing
- Object / property
- An object uses braces to hold name–value pairs. Each pair is a property; its name is a quoted string.
- String / number
- A string is quoted text. A number is unquoted. The number 3 is different from the string "3".
- Array
- An ordered list of values inside square brackets. An array of responses is different from one response object.
- Boolean / null
- True and false are boolean values. Null is an explicit value often used by a contract for no value; it is not the same as leaving a field out.
- Parse / serialize
- Parsing reads text into program values. Serialization turns program values into a format such as JSON text.
- Schema / validation
- A schema declares rules. A validator checks actual data against them; it does not automatically establish factual support or permission.
ONE EXAMPLE / FICTIONAL CASE
Follow the connections.
A fictional maintenance assistant turns a note into four fields: source_id, source_revision, condition and evidence. The program can parse a stopped condition even when the note says running. Reading the data and trusting its meaning are separate jobs.
UNDERSTAND THE SYSTEM
From a text message to a usable value
A fictional note says Pump P7 is running at revision 3. Follow the response through three different checks. Parsing reads its syntax; field rules and source comparison ask different questions.
See what moves and why.
Read the connections in plain English
- 01JSON text → Parser
JSON has its own formatting rules. A trailing comma stops this example before any field checks.
- 02Parser → Field rules
The number 3 and the string 3 can look similar, but they are different value types.
- 03Field rules → Compare evidence
Continue only when required fields, their types and allowed values fit.
- 04Source note → Compare evidence
A valid positive revision may still be older than the current note.
- 05Compare evidence → Draft or hold
Report a supported fixture draft or explain the mismatch; do not treat data as an instruction to act.
Check your understanding: If a response is valid JSON, is it ready to use?
No. It may have the wrong shape, omit a required field, cite an old revision or contradict its source. Parsing, validation, evidence and action authority answer different questions.
Work through it, step by step.
Read the message as a form
Find the outer braces, the quoted field names and the values. Notice which values are text and which are numbers. A JSON document can also contain an array or a single value; this particular consumer expects an object.
What you have now: An ordinary-language explanation of each field.
Separate syntax from field rules
A parser recognizes JSON syntax. The contract then asks which fields must exist and what each may contain. Listing a field under properties does not make it required. Required does that; additionalProperties can restrict extra fields.
What you have now: A readable value that either fits or violates an explicit contract.
Check what the fields mean
Compare the source and revision with the actual note. An allowed word can still be unsupported. No field in this draft authorizes a machine operation.
What you have now: A supported fixture draft or a specific reason to hold it.
FROM RECOGNITION TO REASONING
Change one field. Explain where the checks stop.
- 01
Start with Number or text? Predict the first stop, then inspect the response.
- 02
Remove the quotation marks around 3 and inspect again. Next change 3 to 2 and explain why the stop moves.
- 03
Compare an absent evidence field with null, then a valid-looking stopped condition. Use the source note to explain the difference.
A comparison of syntax, field and source failures, plus one repaired response in the free Python lab.
Compare your reasoning when you are ready
Quoted 3 is a string and fails the integer field rule. An unquoted 2 fits that rule but differs from the current revision. Null is present but not a string; omission fails the presence rule. Stopped is allowed by the shape, but contradicted by this note.
Keep notes in your own working copy. Moving through these cards does not record completion.
TURN THE IDEA INTO USEFUL WORK
You can now go deeper.
JSON gives data a readable structure. A schema gives that structure rules. Evidence and authorization require separate checks. Continue into the full validator lab to work with actual JSON Schema, stricter parsing and your own file.
Academy lessons use your existing training access. Free guides stay open.