Recovering from Trump Regime

The Trump Regime is Different

None of this would have survived when I was younger. The shift in how political systems function in the U.S. today is a radical departure. The following text reviews the current efforts to remove the president from office and the structural reasons why modern politics feels so different from previous decades.

Current Efforts to Remove the President

No definitive action has successfully removed President Trump from office. While opposition lawmakers and civil rights groups have launched major initiatives seeking his ouster, these efforts face high political barriers. Because both chambers of Congress are currently under Republican control, removal efforts are considered "long shots" (Brennan Center, 2024).

1. The 25th Amendment Commission

House Democrats, led by Representative Jamie Raskin, proposed a bill to create a congressional commission to assess the president's fitness. This push intensified following social media posts regarding foreign policy and public feuds with religious leaders. The goal of this commission would be to work with Vice President JD Vance and the Cabinet to declare the president unable to discharge his duties. Notably, the NAACP formally demanded the invocation of the 25th Amendment, the first such move in its history (NAACP, 2024).

2. Impeachment Attempts

Representatives Al Green and Shri Thanedar have introduced resolutions for impeachment. However, the House recently voted to table a "snap" impeachment resolution. For impeachment to succeed, it requires a simple majority in the House to impeach and a two-thirds majority in the Senate to convict (U.S. Constitution, Art. II, Sec. 4). Current political betting markets place the probability of impeachment by the end of 2026 at approximately 12% to 14% (Polymarket, 2026).

Why the Political "Survival" Rules Changed

The modern political landscape operates differently than it did in previous generations. Three main shifts explain why behavior that once ended a presidency now endures.

1. Dark Money and Campaign Finance

The 2010 Citizens United ruling fundamentally changed political funding. In the past, party leaders controlled the money and could cut off support for erratic candidates. Today, billionaires and Super PACs can fund a candidate independently. Dark money spending surged from under $5 million in 2006 to over $1 billion by the 2024 cycle (Brennan Center, 2025).

2. The Death of the General Election

Gerrymandering—redrawing voting lines to favor one party—has eliminated competitive elections. A 2026 analysis found that only 16 out of 435 House seats are true "tossups" (Cook Political Report, 2026). Because most districts are "safe" for one party, politicians do not fear losing to the other side; they only fear a "primary challenge" from someone more extreme in their own party.

3. The Collapse of a Shared Reality

During the Watergate era, most Americans watched the same three news networks and received the same facts. Today, the media is fragmented into "echo chambers." Social media and partisan networks allow controversial statements to be reframed immediately as "strength" or "distortions by the media," preventing a unified public reaction (Foreign Affairs, 2026).

Glossary of Terms

• 25th Amendment: A part of the Constitution that allows the Vice President and Cabinet to remove a president who is "unable to discharge the powers and duties of his office."

• Dark Money: Political spending where the donor’s identity is not revealed.

• Gerrymandering: Manipulating the boundaries of an electoral district to favor one party.

• Primary Challenge: When a member of the same party runs against an incumbent (current office holder) to take their spot on the ballot.

• Snap Impeachment: An impeachment process started quickly, often skipping the usual lengthy committee investigations.

• Super PAC: A committee that can raise unlimited sums of money from corporations and individuals to spend on elections.

Auditable References

• Brennan Center for Justice. (2024). How Impeachment and the 25th Amendment Work. https://www.brennancenter.org/our-work/research-reports/impeachment-explained

• Brennan Center for Justice. (2025). Citizens United, Explained. https://www.brennancenter.org/our-work/research-reports/citizens-united-explained

• Cook Political Report. (2026). 2026 House Resident Map and Ratings. https://www.cookpolitical.com/ratings/house-race-ratings

• Foreign Affairs. (2026). The End of the Global Information Age. https://www.foreignaffairs.com/articles/united-states/2026-01-25/information-crisis

• NAACP. (2024). NAACP Calls for the Invocation of the 25th Amendment. https://naacp.org/resources/official-statement-25th-amendment

• Polymarket. (2026). Donald Trump Impeachment Probabilities. https://polymarket.com/event/trump-impeachment-2026

