The Pleroma is a fixed-size array of exact integers (finite-field arithmetic) that stores a multiset of items. Each item is a key, optionally with flag bits, an ordering and a timestamp. One array answers many queries: counts by key, by flag word, by Hamming distance, joint flag-and-time counts. Key queries refuse past capacity; the others never return a wrong count within the field's range.
The store holds a harmonic transform on the product of these groups (the key cycle, the flag cube, the symmetric group, and the time cycle). A hologram is the transform itself. Each component of the transform is called a harmonic. The store keeps only the harmonics its views need, and each view reads its own slice of the array and nothing else.
The three faces
A Pleroma view is one of three faces of the same array:
Syzygy (the key cycle): key-addressed lookup, counts per key, whole items (key, flags, arrangement, time all together) with signed counts. Refuses past KeyCapacity distinct keys, returning false rather than a wrong answer.
Monad (the order face S_k, 2 ≤ k ≤ 5): counts per arrangement of up to 5 things, even minus odd, superposed reading of arrangement queries. Exact while counts stay within the field's range.
Ouroboros (the flag cube Z_2^m, 0 ≤ m ≤ 16): counts per flag word, items within Hamming distance r of a query, the nearest words, joint counts over flags and time. Exact while counts stay within the field's range.
The operation grid
The Pleroma implements a grid of operations on one exact hologram: 24 cells (8 rungs by 3 faces) plus the relation and charge lattices. Each rung is a family of operations on one face, numbered 1 to 8:
Pair (add items with signed counts, remove them exactly, toggle flag bits).
Identity (look up items by key, read one-hot arrangements, read exact flag words).
Relation (bind two stores so keys add and flags XOR, read exact counts and shares of the match, read parity).
Function (shift all keys, relabel all flag bits, shift all ticks, apply weighted superpositions of these shifts in one pass).
Symmetry (permute keys, conjugate arrangements, square flag words in GF(2)).
Composition (combine key cycles with the Chinese remainder theorem, apply linear bit maps).
Turning (rotate every item on the time circle, apply Markov diffusion, shift register cycles).
All 24 cells of the operation grid are implemented and tested.
The map
The map is the design that came before the code: a grid of 8 rungs (layers of operations) and 3 faces (views of the same array), with every cell a public, tested API. This section shows the map as it stands. Each cell is traced to its evidence (test code, measured result, or specification), and the pyramid below holds all 24 cells and the lid. Source: the Phasor map document, last verified 2026-10-11.
The pyramid is interactive. The same 25 cells are listed in the table further down.
The pyramid: 8 rungs, 3 faces, one lid
Each of the three sides of the pyramid is a face: Syzygy (the key cycle and its signed counts), Monad (the order face, S_k) and Ouroboros (the flag cube, Z_2^m). Each band is a rung, rung 1 at the base. Every grid cell is superposable: its cost is independent of the number of items stored, and mixing different harmonic permutations costs one pass per term. The lid on top is the one operation that is not superposable: a choice made once on reading. Select a cell to read its caption, status and evidence.
Drag to rotate. Hover or click a cell. Keys when focused: arrows move between cells, Shift+arrows rotate, + and - zoom, space pauses rotation, 0 resets.
SyzygyMonadOuroborosLidCOVEREDREAD-TIMEdashed edge: status is not COVERED
Superposition: one store, many items
One Pleroma holds many items at once. Every whole-store operation then applies to all of them in a single pass, and the cost of that pass is independent of the number of items stored. Mixing different harmonic permutations (key scaling, bit maps, conjugation; rung 5) costs one pass per term. The example below is the map document's worked example with its verified numbers: three items with key capacity K = 4, then one kernel of 1x identity plus 2x (flip bit 0, age 1 tick).
1. Three items
Key 10, flags 001, time 0, count 3
1x → key 10, flags 001, time 0, count 32x → key 10, flags 000, time 1, count 6
Key 20, flags 010, time 2, count 2
1x → key 20, flags 010, time 2, count 22x → key 20, flags 011, time 3, count 4
Key 30, flags 100, time 4, count 1
1x → key 30, flags 100, time 4, count 12x → key 30, flags 101, time 5, count 2
2. One store
One array. 9 harmonics per key line (2K+1 with K = 4), 8 flag words, 7 time ticks, 56 flags x time joint cells. Total count: 18
3. Exact reads
kernel = 1x identity + 2x (flip bit 0, age 1 tick)
Count per flag word (bit 0 is the last digit)
6
3
2
4
1
2
000001010011100101110111
Count per time tick
3
6
2
4
1
2
0123456
One kernel pass over the store changed every item at once. Total count 6 + 2*6 = 18. Every flag and time count above is exact. The cost of the pass is independent of the number of items stored.
Flags and times are read from the same array, before and after.
Result of the pass, from the document: total count 6 + 2*6 = 18, the original items plus their flipped-and-aged copies. Flag counts after the kernel: 000: 6, 001: 3, 010: 2, 011: 4, 100: 1, 101: 2. Time counts after the kernel: 0: 3, 1: 6, 2: 2, 3: 4, 4: 1, 5: 2.
Cost, as measured: one 10,464-cell store with 1 to 10,368 kernel elements takes 0.17 to 0.44 ms per call (no trend), while brute force takes 3 ms at 1 element and 1,916 ms at 1,000.
The code behind the worked example
var store = new Pleroma(new HologramShape
{
KeyCapacity = 4,
FlagBits = 3,
TimePeriod = 7,
JointFaces = HologramFaces.Flags | HologramFaces.Time,
});
store.Add(new HologramItem(Key: 10, Flags: 0b001, Time: 0), 3);
store.Add(new HologramItem(Key: 20, Flags: 0b010, Time: 2), 2);
store.Add(new HologramItem(Key: 30, Flags: 0b100, Time: 4), 1);
var kernel = new PleromaKernel(store.Shape);
kernel.Add(weight: 1L);
kernel.Add(flagMask: 0b001, timeShift: 1, weight: 2L);
store.Apply(kernel);
// Now all reads return the exact counts shown above
The capacity rule: 2K+1, and the refusal
A Pleroma with key capacity K stores exactly 2K+1 harmonics per key line. Any store of K or fewer keys is decoded exactly (Berlekamp-Massey / Reed-Solomon syndrome decoding). Past capacity, decoding fails at K+1 keys and returns false instead of guessing: the store never returns a wrong answer. Reading any face (flags, arrangements, times) gives exact counts for all items. Try it with K = 4.
K = 4: 0 keys in the store, 2K+1 = 9 harmonics per key line
123456789
Measured: key recovery is exact at 16 keys (30/30 trials) and refused at 17 and 20 keys (30/30 refusals). Equal-bits benchmark: exact recovery of 64 items at 200/200 trials, and past capacity refused 12,800/12,800 with 0 wrong. The full benchmark is in Measurements.
What the map predicted
The map, drawn in Genesis/08-THE-MANIFOLD.md, predicted a structure of 8 rungs by 3 faces, with every cell a public operation that is superposable (applied in one pass to a whole store). The prediction held. Every cell is a public, tested API, and the lists below give the document's own counts.
Predictions that came true
Syzygy face. Key cycle with signed counts, exact recovery up to K keys, refuse past K. BUILT Tested on 30/30 trials at capacity and 30/30 refusals past capacity.
Monad face. S_k representations (k = 2 to 5), exact arrangement counts, conjugation, composition. BUILT Measured on S_2 to S_5; all 24x24 left-right pairs on S_4 exact.
Ouroboros face. Z_2^m flag cube, exact per-word counts at any load, Hamming retrieval, Boolean predicates via Walsh spectrum. BUILT Tested on m = 0 to 16 bits; 1,515+ predicates exact.
Rung 3, Relation (Bind). Group convolution on the product group (key x flag x arrangement x time), every pair in one pass. BUILT 35/35 across shapes; 715+ multisets exact.
Rung 4, Function. Store as lookup table, shifts as phase in harmonics, time-valued maps. BUILT 37/37 time spectra exact; 60/60 time maps exact.
Rung 5, Symmetry. Key permutation via ScaleKeys (unit = permute, non-unit = gather), bit squaring via Frobenius. BUILT 120/120 unit permutations, 113/113 non-unit gathers, 18/18 Frobenius.
Rung 6, Composition. CRT key pairing, linear bit maps, Hamming syndromes. BUILT 12/12 CRT pairs; 112/112 single-error locations.
Rung 7, Turning. Time diffusion as kernel power, LFSR cycles. BUILT 600/600 diffusion steps exact; periods verified.
Rung 8, Circulation. Relation faces (holonomy, current, frustration) embedded in the store. BUILT 2,176/2,176 loop reads; reversibility exact 200/200.
Superposition itself. All operations are cost-independent mixes. MEASURED One 10,464-cell store with 1 to 10,368 kernel elements takes 0.17 to 0.44 ms (no trend), while brute force takes 3 ms at 1 element and 1,916 ms at 1,000.
Learning tower (Eliminate, Graded). Exact learning via elimination over GF(2) and the Jordan-Wigner tower. BUILT Tested 180/180 for affine rules; all 10 symmetry classes hold their mirrors and current direction.
Where the map needed correction
Rung 2 (Identity), Syzygy: key lookup. The map said "lookup = TryItems (each key one value)." Refined: TryKeys reads every key at once (line h with W^(k*harmonic)); TryItems refuses if any key has more than one (flags, arrangement, time) pair. Both exact up to capacity K, refuse past K.
Rung 4 (Function), Monad: time-valued maps. The map said "one tick per key" was automatic. Corrected: it requires the opt-in TimeSpectrum shape option; default stores stay compact and do not hold time histograms per key. With it, 37/37 tick maps exact.
Rung 5 (Symmetry), Syzygy: key symmetry. The map said "h -> u h" was one operation. Refined: a unit u permutes keys exactly; a non-unit gathers several keys to one. Both work, 2K+1 harmonics sufficient, verified 113/113.
Rung 6 (Composition), Monad and Ouroboros: bit maps (Frobenius, ShiftRegister). The map said "apply any linear map." Clarified: the map must either permute bits (safe with item lines) or be applied with ItemLines = false. It refuses (NotSupportedException) otherwise, 18/18 cases exact.
Not built
P5, wrap detection. An exact check for field-range overflow would require every mutator to keep a mirror store in a check prime. Deferred pending impact analysis.
Key-addressed attention. The key view is a decode that refuses past capacity. It is not similarity search; a similarity function on keys would need a different architecture.
GPU kernel. The Pleroma runs on the CPU. HoloVoxel and other consumers use the CPU codec directly.
All 25 cells as a table
The same 24 cells and the lid as plain text: rung, face, capability, API and evidence, with the status exactly as the map lists it. Every status here is COVERED except the lid, which is READ-TIME.
Cell table (25 rows)
Rung
Face
Cell
Status
Capability
API
Evidence
1 Pair (Logic)
Syzygy
Signed insertion and deletion
COVERED
0 = (+1) + (-1): add any signed count to any key up to capacity K, remove exactly.
Add(item, count), Remove, Subtract(other)
PleromaRungsTests.R1_*: +c then -c zeroes every cell (default + 3 primes), PleromaTests.InsertThenRemove_RestoresExactly, Merge_And_Subtract_*
1 Pair (Logic)
Monad
Binary choice
COVERED
One of two arrangements (S_2): stores read even vs odd exact counts.
OrderSize = 2, Arrangements(), SignBalance()
PleromaRungsTests.R1_*, PleromaOrderTests.SH19_*: S_2 counts exact, superposed via kernel identity and swap
Parity of the integer sum around a loop (product = -1 or +1).
RelationFace.Frustration(loop, tag)
PleromaFinishTests.RelationFace_InsideThePleroma_*: every loop's frustration exact
Lid: The Read-Time Choice
Lid (read-time choice)
Draw one value with probability count/total
READ-TIME
One exact integer draw landing on its cumulative count.
Sample(rng, faces)
PleromaRungs58Tests.Sample_*: every draw r in [0, total) lands on its value; shares uniform 4/4 views
Core operations: Add, Remove, TryKeys, TryItems
Build the store item by item: Add(item, count) with signed counts (positive or negative), Remove to erase one copy. The store accepts any number of items; the key view keeps exactly those with distinct keys up to KeyCapacity, and refuses past that.
Read the store back: TryKeys(out var keys) returns the key, total count, and flag word / arrangement / tick if there is one per key (refuses past capacity); TryItems(out var items) returns the whole items when each key has one value per face factor. Both return false past capacity, never a wrong answer.
Flags, Hamming distance, nearest words
Read exact counts of every flag word: Flags() returns a length-2^m array of the count at each word, within the field's range. Query by Hamming distance: Near(x, r) counts items whose flags differ from x in at most r bits, exact within the field's range. Find the closest words: Nearest(x) returns the near words and their distances.
Bind: compose keys, XOR flags
Bind two stores in one pass: store.Bind(other) applies every pair of items from one store with every item from the other, adds keys (mod the key space), XORs flags, composes arrangements, adds ticks, and multiplies counts. The cost is one matrix product per order representation, not per item pair. A one-item store binds the whole store by that item; a many-item store applies a weighted mix of all those shifts in one pass.
Attend: three reads of one query
The query is a flag predicate (an exact match, a partial match on a mask, or any Boolean function). Attend(query, face) reads the store three ways from one contraction:
Counts per value: the exact count at each matched flag word, arrangement, or tick.
Shares: those counts divided by the total, summing to 1 (equal shares when the total is 0).
Parity: +1 or -1, the sign of the total.
The readout cost is one spectrum (the Walsh transform of the predicate) and one inner product, whatever the number of items.
Key shifting, scaling, and the Chinese remainder
Shift all keys by a constant: ShiftKeys(k) adds k to every key in place, in one pass. Scale all keys by a unit: ScaleKeys(u) multiplies every key by u (a unit mod the key cycle), or gathers several keys to one (a non-unit). Both need the optional CompleteKeys configuration so that every key harmonic is stored. Combine two coprime key cycles: CombineCycles(a, b) joins two stores whose keys are on cycles N_a and N_b, forming every pair of keys into the one key that is the first residue mod N_a and the second mod N_b (the Chinese remainder theorem), in one pass.
Bit maps: Frobenius, shift registers
Apply linear maps on the flag cube: Frobenius(modulus, steps) squares every flag word as a polynomial over GF(2) modulo the given polynomial, exactly and in one pass, any number of steps. ShiftRegister(polynomial, steps) steps every word through a linear shift register. Both work within the field's range and cost one pass.
Exact repair and redundancy
Store reserve keys as empty slot harmonics: ReservedKeys lets Verify detect and Repair exactly rebuild up to r lost or corrupted key-line harmonics. Mirror every cell in a second prime: CheckPrime lets VerifyCheck detect any corruption of one copy. Keep the exact sum of a group of stores: PleromaParity rebuilds any one lost store from the others, with Update(before, after) streaming per write.
Sparse pages
PleromaSparsePage holds exact counts over keys anywhere in [0, 2^61-3] in memory proportional to the keys present. Add, subtract, and draw from it without decode; merge exact. Measured: 183 bytes and 0.4 microseconds per read for one key, about 2.2 KB and under 41 microseconds for 50 keys.
Dense pages
On the optional CompleteKeys configuration, a store is a dense page of up to 4,096 slots in which every slot reads back exactly within the field's range: Count(key) and Counts() give the exact count at every slot in one transform, no decode needed. Build or add a whole page from a count vector in one forward transform: FromCounts and AddCounts. Apply any function of the key to the whole page in one read: CountWhereKey(KeyPredicate). Equi-join two pages exactly in one read: InnerProduct(a, b) sums a's counts times b's on equal keys. Measured: about 0.6 to 0.8 ms to read a whole 3,150-slot page.
Measurements
Equal-bits benchmark: exact recovery vs HRR
Measured against Plate's Holographic Reduced Representations at equal storage (about 2,064 and 2,580 bits, not the registered 7,869), by our benchmark log and test suite (not shipped):
Exact recovery: at 64 items (200/200 trials at both vocabulary sizes) against the best baseline's 95 percent point at 4 items, that is 16x that one baseline point at these budgets only. The registered 7,869-bit point was not run.
Past capacity: the Pleroma refused 12,800 of 12,800 trials past capacity (k = 65 to 96), 0 wrong. Every baseline answered every time (wrong-set rate 1.0); peeling at 2^20 ran 510 trials.
The test used a keys-only CycleHologram (the Pleroma's single-face special case) at two vocabulary sizes (4,096 and 2^20 symbols), 200 trials per capacity point, with both the standard correlation clean-up and a stronger peeling decoder (orthogonal matching pursuit) as the baseline.
Associative recall: exact vs float at equal bits
One configuration, exact arm (K=32, 3,965 bits) vs float arm (d=61 complex, 3,904 bits), equal bits within 2 percent. 256 codebook values, 20 random seeds, null baseline 0.39 percent.
n pairs
exact
float (d=61)
float (d=30, half bits)
2
100%
100%
100%
4
100%
100%
93.8%
8
100%
87.5%
53.8%
16
100%
48.1%
20.9%
32
100%
21.9%
8.0%
64
0 (refuses all)
9.5% (never refuses)
3.1%
The exact store holds O(K) numbers for K pairs and grows with context; the float bundle is fixed size. The exact read here is decode-then-test (not a ShiftKeys read). Recall only, not model quality. A trained model can learn around float noise.
HoloDb
The HoloDb holographic plane uses the Pleroma as its data store. Measured exact in the 65-shape parity run:
COUNT, SUM, MIN, MAX, GROUP BY, HAVING, COUNT DISTINCT: exact.
WHERE, JOIN, any Boolean predicate: exact.
See HoloDb's page for the complete speed and scale numbers.
What it is not
No key-addressed attention. The key view is a decode that returns exact whole items; it reads the key line but returns nothing to a query key outside the capacity. This is not a similarity search on keys; key-addressed attention needs a similarity function, which the Pleroma's finite-field arithmetic does not give.
Capacity limits. A store of capacity K keeps 2K+1 harmonics per key line and decodes up to K distinct keys.
Small-field wrap limits. On a small prime field, weighted queries scale counts by the weight magnitude. On q = 13,879, keep totals times the weight below q/2 (about 6,900) to avoid wrapping.
CPU only. There is no GPU kernel. The Pleroma runs on the CPU with exact arithmetic in a finite field.
Not a float embedding. The Pleroma is not a trainable embedding engine like a transformer. It is a data structure and a set of operations. The continuous phasor bundle is an approximate store for superposition and correlation; the Pleroma is exact.
Exact arithmetic is not faster in general. A Pleroma read costs one or more transforms (on the key, flag, or time dimensions) depending on which views are set. A float-bundle read is one correlation. At equal bits, float reads are often faster; at large loads, both converge (the float bundle's noise dominates, while the Pleroma's decode stays exact). The Pleroma trades speed for exactness and for the multiple views on the same array.
Code examples
All examples compile and run against the current API.
One store, many views
var store = new Pleroma(new HologramShape
{
KeyCapacity = 16, // whole items come back for up to 16 distinct keys
FlagBits = 8, // an 8-bit flag word per item
TimePeriod = 63, // a 63-tick clock (on the default field it must divide 2^61 - 2)
JointFaces = HologramFaces.Flags | HologramFaces.Time, // also store flags x time joint counts (256 x 63 cells)
});
store.Add(new HologramItem(Key: 1001, Flags: 0b0000_0101, Time: 0), 3);
store.Add(new HologramItem(Key: 2002, Flags: 0b1000_0001, Time: 5), 2);
if (store.TryItems(out var items))
foreach (var (item, count) in items)
System.Console.WriteLine($"{item.Key}: flags {item.Flags}, time {item.Time}, count {count}");
// 1001: flags 5, time 0, count 3
// 2002: flags 129, time 5, count 2
long[] perFlagWord = store.Flags(); // exact within the field's range
long near = store.Near(0b0000_0100, radius: 1); // items whose flags differ from 0b100 in at most 1 bit
long[] joint = store.JointCounts(HologramFaces.Flags | HologramFaces.Time);
System.Console.WriteLine($"{perFlagWord[5]} {near} {joint[5 * 63 + 0]} {joint[129 * 63 + 5]}");
// 3 3 3 2
store.Diffuse(stayNumerator: 1, stayDenominator: 3); // each item stays with probability 1/3
long[] perTick = store.Times(); // TimeScale (3) times the exact expected counts
System.Console.WriteLine($"scale {store.TimeScale}: {perTick[0]} {perTick[1]} {perTick[5]} {perTick[6]}");
// scale 3: 3 6 2 4
Keys only: exact multiset
var stock = new CycleHologram(capacity: 8);
stock.Add(CycleHologram.Symbol("apples"), 10);
stock.Add(CycleHologram.Symbol("oranges"), 3);
if (stock.TryDecode(out var items))
{
foreach (var (symbol, count) in items)
System.Console.WriteLine($"Symbol {symbol}: {count}"); // every count is exact
}
Bind
var shape = new HologramShape { KeyCapacity = 8, FlagBits = 4, TimePeriod = 9 };
var store = new Pleroma(shape);
store.Add(new HologramItem(Key: 10, Flags: 0b0011, Time: 2), 3);
store.Add(new HologramItem(Key: 20, Flags: 0b0111, Time: 5), 1);
// Bind with a one-item store
var shift = new Pleroma(shape);
shift.Add(new HologramItem(Key: 1, Flags: 0b0001, Time: 1));
store.Bind(shift);
if (store.TryItems(out var items))
foreach (var (item, count) in items)
System.Console.WriteLine($"{item.Key}: flags {item.Flags}, time {item.Time}, count {count}");
// Keys added (10+1=11, 20+1=21), flags XORed, times added
// 11: flags 2, time 3, count 3
// 21: flags 6, time 6, count 1
Exact parity and flag checks
var store = new Pleroma(new HologramShape { FlagBits = 4, KeyCapacity = 8 });
store.Add(new HologramItem(Key: 1, Flags: 0b0011), 2); // two copies
store.Add(new HologramItem(Key: 1, Flags: 0b0110), 1); // one copy
store.Add(new HologramItem(Key: 2, Flags: 0b0001), 3); // three copies
long[] bitCounts = store.BitCounts(); // exact count of items with each bit set
uint parity = store.FlagParity(); // XOR of every stored word
System.Console.WriteLine($"{bitCounts[0]} {bitCounts[1]} {bitCounts[2]} {bitCounts[3]} parity {parity}");
// 5 3 1 0 parity 7
The Berlekamp-Massey algorithm for finding minimal polynomials.
PinSketch (Talbot et al. 2012) and minisketch (Poinsot et al. 2017), which use the same construction for set sketches.
Plate's Holographic Reduced Representations (1995) and its phase refinement.
Version and licensing
Check the live NuGet listing for the exact package version (EvaluatedApplications.Phasor). This page describes the current feature set, subject to change.
License: Proprietary. Installing and using unmodified copies for internal evaluation and non-commercial development or testing is licensed; commercial, production, or revenue-generating use requires a separate commercial licence. No feature on this page is gated by tier or key; every capability described works identically with or without one. See LICENSE for the full terms.