Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

stopping judgment

This notebook rebuilds AI-C06, an asserted_inference record about the level-2 heat-generation branch; after running it you can see a stopping-rule judgment checked against real analysis on the loaded model, not against the model’s own declaration.

The previous two notebooks built one function, logical carrier, allocation and physical realization for GenerateHeat, then recorded the mechanism selection (AS-C06) and the measure framing (AC-C06) that decision raises. This notebook asks what the recursion’s own stopping rule actually shows for this one branch, and states plainly what it does not yet show.

    port def EnergyPort {
        doc /* Carries an energy signal delivered to a heat generator, not
             * committed to any particular energy form. */
        out energy : ISQ::EnergyValue[0..*];
    }

    action def GenerateHeat {
        doc /* Converts a supplied energy input into a thermal energy output.
             * No mechanism, and no energy form, is committed yet: a resistive
             * coil and a gas flame both take some supplied energy and deliver
             * heat, so any device that does this satisfies the function. */
        in energyIn : ISQ::EnergyValue[0..*];
        out heatOut : ISQ::EnergyValue;
    }

    abstract part def HeatGenerator {
        doc /* The logical carrier of heat generation, one level below
             * HeatingSystem: performs GenerateHeat and exposes a port for an
             * energy signal, not yet connected to a producer. Named for the
             * function it carries, not for a mechanism: which mechanism
             * realizes it is a selection among alternatives, recorded once a
             * concrete part specializes this carrier. */
        perform action generateHeat : GenerateHeat;
        port energyIn : ~EnergyPort;
        attribute power : ISQ::PowerValue;
    }

    requirement def HeatGenerationReq {
        doc /*
         * A heat generator shall be rated for at least 600 W.
         * This is an engineering performance threshold on a component rating,
         * not yet derived from a stated measure of effectiveness through the
         * energy relation: no supply and no coil are modeled together yet, so
         * there is nothing to derive it from. Recorded openly, not faked.
         */
        subject heatGen : HeatGenerator;
        require constraint { heatGen.power >= 600.0 [SI::W] }
    }

    requirement heatGenerationReq : HeatGenerationReq;

    metadata acC06Tag : ReviewRecordRef about heatGenerationReq {
        identifier = "AC-C06";
    }

    part def ResistanceCoil :> HeatGenerator {
        doc /* An electrically switched resistive element: converts electrical
             * energy to heat by Joule heating. The mechanism selection this
             * specialization commits to is recorded against the alternative
             * it was chosen over, argued from a domain premise about how the
             * two mechanisms work, not from anything the model connects. */
        attribute :>> power default = 800.0 [SI::W];
        attribute resistance : ISQ::ResistanceValue default = 12.0 [SI::ohm];
    }

    metadata asC06Tag : ReviewRecordRef about ResistanceCoil {
        identifier = "AS-C06";
    }

    part rated : ResistanceCoil {
        assert satisfy heatGenerationReq by rated;
    }
    part weak : ResistanceCoil {
        attribute :>> power = 400.0 [SI::W];
        assert not satisfy heatGenerationReq by weak;
    }

Rooted at HeatingAssembly, not Toaster: the only root that reaches heatGen and its type, HeatGenerator.

Loading...

HeatGenerator, EnergyPort, HeatGenerationReq, ResistanceCoil, rated and weak loaded without error, and the diagram confirms HeatingAssembly composing heatGen, typed by HeatGenerator. The next cell checks what happens when an inference record’s own required field is left empty.

Validation errors for empty-premises record: ['asserted_inference requires at least one premise (Hawkins §3.1)']

With the negative control confirmed, the next cell gathers the real analysis this chapter’s stopping judgment is checked against, not the model’s own declaration cited back at itself.

Perform relationships: [{'performer': 'ToasterDemo::ToastingSystem', 'action': 'ToasterDemo::ToastBread'}, {'performer': 'ToasterDemo::HeatingSystem', 'action': 'ToasterDemo::ApplyHeat'}, {'performer': 'ToasterDemo::HeatGenerator', 'action': 'ToasterDemo::GenerateHeat'}]
Allocations: [{'id': 'ToasterDemo::Toaster::heatAllocation', 'type': 'AllocationUsage', 'ends': [['ToasterDemo::ToastingSystem::toastBread', 'ToasterDemo::ToastBread::applyHeat'], ['ToasterDemo::Toaster::heating']]}, {'id': 'ToasterDemo::HeatingAssembly::heatGenAllocation', 'type': 'AllocationUsage', 'ends': [['ToasterDemo::HeatingSystem::applyHeat', 'ToasterDemo::ApplyHeat::generateHeat'], ['ToasterDemo::HeatingAssembly::heatGen']]}]
heatGenerationReq(rated) = True, heatGenerationReq(weak) = False

The same HeatingAssembly interconnection, re-rendered here as AI-C06’s own evidence base, grounding the judgment in a picture at the point it’s assembled.

Loading...

HeatGenerator performs GenerateHeat, heatGenAllocation points from applyHeat.generateHeat to heatGen, declared inside HeatingAssembly where both resolve, and the requirement evaluates True on rated and False on weak, the deliberately failing candidate. The next cells build AI-C06 directly from these results, following the construction zone Hawkins’ taxonomy uses.