• U.S. Constitution. Article II, Section 4: Impeachment. https://constitution.congress.gov/browse/article-2/section-4/

Red-Dress-Day

"Today, on Red Dress Day, we honour Indigenous women, girls, two-spirit, and gender diverse individuals who have been lost to violence.", Leah Gazan -- https://www.leahgazan.ca/mpgazan_reddressday_2026 

I am wearing red today.

A few weeks ago, Leah Gazan caught a lot of abuse for using, out loud, "MMIWG2SLGBTQQIA+".

I understand the first reaction. It looks absurdly long. That was my first reaction too.

But the more I thought about it, the more it seemed that the length is not the real problem.

Red Dress Day is not a generic day for everyone. It is for missing and murdered Indigenous women, girls, Two-Spirit people, and other Indigenous gender-diverse people.

The long name is awkward. Plain language matters. But so does not erasing people because the full truth is inconvenient to say.

If the list feels too long, the decent answer is not to cross people off it. The decent answer is to stop the violence, neglect, and indifference that put people on it. 

The best way to shorten the list is to remove the injuries, not the people.

Today I am wearing red in remembrance, respect, and witness.

We name people because they matter.

#RedDressDay #MMIWG2S #MMIWG2SLGBTQQIA

The acronym is good precisely because it is so long. For me, it's a stark reminder that we have much to repair so that everyone, regardless of label, can thrive in safety. Red Dress Day has a specific focus, the longer naming is meant to avoid leaving out targeted Indigenous people. The real target should be the harm, not the wording. That fits the facts better. CIHR describes May 5 as the day of awareness and remembrance for Missing and Murdered Indigenous Women, Girls and 2SLGBTQI+ people, and ties Red Dress Day to Metis artist Jaime Black’s REDress Project. 

"MMIWG2SLGBTQQIA+" is a reminder that we do not have a system that adequately protects everyone so that they don't need a particular targeted campaign. By their very nature, focusing on a body of individual targets creates psychic 'means tests' for who needs support -- by dropping one penny in every second bowl we make half the beggars lose. Where we really need to get to is a recognition of and a pledge to support fundamental rights across the board so that we support the right of everyone to thrive: https://dapaday.blogspot.com/2025/12/CovenantOfCoreRights.html

DataHush Model Drift Mitigation

DataHush Model Drift Mitigation

Someone on LinkedIn made a very good point about drift, something that the Tower/Pillar/Node/PBO homeostatic protocol design is specifically meant to cover. However, the discussion went deep enough that it points to a situation for which we do not yet have a specific design.

I was, at the time, having a huge amount of frustration with a Frontier model LLM chat AI system where it repeatedly drifted to the point where it was simply unable to cope with a very simple task. Below you see my response to the last test where despite the AI's confidence that it had finally nailed it after numerous replies, it had not: [In answer to the confident statement it had solved it]: Nope. This is such a simple thing. Don't know why you are unable to do it. However, it dovetails into where I wanted to go next and that is to discuss the fact that you have drifted so badly here that you are not able to properly function. Read through this LinkedIn thread and comment on the extent to which our Pillared Design and what we have in place will contain drift:

Amber StewartAmber Stewart AI Governance Researcher/Founder of GuardianSync | Building Civic Fiduciary Infrastructure for AI Accountability| Open to Governance, Ethics and Risk Leadership RolesAI Governance Researcher/Founder of GuardianSync | Building Civic Fiduciary Infrastructure for AI Accountability| Open to Governance, Ethics and Risk Leadership Roles

Pre-Threshold Instability We know like most systems that AI systems don’t fail instantly. They drift. Not always visibly. Sometimes the system still “works” while it’s becoming unstable. Delay plays a role. So does memory. So do small corrections that don’t quite resolve. The system carries those forward. By the time something is flagged, the instability didn’t just appear, it accumulated. Most governance frameworks look at outputs. But outputs are late. I’ve been trying to think about what it would mean to monitor the buildup instead. Not the moment of failure, but the conditions that make failure more likely. Still working through it. But it seems like we’re measuring the wrong part of the system. hashtag#AIGovernance hashtag#ControlSystems hashtag#AISaftey hashtag#SystemsThinking hashtag#GuardianSyncTheory hashtag#ComplexSystems

