LanterninaActivities in a real room, with a parent steering
Language: English

A project built in one house. The code, the measurements and the open problems are public.

Source on GitHub ↗

Requests, state and model calls

Execution and data flows

The hub coordinates devices and activity timing. The cloud API handles model calls. Returned sheets and photographs of visible work provide input for the next step.

Who asks whom

Devices sit around the home and communicate with the hub over the local network. Battery-powered displays use Wi-Fi; the hub can stay out of sight. Arrows represent data exchanges, not cables. The hub initiates requests to the cloud and receives parent decisions in subsequent responses.

Who asks whomThe hub connects local devices to the cloud API. The API calls models on Microsoft Foundry through the model router and screens generated text with Content Safety. The hub retrieves parent decisions in response to its requests.The houseCloud servicesFamily browsersparent decisions · portal photographsHTTPSe-paper displaysbattery · Wi-Fia buttonanswered in the replyHubmini-PC on the home networkout of sight · fixed power supplyprinter · scanner · camerapages and photographsvia Wi-Fia pressvia local networkcloud APIpending decisions and photographsmodel routerthe only module allowed a model SDKMicrosoft Foundrylanguage · vision · imageContent Safetychecks generated textscheduledHTTPS requestdecisions inthe response
The hub initiates cloud requests and receives decisions in the response. The API calls Foundry through the model router and separately calls Content Safety to screen generated text. Foundry does not call the safety service.

The models run on Microsoft Foundry. Reading a sheet therefore requires cloud connectivity.

The life of an activity

An activity is a graph of steps called moments, with duration options, help and paths to the ending. The hub follows its transitions as time and returns change. A planned ask requests a continuation from the cloud API using the reading of returned material; other transitions continue through the existing plan.

The life of an activityThe hub requests an activity. The cloud API generates, validates and screens it, then waits for parent approval. The hub retrieves approved activities. A returned reading selects a moment or requests a checked continuation without another parent approval.The hub requests an activitypreferences · optional briefA model writes the whole activitymoments, help and ending pathsFormat, checks and safetyblocking checks before storageThe API awaits approvalthe parent reads the activityThe hub starts the activityif enough scheduled time remainsThe hub executes a momentinstructions · pages · responsesWhat came backmarks, or blankThe activity concludeswith its planned endingaskthe hub sends the material readingthe API checks the continuationwithout a second parent approvalpassesapproved; next hub pollit closesrepairthe next momentaska continuation, in the same format
The left return edge covers permitted format and structural repairs only. A Content Safety refusal blocks the result. The right return edge is a planned continuation based on returned material. The hub's timer can also start the ending without receiving a return; that time-driven path is not drawn here.

Generation permits one format repair and a separate repair after validation; continuation has no repair. The hub respects the schedule and daily activity limit. It starts the ending path at its first timer check within thirty minutes of the scheduled end. Consecutive moments that collect no response advance without waiting for their declared durations.

The paper round trip

The parent assigns the return function to cameras and scanners. At each collection moment the hub chooses one compatible assigned device, names it on the display and keeps that choice until the return ends. Paper can use either kind; constructions and objects require a camera. A scanner press does not acquire a page while the moment is waiting for a photograph.

The paper contains only the page a person reads and writes on. The vision call compares the returned scan with the original image, so the page needs no machine-readable registration layer.

The paper round tripAn image model draws the page from screened text. The hub prints it and keeps the original image. A camera or scanner captures the returned sheet. A vision model compares both images and describes added marks, if any. The result informs the continuation.Wordsalready through the safety gateOne image callthe whole A4 sheetPrintedthe hub keeps the original imagefor comparison with the returnSomebody writes on itor does notCamera or scannercaptures the returned sheetTwo images to a modeldescribes the added marksmarks · blankdescriptions for continuationdegraded reading: waitstored originalinforms the continuation
The vision model compares the returned sheet with the original image kept for printing. An uncertain reading leaves the activity waiting.

The branch depends on whether marks were added; the descriptions inform the continuation. Retained profile observations and the development exception are described under system memory.

The model-call path

The generation path selects a method, devises the activity, repairs refused format or structure when permitted, and screens the resulting text with Content Safety. The API then stores the activity for parent approval. A separate model rereads it in a background task after the response. That diagnostic judgement can fail or be skipped at the usage limit without removing the stored activity; it is not a blocking approval gate.

The panel sends method names to the model and receives a form and a move. It then requests the complete activity and receives one JSON document. A format refusal returns the original answer for repair. A structural refusal returns the document with the failed checks for one repair attempt. Finally the document text goes to the safety gate.
This diagram covers generation and its conditional repairs, ending with text screening. Its method count and approximate prompt length illustrate earlier research runs, not current service limits. The diagnostic background judge and the calls made while an activity runs are separate.

During execution, image generation draws a page, vision reads returned material and a planned ask generates a checked continuation. A scanner comparison also schedules a separate observation for profile calibration; photographic reads skip that observation. These calls are not all repeated at every moment.

Objects and portal photographs

An object or construction can be returned without a printed page. The vision model receives one photograph and describes the relevant visible material, rather than comparing it with an original. An uncertain reading leaves the activity waiting.

An invited adolescent can upload a photograph through the portal. The API stores it; the hub retrieves pending photographs on its synchronization cycle, normally every 60 seconds plus network and processing time. A compatible waiting camera moment can receive it through the same reading path. Otherwise the hub archives it or shows it on a display explicitly assigned to photographs. The portal's completed state means the hub finished processing; it does not promise a model response. A disconnected hub leaves it pending.

Officina collects the research notebooks, their saved outputs and iteration reviews. The index includes the historical workbench. These runs use synthetic material and do not trace every production execution.

This site sets no cookies, collects no statistics, and loads nothing from anybody else's server.