Before AI-C06 states its claim, the next cells give it a real anchor in the model: a ReviewRecordRef tag naming HeatingAssembly::heatGen as what AI-C06 is about.

metadata aiC06Tag : ReviewRecordRef about HeatingAssembly::heatGen {
    identifier = "AI-C06";
}

This fragment is the same text now committed in models/ch06-cumulative.sysml onward, alongside the ReviewRecordRef definition (carried forward since Chapter 2) and the acC06Tag/asC06Tag tags (notebook 02); loading the cumulative model (the model.ok cell above, unchanged) is what makes this a real, checkable tag rather than an assertion the reader has to trust.

AI-C06 states the claim next: what the stopping rule actually shows for HeatingAssembly::heatGen, condition by condition.

GenerateHeat is a real, specified behavior: HeatGenerator performs it and is allocated the nested step, not merely declared syntax. energyIn is a declared, typed connection point on HeatGenerator, not yet wired to a producer. heatGenerationReq evaluates against two real candidates, rated (True) and weak (False), a genuine satisfaction check on an underived threshold, not an unevaluated assertion.

The standard this claim is checked against: the recursion’s own stopping rule, applied one level down.

Per the recursion's own stopping rule, a leaf performs its specified behavior, connects through its specified interfaces, and has verification evidence. At this level: GenerateHeat is a specified behavior, allocated to HeatGenerator (met). energyIn is a declared, typed connection point, not yet connected to any producer (partially met, not complete). heatGenerationReq evaluates on two real candidates against a threshold that is itself not yet derived (partial evidence, not full verification).

What the claim takes as given: the two judgments this chapter already recorded, and the two from earlier chapters this branch still rests on.

["GenerateHeat's own energy input is bound to ApplyHeat::energy, printed as part of APPLY_HEAT_INCREMENT and loaded successfully in notebook 01; this does not by itself mean energyIn is wired to any producer."]

evidence_refs points at the three results gathered above; rationale connects them to the claim, condition by condition.

Performs: real, not merely declared. HeatGenerator performing GenerateHeat and heatGenAllocation both appear directly in perform_relationships and find_allocations above, not just in the source text, the same performer-and-allocation split Chapter 5 established one level up. Connects: energyIn is declared and typed, the interface point the stopping rule names, but it is not wired to any producer, so this condition is only partially met. Verified: heatGenerationReq is genuinely evaluated, not left as an unevaluated assertion, on two real candidates, one passing and one deliberately failing for a reason about the design; but its own threshold is not yet derived from any stated measure of effectiveness (AC-C06), so this is partial verification evidence, not a completed check.

The challenge: what this branch does not yet establish, stated plainly rather than folded into a premature completeness claim.

energyIn has no producer wired to it: no supply or wire component exists in this model, so the interface point is declared, not yet connected end to end, the same partial state Chapter 5 left ApplyHeat::duration in before that chapter built its own port connection. HeatingAssembly is not yet composed into any Toaster candidate: Toaster::heating is still typed by the abstract HeatingSystem, so no full toaster candidate contains a resistance coil yet. The 600 W threshold is not derived from any stated measure of effectiveness (AC-C06); it is a free-standing engineering figure. This branch addresses only GenerateHeat's own energy-to-heat conversion: ApplyHeat's other flows (bread, duration, toast, delivered, loss) are not decomposed or accounted for at this level. This is a deliberate one-branch worked example of one of ApplyHeat's own flows, the same kind of honestly scoped choice Chapter 4 made for ApplyHeat itself out of Douglas's roughly fifteen functions, not a claim that Chapter 6 finishes ApplyHeat's full decomposition.
Whether GenerateHeat needs further decomposition of its own, whether HeatingAssembly is ever composed into a real Toaster candidate, and whether ApplyHeat's other flows (duration, bread, toast) get their own level-2 branches, are open for whichever chapter takes them up.

With every part named above, the record assembles from them directly.

Model tag: {'tag': 'ToasterDemo::aiC06Tag', 'identifier': 'AI-C06', 'annotated_element': 'ToasterDemo::HeatingAssembly::heatGen'}
Validation errors: []
Premises: ['AC-C06', 'AS-C06', 'AS-C03', 'AI-C04']

The tag printed above is now part of the loaded model, and validate_record confirms the Python record and the model’s own tag agree about what AI-C06 is actually about; the same empty error list confirms the Hawkins 3.1 schema’s required fields, including a non-empty premises list, are present and checked, not merely printed.

The model built across this chapter’s notebooks, including this one’s own anchor addition, loaded without error, and the evaluated results above, not the model’s own declaration, are what this stopping judgment cites.

Try the chapter exercise in exercises/ch06/exercise.ipynb: record the two judgment sites your own BrewReq requirement raises (AC-C06-EX, a measure-framing judgment; AS-C06-EX, a mechanism-selection judgment for Impeller), then write an AI-C06-EX stopping judgment honestly scoped exactly like this notebook’s own AI-C06 — not a claim that your BrewUnit decomposition is complete — with premises referencing the real chain this branch rests on: AC-C06-EX, AS-C06-EX, your Chapter 3 exercise’s AS-C03-EX, and your Chapter 4 exercise’s AI-C04-EX.