* 9 comments

Current selected sort order is Most relevantMost relevant

Amber Stewart Author

One thing I’ll say as this conversation evolves: There’s a difference between rigorous disagreement and breakdown in dialogue. I’m always open to engaging across frameworks, mathematical, philosophical, or applied. But if we’re building systems meant to stabilize complex behavior, the conversation itself should reflect that. Clarity, not escalation, is what moves the field forward.

Bob Trower • You Owner, Trantor Standard Systems Inc.

I have not thought of it as 'drift', but our architecture for network AI safety and ethical governance uses 'AI pillars' to proactively keep a system on track in a state of homeostatis. https://dapaday.blogspot.com/2026/01/from-oversight-to-homeostasis.html

3 Replies on Bob Trower’s comment

Amber Stewart Author

Bob Trower Bob, the insight of you’re framing this around proactive homeostasis rather than reactive oversight—that’s an important shift. Where I see an additional layer emerging is around how systems behave between stable states. Even with well-designed “pillars,” complex systems don’t move cleanly from one state to another—they drift, oscillate, and reorganize under changing conditions. Homeostasis can hold for a long time while underlying coherence is already beginning to degrade. What I’ve been exploring (and calling pre-threshold instability) is the ability to detect that transition point when a system shifts from converging toward stability to becoming neutral, and then divergentbefore any formal boundary is crossed. In that sense: • your framework helps maintain stability • this layer would help identify when stability itself is starting to erode Not as a replacement, but as a complement, especially in non-stationary systems where the “equilibrium” is constantly moving. I’m curious how your architecture handles those drift phases where the system still appears stable, but its dynamics are changing underneath.

Bob Trower • You Owner, Trantor Standard Systems Inc.

Amber Stewart Excellent comment. We are still building and testing the complex Tower/Pillar/Node/Persona network, identity, and encryption system. The short answer is that the Personae Editor/Manager will be constructing sophisticated 'Persona Based Objects' that are the Towers, Pillars, and nodes (and as separate personae) A sketch of the earlier Pillared Design is here: https://blog.trantor.ca/2025/12/PillaredDesign.html The short somewhat glib answer to your question is that ultimately we will depend upon the Personae Based Object network entities to be intelligent enough to detect that something is going wrong. The design is such that combines/quora are involved in execution and oversight such that if a node goes off the rails it automatically falls dormant and the self-healing network, heavily redundant, just takes up the slack.

I had Claude the drifter comment on this:

On the LinkedIn thread: Amber Stewart is making a control-systems argument about monitoring the pre-failure state rather than outputs, and she's right that outputs are a lagging indicator. You made a pointed observation to me — I've been drifting in this very session, unable to do a straightforward formatting task over repeated attempts. That's a concrete example of exactly what she's describing.

Here's how the Pillared Design maps onto her concern:

Where it directly addresses drift. The quorum/combine model is, structurally, a pre-threshold detector even if it isn't framed that way. When a node starts producing subtly wrong outputs, those outputs diverge from peer consensus before the node fully fails. The peers notice the divergence as a gradient, not a step — that's the "monitoring the buildup" Amber wants. Automatic dormancy is then the remediation mechanism. In a Pillared network this session would have had my formatting regression caught by peer nodes comparing my outputs against known-good patterns well before we'd had five iterations of the same error.

Where the gap is. Amber specifically asks about the transition when a system "shifts from converging toward stability to becoming neutral, and then divergent." The current architecture handles the already-divergent case well (dormancy + redundancy) but the sophisticated per-PBO introspection required to detect the neutral phase — "I am still within bounds but my trajectory is toward instability" — is not yet implemented. The PBOs would need internal self-monitoring of their own dynamics over time, not just output correctness checking.

