hayodea/salmanoff
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

Docs: Update notes on stencils

Browse Source
This commit is contained in:
Hayodea Hekol
2026-06-06 19:21:28 -04:00
parent 986e1833d0
commit 86c036a505
1 changed files with 101 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/design/stencils.md
+101 -89
View File
@@ -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 = <stencil|mathobj|3dobj>
```
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.