From 86c036a5055416979b3a203f713d29cd18d53c0a Mon Sep 17 00:00:00 2001 From: Hayodea Hekol Date: Sat, 6 Jun 2026 19:21:28 -0400 Subject: [PATCH] Docs: Update notes on stencils --- docs/design/stencils.md | 190 +++++++++++++++++++++------------------- 1 file changed, 101 insertions(+), 89 deletions(-) diff --git a/docs/design/stencils.md b/docs/design/stencils.md index 002398e..cfa7378 100644 --- a/docs/design/stencils.md +++ b/docs/design/stencils.md @@ -1,111 +1,123 @@ -# Stencils +# Stencil Design: -## Overview +Right now, I think we have an attachmentSupport stencil base class, right? -Stencils are an intrin info event data type used by SMO to efficiently -identify and process intrinsic stimuli (postrins and negtrins). Each stim -feature may have a stencil type if it's expected that devices exporting -stimbuffs for that feature can raise intrins. Stencils are derived classes -that provide sparse lists of body spots whose stim feature values have -passed the importance threshold for a particular intrin. +## Opaque, per-stimbuffapi? Or SMO-standardized, per-format? -## Purpose +I think stencils will have to be opaque derived types of that base class, and +each stimbuff api lib will have to export its own derived stencil type, perhaps. -Stencils enable SMO's mind layer to quickly "just know" where an intrin is -occurring on the body. When an intrin is raised, SMO doesn't have to first -scan its percepts to figure out where the intrin is. The stencil -descriptors tell it exactly which body spots are raising it. +Alternatively, since the output data format exposed by a stimbuff is conformant to a qualeifaceapi's expectations, maybe stencils should be decided by SMO and then used jointly between and by the stimbuffapis and the qualifaceapis. I think this is better, actually. So stencils are per-stimbuff data format-specific, and not perstimbuffapi opaque. -This direct information also assists SMO in narrowing down the scope of its -DB searches for methods to handle (increase or decrease) the stimval. For -example, for a negtrin raised from a `negtrin(...)` segment attached to a -nontrin DAP line (e.g. `pcloudLightAmbience` / `pcloudDarkAmbience`), -we don't search DB by trying to -match all possible body spots with their stimvals. Rather, we search for -all the body spots that are described in the stencil. This optimizes DB -searches and also makes negtrin relieving/postrin satisfying searches -more explicit and obviously scoped items of knowledge. The eventual -solution is automatically classified as being a method to relieve/satisfy -intrins at this point on the body and not just hazily generally for "all -over the body". We get to make the new item of knowledge more specific. +## Stencils: where do they fit in, and what are they? -## Format and Allocation Model +Stencils are mentena. They are the result of abstraction and projection. -Stencils' formats are specified and standardized by SMO, as well as the -number of stencils that a stimbuff may deliver at once. But the size of the -stencil allocated by a stimbuff cannot be known by the SMO layer. Only the -stimbuff itself knows how much memory is required to hold a stencil for -describing intrin events that it raises. +When the direction of operation is from quale soup to interpretion/knowledge, +they are produced from the stimframe -- this is abstraction. +When the direction of operation is from a mathobj to the soup in order to +compare an abstract notion to the data in a stimframe, they are created by +artificing a new stencil which satisfies the properties of the mathobj whose +properties need to be compared against the stimframe soup data -- this is +projection. -For example, only the livoxGen1 stimbuff knows the upper bound on how many -sparse descriptors are needed to describe an ambience event, for its current -configuration. Because for example, the stencil memory size is determined -by its nDgramsPerFrame parameter. +I.e: stencils are implexed mental phenomena. They are what Ayn Rand calls, +"Implicit existents", or what conventional AI researchers call "Regions of +Interest". -So SMO must specify the format and number of stencils (for rate limiting) -per stimbuff. But the stimbuff library will determine internally the memory -size required for each stencil. This means that SMO can't pre-allocate and -loan stencils to the stimbuffs. That would be ideal because it would give -total control to SMO over intrin events -- because SMO could reject any -intrin event whose stencil's internal memory doesn't match one that it -previously loaned out. +## Abstraction and projection: -We could probably still enforce this by making the stimbuffs "register" -their stencils with SMO before raising intrins. This would have the effect -of ensuring that SMO can verify that only its permitted number of stencils -have been allocated. Moreover, we also regain the ability to reject stencils -whose internal memory doesn't match the memory of a registered stencil. +Cognition is possible because the body helps the mind to perform its first +abstractions. When intrins occur, the sense organ is aware of where the intrin +is located and what its intensity is, and what ought to be done with the intrin. +The intrin can tell the mind: +* Where its attention ought to be directed (stencil of BodySpots). +* What it ought to do with the intrin (autogoal with reference values to + achieve). +* How to tell when the required operation has been satisfied (comparators + attached to the stencil). -But it's fine because we don't expect the relationship between SMO and -stimbuff libraries to be inimical enough for security measures like that to -be non-negotiable. +In this respect, yet again, it seems like the mind is not in charge of the body. +Rather, the body literally gives the mind missives to fulfill, along with +completion criteria. Nietzsche seems to be correct again: +> The body is a big sagacity, a plurality with one sense, a war and a peace, a flock and a shepherd. +> +> An instrument of thy body is also thy little sagacity, my brother, which thou callest "spirit"- a little instrument and plaything of thy big sagacity. +> +> "Ego," sayest thou, and art proud of that word. But the greater thing- in which thou art unwilling to believe- is thy body with its big sagacity; it saith not "ego," but doeth it. -## n-stencils Intrin-Segment Parameter +## But how ought these things be put together as an abstract data structure? -Where a stim buff supports it, a parameter called `n-stencils` tells the -stimbuff how many stencils it can allocate and deliver to SMO -simultaneously for **intrinsic** delivery. `n-stencils` belongs on the -`postrin(...)` / `negtrin(...)` segment it rate-limits — **not** on the -nontrin qualeIfaceApi params. Postrin and negtrin get independent -budgets. +I understand that the comparators should hold the autogoal's reference values +(which are within the stencil) as their ref operand. -The stimbuff must wait until SMO returns stencils to it via postrinEventRdy or -negtrinEventRdy before delivering new intrin events. Stimbuffs can deliver -as many intrin events as they have stencils for. When all of their stencils -have been given to SMO, they must wait until SMO returns a stencil before -raising new intrins. +I understand that a cologex is a string of comparators, each having its own +reference operand and a var operand as the slot for whatever it will eventually +be compared against. -**Specification:** -- The parameter is specified inside a `postrin(...)` or `negtrin(...)` - segment on a DAP line -- The value is an integer representing the maximum number of stencils - that can be allocated simultaneously for that segment's intrin path -- This parameter controls rate limiting for intrin events -- Stimbuffs must respect this limit and wait for stencil returns before - allocating new ones +### Are mentena the top-level, identity objects? Or are cologexes? + +I guess I just keep thinking that the stencil should be some kind of central +mentenon that holds all of the comparators in an array. But maybe this is wrong. +Maybe we should allow a situation where a single cologex has comparators of +different kinds, and each one may point to different mentena. It will simply +be the case that most of the time, the referent mentena for the comparators +within any given single cologex will usually be a single mentenon. But this may +not be necessary. -**Example (generic shape — names depend on device):** ``` -+idev|my-device - |negtrin(interest-pc=85|n-stencils=4)|someSensoryQuale()|someStimBuffApi() - |livoxProto1()|SERIAL +cologex = collection of comparators; +comparator = reference value + method for comparison; +reference value = ``` -The Livox Gen1 **`pcloudLightAmbience`** / **`pcloudDarkAmbience`** sensory -lines do **not** use `n-stencils`; each emits one `uint32` passband count -per stimframe. If Livox adds `n-stencils` for its intrinsic pipelines, it -would appear inside the `postrin(...)` / `negtrin(...)` segments attached to -the ambience line, not on the ambience qualeIfaceApi itself. +### What does the stimbuffapi give to the mind? -**Invalid (sensory qualeIfaceApi must not carry intrin-oriented params):** -``` -+idev|my-device|pcloudLightAmbience(n-stencils=4)|livoxGen1-pcloud()|livoxProto1()|3JEDK380010Z39 -``` +We have two paradigms for thinking about this, and hitherto we've been thinking +about it as, the stimbuffapi gives the mind a stencil, with a comparator that +allows the mind to use that stencil to determine autogoal completion. -## Notes +Perhaps we should be thinking about it as: the stimbuffapi gives the mind a +cologex with a set of comparators, and those comparators' ref operands happen to +point at this stencil which has been filled with these values that the +stimbuffapi wants the mind to achieve. -The stencil registration mechanism discussed above is not currently -implemented. The current design relies on the cooperative relationship -between SMO and stimbuff libraries, where stimbuffs are expected to respect -the n-stencils limit without requiring explicit registration or validation -by SMO. +So: it's not that the body gives the mind a stencil. Rather: the body gives the +mind a cologex. The cologex encodes ref operands which, if the mind pursued, +would achieve the body's goals. The focus isn't on the stencil, but rather on +the comparators...nay, even more: on the cologex. + +## Cologexes as the top-level pertinence determiners for memory? + +Do we store stencils on HDD for their own sake, as ends in themselves? Or do we +store them for as long as they're attached to a comparator? + +And do we store comparators for their own sake? Or do we store them for as long +as they're instrumentally valuable for achieving an autogoal? + +It seems like cologexes are the root of the knowledge graph, and more than that: +the cologexes constructed by stimbuffapis are the root cologexes of the mind's +knowledge graph? And we can "forget" and evict mentities based on their +relationship to our cologex graph. + +## But still: what do stimbuffapis hand over to the mind in pos/negtrinCInd? + +They hand over a cologex, with a comparator, whose ref operand is a stencil, +which has been filled with reference values that are pertinent to that intrin. +* For a negtrin, the ref values in the stencil will be 0s. +* For a postrin the ref values in the stencil will be INT_MAX or something. + +### And how does the mind use this? + +The only way to answer this is to first figure out what a goal is, relative to/ +within our taxonomy of data structures and notions. Because ultimately, the +stimbuffapi is trying to give the mind a goal -- an auto-generated goal. + +What's the difference between a concept and a goal? Concepts are cologexes that +state the criteria for qualifying to be a member of that concept. We compare +data against the comparators in a cologex to deduce what that data should be +classified as. + +Goals seem to be, at the same time, cologexes, yet something more. + +We need a stencil type that encodes the intrin spots within an [light/dark]ambience stimframe. We also need comparators, but we'll deal with that after. \ No newline at end of file