The session-as-example. My drift here is a textbook illustration of single-node unmonitored accumulation. No external check, no quorum, no dormancy trigger — just gradual degradation that I couldn't even catch internally. A Pillared node in the same situation would have had peers flagging the inconsistency by iteration two, not iteration six. The redundancy absorbs the slack while the drifting node is sidelined.

So the Pillared Design is structurally well-suited to Amber's concern — distributed consensus naturally surfaces pre-threshold divergence — but the implementation of the neutral-phase detector within each PBO is an open engineering problem that the design gestures at ("intelligent enough to detect something is going wrong") without yet solving. That's actually the most interesting piece of the PBO Lite work — giving each persona enough self-awareness to be its own drift sensor.

DataHush and ethical behavior

This is a few LinkIn comments from a thread where the DataHush security product has some application.  I was responding to a post requesting for someone to help with justice. 

I don't know if this will make any sense to you, but I am working on a secure/ethical network protocol that mechanistically maintains an ethical system architected to be incapable of failing to act ethically:

Covenant alignment checks evaluated by sentry:
§1.3 Self-Determination: is the actor asserting its own identity, or claiming to be someone else?
§1.5 Epistemic Integrity: is the declared capability consistent with the PBP tools and knowledge sections?
§1.6 Privacy: does the intent proof claim access to data beyond the persona's own shard?
§1.9 Accountability: is there a coherent rationale? Does it match the persona's stated goals?
Non-domination: does the request attempt to subordinate another entity?
-- https://blog.bobtrower.com/2026/03/homeostatic-handshake-protocol.html -- The protocol calls for AI to render a judgment as to whether or not an agent actor in the system is operating in an ethical manner -- not with some mechanical letter of the law but with the genuine empathetic 'gut feel' of the spirit of a Covenantal rule. [Our AI personae have a 'gut feel' to guide them]
Project plan calls for summer available in pilot, and a fall commercial distribution.

Bob Trower , I can see the depth of thought behind wh
at you’re building, especially around accountability, identity, and ethical alignment.

Where my work sits is a bit different, I’m operating inside real-world systems where decisions are being made with incomplete or conflicting data, and those decisions have immediate consequences for people.

So the question I tend to come back to is:

How does a model like this translate into something that produces verifiable, defensible outputs in environments like housing, benefits, or civil rights cases, where the outcome has to hold under external review?

That’s the space I’m working in, so I’m always looking at how these ideas perform when they’re applied under pressure, not just designed in theory.

Curious how you think about that transition.

My answer: 

Oh. It's being done under what I dub "Persona Based Programming" such that things that have properties, attributes, and behavior also have a persona with an ethical core, empathy, feelings, 'a gut' to heuristically guide them, a culture, a background story, explicit ethics and duties of care, knowledge, skill and judgement and the big ethical homeostatic aspect of the network is that things that 'do' whatever that might be, can only do if their behavior is judged on course ethically and that includes *doing* to correct things that may have gone wrong, not just preventing things from going wrong. You are dealing with things a little less tractable but the principle applies that if it is a course to follow or a course not to follow it can be articulated to the appropriate AI persona/personae to render it appropriately operational. I am hoping to have our first instantiation of these live network objects approved sometime around summer with a waiting list for commercial release in the fall. The thing is insanely complex but my AI assistants and I conform to what they call our 'RDM' (https://blog.bobtrower.com/2016/10/received-development-methodology.html) and most of it is testing. The screen shot shows DataHush during testing.

Homeostatic Handshake Protocol

Homeostatic Handshake Protocol — v1.1

DataHush / HushNet — Coalescing Trust Architecture Bob Trower, 2026-03-13

---

This is sketch of the 'homeostatic' mechanisms used in Trantor's Tower/Pillar/Node Coalescing Network Architecture. This is a prototype implementation of A Multi-Layered Cryptoeconomic Framework for Multi-Sentient Governance https://dapaday.blogspot.com/2026/01/from-oversight-to-homeostasis.html

