{"id":"crg-problem-statement","level":"system","name":"The computation-to-realization gap","shortName":"The realization gap","role":"Defines the problem of carrying a computational intent into a physically constrained machine.","description":"An algorithm can be specified as a function over symbols, tensors or state transitions without saying how a device will store, move, time or verify those states. Realization begins when that specification is given a representation, an architecture, interfaces and measurable acceptance conditions. The same computation can be realized by different circuits and systems, each with different communication, energy, fault and manufacturing boundaries. This lesson makes the gap explicit so the later chip-design steps are understood as transformations of a contract rather than an unexplained jump from software to a finished die.","specs":[{"label":"Boundary","value":"Abstract computation → physical state transitions","context":"A teaching boundary; no single implementation is implied."},{"label":"Required invariants","value":"Meaning, timing, energy, error and interface scope","context":"Each invariant needs a measurable definition before signoff."}],"interfaces":[{"name":"Computation intent","direction":"in","signal":"Function, tensor graph, state transitions and quality target"},{"name":"Realization contract","direction":"out","signal":"Representations, interfaces, budgets and proof obligations"}],"tradeoff":"More detailed contracts reduce ambiguity but increase design and verification effort; an underspecified contract moves risk downstream.","whyAI":"AI systems are useful only when model operations survive the chain into memory, arithmetic, communication, power, cooling and evaluation.","related":["crg-communication-graph","compiler","attention","standard-cell"],"sources":[{"title":"Semi AI Foundry — Communication Theory of Computation Realization","url":"https://semiaifoundry.com/updates/communication-theory-of-computation-realization/"},{"title":"Stanford Encyclopedia of Philosophy — Computation in Physical Systems","url":"https://plato.stanford.edu/entries/computation-physicalsystems/"}],"scale":"Abstract state to physical system; representation boundaries","kind":"theory","mechanism":["State the computation independently of a particular chip implementation.","Choose physical representations with defined noise, timing and energy margins.","Carry those representations through architecture, design, manufacturing and operation.","Measure whether each boundary preserves the required behavior.","Feed failures back into the next design or deployment decision."],"misconception":"A high-level algorithm is not a chip design; realization adds interfaces, budgets, implementation choices and evidence.","check":{"question":"What makes an abstract computation physically realizable?","options":["Naming a semiconductor process alone","A chain of representations and verified interfaces that preserve its required behavior","Increasing parameter count until a circuit appears"],"answer":1,"explanation":"Realization is a chain of constrained transformations and checks, not a single process-node label."},"science":[{"title":"A realization contract","equation":"C_{physical} = (R, I, B, E, V)","explanation":"A useful contract records representation R, interfaces I, budgets B, error model E and verification evidence V. The tuple is a design scaffold, not a theorem that all systems share one format.","assumptions":"The tuple is a conceptual decomposition; each element must be instantiated for a chosen workload and physical boundary."}],"history":[],"prerequisites":["compiler","attention"],"learningObjective":"Explain why an abstract computation needs a typed, measurable path into a physical machine.","workstream":"CRG","visualFamily":"design-flow","engineeringExample":"Trace a matrix multiply from its graph operation to a tile schedule. The operation is unchanged, but layout, data type, memory traffic, arithmetic units, link budgets and acceptance tests become explicit at each boundary.","evidenceNotes":"This lesson presents the CRG framing as Semi AI Foundry research context and separates it from the independently sourced physical-computation literature.","labId":"library","scope":"Use the manufacturing investigation to trace compatible inputs, assembly and operating constraints; no current standalone calculator models this lesson’s full mechanism.","investigationId":"manufacturing","labScope":"Use the manufacturing investigation to trace compatible inputs, assembly and operating constraints; no current standalone calculator models this lesson’s full mechanism."}