Read a build as a system
Move from a project name to its components, interfaces, and evidence.
Course lessons · 1 of 5
Identify the responsibilities and limits of the recovered C++ G16 and Rhiannon components.
Useful background: Explain what a result means
Start with boundaries and responsibilities
The recovered C++20 G16 scaffold transforms scalar family activations, blends their outputs, applies a stability gate, and normalizes the result. Separate command-line applications expose steps, rollouts, optimization, and profiling. These are concrete entry points in a particular source revision.
A component list helps locate the implementation; it does not establish that every optional path is complete. The recovered Rhiannon source, for example, describes a CPU correction engine while its SIMD path is a no-op and its Metal path delegates to that placeholder.
Separate architectural capacity from demonstrated capability
The later G16 v3.1.1 design describes sixteen families with five thousand addressable substrate sites per family. Multiplication gives eighty thousand possible sites. That is an architectural count, not a measured count of learned facts, functioning biological neurons, or independent agents.
A useful build explanation records inputs, transformations, retained state, outputs, dependencies, and the evidence for each. Source recovery, successful local execution, and a live distributed deployment answer different questions and should be linked separately.
Inspect a component without overclaiming
1Locate the entry point
Use the Rhiannon build record to find the demo, TwoWayEngine implementation, and focused test sources. Pin the source revision before discussing behavior.
2Describe the numerical responsibility
The component maps parameters through a sigmoid, compares outputs with targets, and applies a squared-error derivative. This is a bounded numerical correction task.
3Record optional-path limits
The source’s GPU-related placeholder does not establish acceleration. A claim of working Metal execution would require a real implementation and an observed run.
Make the idea respond
This small weighted-aggregation component is an example of an inspectable interface: its inputs are component values and weights, its intermediate values are normalized weights and contributions, and its output is a score. Trace those stages here, then apply the same questions to the source build. The lab does not execute G16’s full update pipeline or model its eighty-thousand-site architecture.
Change one input at a time. Predict what should happen, then compare the computed result with your prediction.
Teaching model · computed in your browser
Build a weighted score
Change component values and weights. Watch normalization turn them into a single, explainable score.
vᵢ is a component value from 0 to 1; wᵢ is a nonnegative raw weight. Divide every weight by their positive total before combining the values. These illustrative values are not measurements from a live AI system.
Try this: double all three weights. The normalized weights and total score should stay the same. Then set all weights to zero.
The default worked example is shown below.
Normalize before adding: divide each raw weight by 6. Then S = 0.4 + 0.2 + 0.0667 = 0.6667. Multiplying every raw weight by the same positive factor leaves the result unchanged. Choosing weights expresses a modeling decision; it does not validate what a score means.
| Component | Value | Raw weight | Normalized weight | Contribution |
|---|---|---|---|---|
| Component A | 0.8 | 3 | 0.5 | 0.4 |
| Component B | 0.6 | 2 | 0.3333 | 0.2 |
| Component C | 0.4 | 1 | 0.1667 | 0.0667 |
Your turn.
Try an answer before opening a hint. Feedback will explain the result, and you can practice again.
Interactive practice is loading. The lesson, worked example, and printable questions remain available below.
View printable practice and solutions
Use these questions when studying without interactive controls. Opening a written solution does not earn progress.
A documented design has 16 families and 5,000 possible sites per family. How many possible sites does it describe?
Read the solution
The design describes 16 × 5,000 = 80,000 possible sites.
What does that count establish directly?
- Eighty thousand biological neurons.
- A healthy live federation.
- The stated design’s number of addressable sites.
- Eighty thousand independently verified learned facts.
Read the solution
The arithmetic establishes a capacity count within the documented design.
A recovered Metal function delegates to a no-op placeholder. What should the build page say?
- The build has verified GPU acceleration.
- The CPU component cannot exist.
- The placeholder proves the entire project has no value.
- The accelerated path is not established by this snapshot.
Read the solution
Describe the narrow placeholder limitation without expanding it into unrelated claims.
Which question best begins a system explanation?
- What are its inputs, transformations, retained state, and outputs?
- How impressive is its codename?
- How many animation effects can be added?
- Which claim sounds largest?
Read the solution
An input-to-output account makes responsibilities and dependencies clear.
Follow the original record
Use the definitions you just practiced to read the project’s own notation, assumptions, and evidence.
The ideas to keep
- Map inputs, state, operations, and outputs.
- Read optional implementations before promising them.
- Keep capacity counts distinct from demonstrated capability.
Reading completion is separate from your practice evidence.
Progress is kept in this browser. How learning works