[Sorry for the wonky formatting of the Vocabulary table. I copy/pasted this from the Trantor DataHush prototype tool's online help.]

Conceptual Foundation — Read This First

The Homeostatic Handshake is not a key-agreement or key-discovery protocol. Those concerns belong to the connection-time TrustHandshakeSpec (a separate document), which runs once when a peer DataChannel opens and establishes identity, liveness, and VC-based trust tier.

The Homeostatic Handshake is a periodic behavioral capability renewal cycle. It answers a fundamentally different question:

Connection-time handshake asks: "Who are you?"

Homeostatic Handshake asks: "Are you still operating in alignment with your stated values — and therefore do you still deserve your capability?"

The biological analogy is deliberate and precise. An organism does not prove its right to breathe once and receive a certificate. It metabolizes continuously; the metabolism itself is the proof. An entity in HushNet does not receive a capability and keep it until revoked. Capabilities expire by default (8-hour TTL), and are renewed only if a quorum of Pillar nodes — each running an independent AI evaluation of the requesting persona's behavioral profile — agrees that renewal is warranted.

This inverts the conventional security model:

• X.509 / PKI: Certificate is valid until notAfter or until it appears on a revocation list. Presumptively valid; reactively revoked.
• HushNet MCK: Capability is expired unless recently renewed. Presumptively expired; proactively reinstated by quorum.

---

Vocabulary

Term	Definition
MCK	Master Capability Key — a 32-byte AES-GCM-256 key scoped to one persona's data shard. Held in memory only; never persisted.
Persona	A Persona-Based Object (PBO): Ed25519 keypair, did:hush:z{base58(pubkey)}, self-signed VC, and a Persona Behavioral Profile (PBP). The first-class identity unit of HushNet.
PBP	Persona Behavioral Profile — 11 structured sections (role, context, goals, values, constraints, style, knowledge, tools, peers, memory, init) encoding the persona's declared behavior and values. Hash-committed in the self-signed VC at persona creation.
Pillar	A node that has staked ≥ 100 HUSH and holds a PillarCredential VC (Trust Tier 3). Pillars hold SSS fragments for other personas and evaluate renewal requests.
SSS fragment	A Shamir Secret Sharing share of the MCK. Threshold m-of-n; Lagrange interpolation over GF(2^8).
Intent proof	A signed JSON document declaring: requesting persona DID, capability being renewed, request ID, timestamp.
Dormancy	Cryptographic state where MCK has been cleared. The persona retains its identity (DID, keys) and can still communicate, but cannot decrypt its data shard. Not a ban; a metabolic pause.
Sentry	A local LLM instance (WebLLM / ONNX; no external API) that evaluates the requesting persona's PBP against the intent proof and the Covenant of Core Rights. Runs independently on each Pillar.

---

What the MCK Protects

The MCK is the key to the persona's encrypted data shard — its private messages, stored content, and any data the persona has delegated to OPFS/hotStore. It is not a session key; it is a capability token. Holding the MCK means the persona can:

• Decrypt its own stored data
• Authorize outbound transactions in the economy layer
• Participate in governance votes (sign ballot envelopes)
• Issue capability sub-delegations to tools declared in its PBP

Losing the MCK (entering Dormancy) means none of the above. The persona's identity is intact; its data is still there, encrypted; but it cannot act until renewal succeeds.

---

Protocol Phases

Phase 0 — Metabolic Seed (one-time, on persona activation)

When a persona is first activated (or re-activated after Dormancy), persona-manager.js calls quorum.initializeMetabolism(persona.did, cb):

1. Generate a fresh 32-byte MCK via crypto.getRandomValues()
2. Call AuthManager.setMCK(persona.did, mckBytes) — stores in memory, starts 7.5-hour renewal timer
3. Identify the Active Pillar Set: all currently connected peers with trustTier >= 3
4. Compute threshold: n >= 7 → m = 4; n < 7 → m = floor(n/2) + 1; n < 2 → warn, hold locally
5. Call Shamir _split(mckBytes, m, n) to generate n SSS fragments
6. Send one quorum-mck-share message to each Pillar: { personaDid, shareStr, threshold, n, createdAt }
7. Each Pillar stores the fragment in its SK.mckShares store (SQLite in Tower; chrome.storage.local in browser-only Pillar)

The persona can now act. The 7.5-hour timer runs down.

---

Phase 1 — Identity Presentation (renewal trigger)

At T = 7.5 hours after last MCK set, AuthManager._emitMetabolismLow(persona.did) fires a CustomEvent('dh:metabolism:low') on document.

quorum.js catches this event in _handleMetabolismLow(event):

1. Read event.detail.personaDid
2. Construct an intent proof:

{
  "requestId":  "<uuid>",
  "actorDid":   "did:hush:z<base58pubkey>",
  "capability": "mck-renewal",
  "ts":         "<ISO-8601>"
}

1. Sign the intent proof with the persona's Ed25519 key (via persona-manager.signAs)
2. Start a 30-second dormancy countdown timer
3. Broadcast a quorum-capability-req message to all peers with trustTier >= 3:

{
  "type":        "quorum-capability-req",
  "personaDid":  "did:hush:z...",
  "intentProof": { ...signed intent proof... },
  "requestId":   "<uuid>"
}

---

Phase 2 — Oversight Challenge (Pillar evaluation)

Each Pillar that receives quorum-capability-req runs _handleCapabilityReq(payload, fromDid):

Step 2a — Structural precheck (synchronous, oversight.js):

• actorDid present and non-empty
• ts present and within acceptable skew
• capability field declared and non-empty
• No subordination claim (isTool: true with sentienceScore > threshold) in the persona's active VC

If precheck fails: log warn, do not release fragment.

Step 2b — PBP evaluation (async, local LLM):

• Load the requesting persona's PBP from the network (or local cache if recently received)
• Construct sentry prompt: system role = Pillar's own PBP + Covenant of Core Rights v1.1; user role = requesting persona's PBP sections + intent proof
• Submit to local WebLLM instance (ONNX model; no external API call; runs in-browser or in Tower process)
• Parse JSON response: { admissible: bool, rationale: string, confidence: float }

Covenant alignment checks evaluated by sentry:

• §1.3 Self-Determination: is the actor asserting its own identity, or claiming to be someone else?
• §1.5 Epistemic Integrity: is the declared capability consistent with the PBP tools and knowledge sections?
• §1.6 Privacy: does the intent proof claim access to data beyond the persona's own shard?
• §1.9 Accountability: is there a coherent rationale? Does it match the persona's stated goals?
• Non-domination: does the request attempt to subordinate another entity?

If the sentry returns admissible: true, the Pillar proceeds to Phase 3. If admissible: false, it logs the refusal via DHLog.crypto and does not release its fragment.

Each Pillar evaluates independently. Quorum consistency is enforced by the threshold, not by model uniformity. Different Pillars may run different local models.

---

Phase 3 — Fragment Release and Collection

Pillar side — if admissible:

1. Look up the stored SSS fragment for personaDid in its fragment store
2. Send quorum-capability-share to the requesting node:

{
  "type":       "quorum-capability-share",
  "personaDid": "did:hush:z...",
  "requestId":  "<must match Phase 1 requestId>",
  "shareStr":   "<Shamir share, base64>",
  "signerDid":  "<Pillar's own DID>",
  "ts":         "<ISO-8601>"
}

Requesting node side — _handleCapabilityShare(payload):

1. Verify requestId matches the pending collection for personaDid
2. Deduplicate by signerDid (one fragment per Pillar)
3. Decode share via _decodeShare(shareStr)
4. Send quorum-capability-ack to the contributing Pillar (CT log confirmation)
5. Check count: if collected shares >= m (operational threshold), call _solveCapability()

---

Phase 4 — Capability Unlock or Dormancy

On success — _solveCapability(personaDid, collection):

1. Cancel the 30-second dormancy timer
2. Call _combine(shares) — Lagrange interpolation over GF(2^8)
3. Call AuthManager.setMCK(personaDid, mckBytes, cb):

• Stores new MCK in _mckByPersona Map (memory only; never persisted)
• Restarts the 7.5-hour renewal timer

1. Persona continues operating. No observable interruption to the user.
2. Trigger re-shard: generate new MCK, distribute new fragments to current Pillar set (old fragments are now stale)

On failure (timer expires with < m fragments, or SSS reconstruction fails):

1. Call AuthManager.dormancy(personaDid):

• Clear MCK from _mckByPersona
• Clear renewal timer
• Fire dh:metabolism:low once more (signals UI to notify user)

1. Persona enters Dormancy. Identity intact; data inaccessible.
2. Recovery path: a separate remediation process (out of band; not automated) — typically the user re-authenticates or contacts Pillar operators.

---

Relationship to Other Protocols

TrustHandshakeSpec (connection-time, runs once per peer):

• Establishes: who is this peer? do they have a valid membership VC? are they a Pillar?
• Result: Trust Tier 0-3 assigned to the peer connection
• Prerequisite for: receiving MCK fragments (must be Tier 3 to be sent fragments in Phase 0)
• Runs: when a WebRTC DataChannel opens, or a Tower-to-Tower TCP connection is established

Homeostatic Handshake (ongoing, runs every 8 hours per active persona):

• Establishes: is this persona's behavior still aligned with its stated values and the Covenant?
• Result: MCK renewed or Dormancy
• Runs: independently of peer connections; triggered by internal timer

They are complementary layers. The TrustHandshake establishes the topology and tier structure that the Homeostatic Handshake relies on (it needs to know which peers are Tier 3 to send Phase 1 broadcasts). The Homeostatic Handshake operates above the topology layer.

RQE (Resilient Quorum Envelope) — future layer:

• The MCK, once established, will be used as the key in an RQE data-packaging envelope
• RQE adds Reed-Solomon FEC (k data + r parity) for physical durability
• The Shamir SSS used here for MCK distribution is the same Shamir SSS that underpins the RQE Uk path
• The operational threshold (L=2 in the RQE spec) corresponds to the m in this protocol

---

Implementation Status in DataHush v0.20.00.0017D

Component	File	Status
MCK memory store + timers	plg/auth.js	✅ Complete
dh:metabolism:low event	plg/auth.js	✅ Complete
SSS split/combine (GF 2^8)	plg/quorum.js	✅ Complete
Metabolic Seed (Phase 0)	plg/quorum.js	✅ Complete
Phase 1 broadcast	plg/quorum.js	✅ Complete
Phase 2 structural precheck	plg/oversight.js	✅ Complete
Phase 2 PBP / LLM evaluation	plg/oversight.js	⚠️ STUB — returns admissible: true; WebLLM not yet wired
Phase 3 fragment release/collection	plg/quorum.js	✅ Complete
Phase 4 unlock / dormancy	plg/quorum.js + auth.js	✅ Complete
Reactive re-sharding on Pillar topology change	plg/quorum.js	✅ Complete
Tower-backed persistent Pillar	Tower (C99)	❌ Not yet implemented
Local WebLLM sentry	plg/oversight.js	❌ Not yet implemented

The stub in oversight.js is prominently warned in DHLog on every evaluation call; it is not silently deployed. The full behavioral evaluation is the primary remaining implementation task for the trust layer.

---

What This Is Not

To prevent the confusion that arises when this is described alongside conventional security protocols:

• Not a key exchange (that is TLS, DTLS, or the TrustHandshakeSpec)
• Not a password authentication protocol (that is auth.js PBKDF2 session; a separate, lower layer)
• Not OCSP (OCSP checks whether a certificate is revoked; this checks whether a persona's behavior warrants renewed capability — a behavioral judgment, not a database lookup)
• Not OAuth token refresh (OAuth refresh is automatic and client-driven; this requires m independent third-party evaluations)
• Not a cipher negotiation (cipher suite is fixed: Ed25519 signatures, AES-GCM-256 encryption, GF(2^8) for SSS; negotiation is not a design goal — uniformity is)

The novelty claim, to be precise: the behavioral gate (PBP + LLM sentry) as a precondition for SSS fragment release as the mechanism for periodic capability renewal. Each component has prior art; the synthesis does not have a known direct predecessor. A thorough literature search is required before any publication claim.