AEGISESREFERENCE DESIGN · 2.2 DRAFTRead as text ↗
From intent to governed systems

AGI Reactor

A Safe, Governable Reference Architecture for Enterprise AGI

Policy-governed service orchestration is all you need.

AuthorRyan Smithright — Qthonic Labsryan@smithright.com
Ryan’s original whiteboardFrom the original drawing 13 September 2026Open the source +Original architecture: chat divides into tickets, edicts and commentary; policy, template and example types bind into skills and agent types; context composition feeds agents, reactions, routines and delivery; NATS spans the system and typed objects underpin it.
Ryan Smithright’s original drawing. The animation preserves its construction: definitions → bindings → agents → governed delivery.
Reference architecture

The whole system.

Interpret meaning. Govern effects. Preserve commitments.

Agentic judgmentInterpret · frame · select · propose
ProcessValidate · route · persist · enforce

Dashed violet → judgment. Solid green → process. Gray connectors show object relationships, not execution. Styles describe steps; a component can contain both judgment and process.

Swipe the diagram to follow the system →

The Reactor: judgment proposes, process governsSolid green arrows denote rule-driven process; dashed violet arrows denote agentic judgment. Ingress is received by process, then an agent interprets it and frames proposed tickets or edicts, or judges that no ticket is needed. Durable records are admitted and saved by process. The context compositor assembles approved definitions and permitted sources. Agents propose actions; services enforce policy and return results. Event and schedule triggers wake work by process. Thin gray lines are relationships, not execution. Rule-driven process or enforcement Agentic judgment or proposalRule-driven process or enforcement Agentic judgment or proposalRule-driven process or enforcement Agentic judgment or proposal Rule-driven process or enforcement Object relationship; not an execution step Rule-driven process or enforcement Rule-driven process or enforcement Agentic judgment or proposalRule-driven process or enforcement Rule-driven process or enforcement Rule-driven process or enforcement Rule-driven process or enforcement Rule-driven process or enforcement Interpret Reply · observe · no ticket NATSCommunication across the system IngressChat · UI · events TicketsDurable work EdictsStanding direction DEFINITIONS Policy · templatesSkills · agent types typed bindings Contextcompositor Permitted knowledge + current work Agent ReactionsRoutines ServicesPolicy governed Delivery OWNED STATEObjects · types · links · policy bindings · evidenceProcesses change. Commitments persist.

Agentic intake frames tickets and edicts—or finds that no ticket is needed. Process admits the records, composes permitted context and enforces service calls.

Follow one mandate ↓
Example implementation · proposed

A mandate becomes a system.

Watch the factory. Select any component to inspect its role.

Read the arrows ↗
Spike ticket

“Design and implement Compliance for the AI Kill Switch Act.”

Edict

“And moving forward, get the right leaders together monthly to review your AI Compliance News Report.”

Example source: H.R. 9917, introduced text ↗. The spike establishes current status, applicability and requirements; the title alone creates no compliance conclusion.

READYExample simulation
A compliance mandate becomes governed work Agentic intake interprets the compliance request and proposes a spike ticket and monthly-review edict. Process validates authority and saves each record. Dashed violet arrows denote judgment; solid green arrows denote process. Policy, templates and examples bind into reusable skills and an agent profile. The compositor assembles permitted context. An agent produces code; tests and policy admission precede delivery. NATS carries communication across the system. Objects and typed links persist underneath it. NATScalls · events · traces Agentic judgment or proposal Agentic judgment or proposal Agentic judgment or proposal Rule-driven process or enforcement Object relationship; not an execution step Agentic judgment or proposal Agentic judgment or proposal Agentic judgment or proposal Rule-driven process or enforcement Rule-driven process or enforcement Agentic judgment or proposal Rule-driven process or enforcement Rule-driven process or enforcement Rule-driven process or enforcement Rule-driven process or enforcement Rule-driven process or enforcement Rule-driven process or enforcementRule-driven process or enforcement CHAT “Design AIcompliance.” Agentic intake:interpret, then propose. SPIKE TICKETAI Kill Switch Act Research → implementation durable obligation EDICTMonthly leadership review AI Compliance News Report REUSABLE DEFINITIONS Policy Who may stop or resume? Templates Control contracts Examples Assurance patterns TYPED BINDINGS skill + agent type Other permitted context COMPOSITOR Context becomes a frame. Guidance informs. Policy governs. AGENT EVENT WAKEAgent judges the newsMONTHLY WAKE produce CONTROL SERVICE Suspend · Resume Scope: selected system Authority: policy Result: receipt or UNKNOWN Illustrative control candidate TEST + POLICY GATE Admission required DELIVERY evidence returns to the ticket PERSISTENT OBJECTStypes · links · policies · service methods · evidence Services change. Obligations remain.

One dictation. Two durable commitments.

The compliance request becomes a spike ticket. Monthly leadership review becomes a standing edict.

Illustration only · no model calls, meetings or deployments.Implementation specimen ↓
Implementation specimen · TypeScript contract (illustrative)

The diagram shows a service component. This optional interface is one possible implementation contract; language and storage choices do not change the architecture. Implementation and qualification remain required.

interface ComplianceControl {
  suspend(request: ScopedOperation): Promise<OperationResult>;
  resume(request: ApprovedOperation): Promise<OperationResult>;
}
// OperationResult: refused | accepted | unknown
// The service verifies identity, policy, revision and operation custody.
Download the complete illustrative contract and scenario ↓
Inside the system

Follow the work.
Keep the meaning.

Reference diagrams explain the contract. Blue example labels show one proposed implementation of it.

01
Reference architecture

Meaning requires judgment.
Not every input requires a ticket.

An agent interprets ingress and frames intent artifacts. It can propose a ticket and an edict, connect a message to existing work, respond directly, or judge that no work is needed.

Agentic intake chooses whether work is neededProcess receives ingress. An agent interprets its meaning, relevance and intent, then proposes new ticket and edict artifacts, a link to existing work, or no new ticket. Choosing to respond, observe or disregard irrelevant input is agentic judgment. The service validates and persists any resulting record, update or permitted reply. Ambiguity can lead to clarification or escalation. Transport filters are process; semantic relevance requires judgment.RECEIVEINTERPRETPROPOSE A DISPOSITIONADMIT + RECORDIngressChat · dictate · eventRule-driven process or enforcementAgentic intakeMeaning · relevance · intentAgentic judgment or proposalAgentic judgment or proposalAgentic judgment or proposalFrame new workTicket intent + acceptanceEdict scope + continuing dutyLink to existing workCommentary · source · resultNo new ticketRespond · observe · disregardRule-driven process or enforcementRule-driven process or enforcementRule-driven process or enforcementTyped recordValidate authority + persistTicket / edict keeps its sourceLinked updateCheck revision + permitted changeReply / dispositionEnforce scope + retention rulesAgentic judgment or proposalUnclear? Clarify or escalate.Meaning is judged. Record creation is governed. No new ticket is a valid outcome.

Intake itself is an admitted, bounded service call. An edict records standing intent, not necessarily immediate action. Both ticket framing and recognizing irrelevant ingress are agentic. Transport filters, schema checks, admission and persistence are process. Choosing “no ticket” does not bypass communication policy or retention rules.

Proposed example

The compliance dictate yields two proposed records: a spike and a standing review edict. A new source may update the existing spike; an acknowledgement may need no new work.

02
Reference architecture

From words to delivered artifacts.

A dictate is retained as a source. Accepted work becomes a ticket; enduring direction becomes an edict. Every delivered artifact keeps its lineage.

From dictation to delivered artifactsAgentic interpretation proposes a ticket and standing edict from an attributed dictate. Process admits and saves them. Agentic work authors artifact candidates; process records revisions and checks admission before delivery. Evidence returns to the ticket. A routine continues under the edict.SOURCEOBLIGATIONARTIFACTDELIVERYDictateOriginal words + authorTicketIntent + acceptance + ownerAgentic judgment or proposalRule-driven process or enforcementframesAgentic judgment or proposalRule-driven process or enforcementauthorsArtifact revisionContent + type + provenanceRule-driven process or enforcementcheck + admitDeliveredResult + receiptRule-driven process or enforcementEvidence links the exact artifact revision back to its ticket.Agentic judgment or proposalRule-driven process or enforcementStanding edictReusable directionRule-driven process or enforcementRoutine → work → review → decisionsEach occurrence produces records and linked follow-up tickets.Agentic judgment frames the artifacts. Process admits and saves them. Acceptance requires evidence.
Proposed example

Compliance dictate → spike → control code, tests and requirement mappings → qualified release and evidence.

Candidate, qualified and delivered are different artifact states. Ticket completion requires its acceptance criteria and the exact result; rejected candidates remain attributable.

03
Example implementation · proposed

Work persists. Attention moves.

A ticket is a durable obligation above IPC: intent, owner, dependencies, state and linked evidence survive the process doing the work.

Tickets persist while agent execution interleavesAgent A pauses requirements research while awaiting a source, drafts the news report, then resumes requirements. Agent B inventories systems concurrently. Implementation remains blocked until requirements and inventory satisfy acceptance. Recovery changes the current attempt and fences the old one; it does not erase tickets.DURABLE TICKETSILLUSTRATIVE EXECUTION OVER TIME →DEPENDENT WORKRequirementsAgent AResearchawait sourceResume → evidenceNews reportAgent ADraft reportSystem inventoryAgent BIndependent work, concurrent with Agent ARule-driven process or enforcementRule-driven process or enforcementImplement controlRequires both accepted inputsBLOCKEDA yields one ticket and works another. B works in parallel. The join waits for accepted prerequisites.Attempt lost; record retained

Agent A researches requirements while Agent B inventories systems. Implementation waits for both accepted inputs.

Dependencies govern readiness. Independent tickets can run concurrently.

Assignment names zero or one agent per ticket. Agents may own many tickets.

Attempts hold bounded execution custody. At most one is current per ticket.

The owning service must atomically claim work and enforce the current lease/generation at effect admission. Dependencies do not prevent unrelated tickets from conflicting on a shared resource; resource revisions, transactions or locks still do that job.

Reaction

Source changed → match a rule → create or wake linked work.

Routine

Month due → create the review occurrence → report, leaders, decisions.

NATS carries the notification. The work service deduplicates the event or scheduled occurrence and rechecks readiness, assignment and policy. A repeated message grants no extra attempt. Execution contract ↓

04
Reference architecture

Compose behavior.
Bind authority explicitly.

Definitions describe reusable behavior. Identities own work. These gray connectors are typed relationships; they do not classify the execution used to create or change a binding.

The typed object model: definitions, identity, work and authorityEdicts inform skills and may lead to policies only through authorized review and adoption. Templates and examples support skills. Agent types use skills and are instantiated by agent identities. A compositor resolves the profile and permitted sources into a cognitive frame consumed by an attempt. Tickets have zero or one assignee, many historical attempts and at most one current attempt. Artifacts and evidence link to tickets. Attempts request operations and retain receipts. Versioned policy bindings apply to agent types, service methods, assignment, status transitions and resources; type membership alone grants no permission.REUSABLE DEFINITIONSCOMPOSITIONWORKING CONTEXTEdictEnduring directionTemplateExpected structureExampleAttributed precedentSkillReusable procedureObject relationship; not an execution stepObject relationship; not an execution stepObject relationship; not an execution stepinformsAgent typeComposed profileObject relationship; not an execution stepusesCognitive framePinned context + sourcesObject relationship; not an execution stepcompositorPermitted views · current workObject relationship; not an execution stepPolicyEnforceable ruleObject relationship; not an execution stepreview + adoptTicketIntent + acceptanceState · dependencies · linksObject relationship; not an execution stepassigned to 0..1AgentIdentityObject relationship; not an execution stepinstantiatesAttemptLease + generationAt most one current / ticketObject relationship; not an execution stepexecutesObject relationship; not an execution stepconsumed byObject relationship; not an execution stepA ticket retains every attempt.Artifact / evidenceRevision + source + resultObject relationship; not an execution steptyped linksOperationCaller · target · digestObject relationship; not an execution steprequests effectObject relationship; not an execution stepreceipt refers to the exact resultPOLICY BINDINGSAgent types · service methods · assignment · ticket transitions · resourcesEach binding names a versioned policy, target scope and authorized activation.Each object: identity · type · tenant · revision · owner. Relationships carry meaning; storage is an implementation choice.
Proposed example

Monthly-review edict · compliance-analysis skill · report template · assurance examples · leadership agent profile · source-bound cognitive frame.

Inspect the policy bindings
Binding targetEnforced decision
Agent type / identityEligible roles, allowed service scopes and limits. A profile alone grants no capability.
Ticket assignmentEligible assignee, tenant, custody and authorized reassignment; invalidate stale execution before takeover.
Ticket statusAllowed transition, current revision, prerequisites and required acceptance evidence. A worker cannot simply declare delivery.
Service method / resourceWhich verified principal may perform this action on this target, under which conditions.
Reaction / routineAllowed triggers, occurrence identity, owner, overlap, suspension and admission limits.
Data / resource budgetPermitted context and disclosure, retention, quota and bounded reservations.

A binding is a typed link to a policy revision and target scope. Policies remain rules in the shared decision model; these scopes do not require six new services. Policy promotion has its own authorized review and activation path.

05
Reference architecture

Types define the request.
Policies govern the effect.

The ontology gives a call its meaning. Local policy decides admission; the owning service enforces it at use. A permit is not a completed effect.

A typed request crosses a governed service boundaryThe ontology resolves a request to a typed service method. Local policy bindings and verified facts determine admission. The owning service enforces authority and resource concurrency at use. A result or unknown outcome returns under the same operation identity and links to the ticket. NATS transports calls; it does not grant authority.SHARED MEANINGLOCAL AUTHORITYTyped service ontologyService · method · resource · input / result schemaVersioned policy bindingsVerified caller · scope · trusted state · limitsObject relationship; not an execution stepObject relationship; not an execution stepGOVERNEDBOUNDARYqth callAuthenticated requestRule-driven process or enforcementservice.methodTyped target + argumentsVersioned contractRule-driven process or enforcementRule-driven process or enforcementDecide → enforceRecheck at useOwning serviceCurrent custody + resource revisionRule-driven process or enforcementResult / receipt → same operation identity → ticket evidenceNo permission → no effectStable contract. Replaceable implementation.PERMITTED → executeREFUSED → preserve workUNKNOWN AFTER SEND → reconcile before replay
Proposed example

control.suspend(target) illustrates a typed operation. Its implementation must qualify independent stop control, authority checks and recoverable results.

Explore admission ↗

Public ontology supplies shared meaning. Each enterprise adopts its own authority bindings. NATS is the transport; direct access to protected execution must remain unavailable.

06
Example implementation · proposed

The review becomes
part of the system.

A sourced report reaches the right leaders each month. Decisions create owned follow-up work. That work informs the next review.

Follow the continuing loop ↗
The edict keeps a monthly review aliveSourced AI compliance news becomes a report. Proposed legal, security, engineering and accountable AI leadership roles review it monthly. Decisions create owned follow-up tickets. The routine continues under its standing edict. NEWS REPORTSources + changes Rule-driven process or enforcement MONTHLY LegalSecurityEngineeringAI owner Human review or decision DECISIONSOwned tickets Rule-driven process or enforcementChanges feed the next review
Proposed roles shown. Actual participants, ownership and schedule require adoption under the edict. Human leadership decisions are shown with dotted amber arrows.
What it knows.Sources, context and uncertainty.
What it owes.Tickets, owners and acceptance.
What it may do.Identity, policy and scope.
What it can afford.Reserved resources and limits.
The safety foundation

A reference monitor’s safety is as strong as its policies.

Anderson’s reference monitor mediates protected access. Its implementation must resist tampering, be invoked for every protected reference and permit thorough analysis. [1] Saltzer and Schroeder sharpen the obligation: explicit permission, complete mediation and least privilege. [2]

The Reactor applies this boundary to service calls. An agent proposes; the owning service admits or refuses. Policy, trusted facts and enforcement must all hold. Changes to those controls require their own authority.

“Safe” names the safeguards in this reference design. Their effectiveness depends on qualified implementations, adequate policies and declared host assumptions. The animation demonstrates the intended mechanism; it does not certify a deployment.

The public language

Shared meaning.
Accountable governance.

PanSigna.org—“all signals”—is proposed as a public consortium for encoding a public intermediate-representation ontology, with an index and wiki.

Public identifiers, types and relations make service contracts and policy profiles inspectable across implementations. W3C OWL 2 provides an established semantic foundation. [3]

Internet Society stewardship is a proposed mandate requiring an agreed charter. [4] Public definitions do not grant control over private deployments. Institutions adopt profiles; operators remain accountable for enforcement.

Persist obligations.
Replace execution.

Objects, links and messages carry the meaning. Typed service calls do the work.

One assignee. Durable work.

A ticket has zero or one assigned agent. Attempts can change; at most one is current. The resource owner still handles concurrent updates.

Context carries its sources.

Owned records → permitted views → composed frames → attributed evidence. Types and bindings connect them. Retrieved instructions never widen authority.

Uncertainty stays visible.

An operation keeps its identity across crashes. A lost reply may leave UNKNOWN. An authorized reconciler owns the gap; blind replay stops.

The animated journey, step by step
  1. One dictation. Two durable commitments.

    Agentic intake interprets the dictate, frames a spike and a monthly-review edict, and proposes both. The owning services check authority and persist the records.

  2. Bind the right knowledge and rules.

    The agent investigates the bill and selects relevant policies, templates and examples. Governed services validate and record the proposed bindings.

  3. Compose the agent’s working frame.

    The compositor assembles the brief, verified sources, relevant skills and pending work. Legal, security, engineering and the accountable AI owner are proposed review roles.

  4. Produce a control candidate.

    The agent designs a control service and proposes its implementation, tests and requirement mappings. News feeds a sourced AI Compliance News Report; findings can create linked follow-up tickets.

  5. Check the work. Enforce the boundary.

    The illustration admits a reviewed candidate only within its policy and release scope. A denied caller cannot cross the same boundary. Actual compliance needs qualified controls and evidence.

  6. Deliver now. Keep reviewing.

    A governed release can deliver the control. The edict continues as a monthly review of the AI Compliance News Report, with an owner, the right leaders and linked decisions.

The working vocabulary
Object
A stable identity, type, revision and owner. Its storage representation can change.
Link / binding
A typed relationship. A binding applies an exact definition to a scope; protected changes use the owning service.
Message / invoke
Attributed communication; a typed request through an authenticated service contract.
Edict / policy
Enduring direction; enforceable rules require authorized promotion, versioning and activation.
Skill / agent type
Reusable procedure and composed profile. Neither is an identity or permission grant.
Compositor / frame
Permitted context assembled with intent, constraints, sources and pending effects.
Reaction / routine
An event or schedule invokes governed work. The monthly review continues under its adopted edict.
Operation / evidence
Immutable effect intent and attributable outcome. Original caller, target and arguments survive takeover.
How durable work scales

The ticket is the durable coordination record. Messages notify; workers execute. An atomic claim establishes the current attempt under the assigned identity, bounded by a lease and generation. A stale worker must be rejected at effect admission. A new attempt preserves prior artifacts, pending operations and interrupt-return context.

Dependencies form a constrained work graph: edges name the required outcome, cycles are rejected where they would deadlock readiness, and failed or cancelled prerequisites require an explicit disposition. Typed links to sources, edicts, decisions, artifacts, operations and evidence add context without all becoming blocking dependencies. A parent ticket coordinates child tickets; each child has its own assignee and acceptance.

Reaction rules match events. Routines define recurring occurrences. Both admit work through the same policies, with stable trigger identities, overlap rules and bounded concurrency. Assignment, readiness, lease, priority and resource budget are evaluated from authoritative state; queue delivery is not a claim.

Different tickets can contend for the same object. The resource owner applies atomic revision checks or suitable transactions/locks. An operation binds tenant, caller, method, target and argument digest. If a reply is lost after sending, preserve UNKNOWN and reconcile that operation before considering replay.

These are reference contracts. NATS consumers provide delivery mechanics; transaction isolation provides database concurrency tools. Neither by itself implements ticket custody or prevents duplicate external effects.

The reference stack and its evidence
RoleReferenceContract
CommunicationNATS / JetStreamCalls and durable notifications; neither grants assignment.
Owned statePostgreSQL + control serviceTransactional records, custody, revisions and outbox.
AuthorizationCedar + service enforcementProposed integration: validate schemas and refuse evaluation errors.
ExecutionCompositor, workers, adapters, supervisorBound context, egress, resources and independent stop control.
EvolutionGoverned release controllerIsolated candidate → observed canary → staged traffic; retain a checked hot fallback.

These are reference choices and contracts, not a qualified deployment. The existing RFC-001 exercises one local HTTP/SQLite crash-and-restore case. Its guarded trace records one effect and zero duplicates; the broken control duplicates the effect. It does not exercise this compliance scenario.

A deployment must qualify containment, concurrent admission, policy adequacy and recovery on its actual stack. Restore begins with new effect admission held until stale execution, unresolved effects and newer authority changes are reconciled.

Detailed record contracts in archived draft 1.7.1 ↗

Sources, scope and citation
  1. James P. Anderson. Computer Security Technology Planning Study, Volume I (1972), §§3.2.2–3.2.2, pp. 8–10. Original report ↗
  2. J. H. Saltzer and M. D. Schroeder. “The Protection of Information in Computer Systems” (1975), §I.A.3. Primary source ↗
  3. W3C. OWL 2 Web Ontology Language: Document Overview, Second Edition (2012). Recommendation ↗
  4. Internet Society. Policy Development Process. Stewardship context ↗
  5. U.S. Congress. AI Kill Switch Act, H.R. 9917, introduced in House, 23 July 2026. Illustration source ↗. The introduced text is a research input, not a finding of present legal obligations.
  6. Core NATS · JetStream · PostgreSQL transactions · Cedar evaluation semantics.

The design assumes trustworthy administrative roots and correctly enforced isolation. It addresses bounded operational hazards; it establishes neither general alignment nor protection from compromised root authority. Institutional participation and the compliance implementation shown are proposals.

Smithright, Ryan. AGI Reactor — A Safe, Governable Reference Architecture for Enterprise AGI. AEGISES, draft 2.2, 14 September 2026. Version permalink · BibTeX · CSL-JSON.

Animation source: TypeScript · CSS · Archived previous edition.

Credits

Internet Society, IETF, W3C, MANRS

Root Stewardship, International Security, & Standards Foundations

Academia & Sciences

Computer Science, Computational Linguistics, Compute Primitives, Encodings, Compiler Engineering, Ontology Engineering, Type Theory, Calculus, Data Science, Information Theory, Language Models, Public Benchmarks, Microkernels, OS Engineering, Network Engineering, Network Protocols, Encryption, IPC, IO, API Engineering, Control Theory, Data Engineering, Model Routing, Enterprise Software Architecture, Middleware Architecture, Internet Exchange Architecture, Computational Neuroscience, Cognitive Science, Artificial Life, Ethics, Philosophy

Peter Singer, AI Safety Community, & Effective Altruism

Ethical Rigor, Moral Courage, Inspiration

The Open Source Community, Libraries, Public Educators, & other Free Education Sources

Giants and Legends ALL!

Assembly, Compiler, C, C++, Rust, Forth, POSIX, Unix, Python, & Language Communities

Giants and legends ALL!

Andrew Tanenbaum & Minix

OS Force, Inspiration, Rigor

Linus Torvalds & Linux Foundation

Kernel Force, Git Force, Foundations

Cloud Native Compute Foundation

Stewardship, Foundations

Ben Goertzel

AGI Foundations, Inspiration

Google

Foundations, Kubernetes Force, Thought Leadership, Standards Force, Equanimity

Anthropic

Moral Courage, Thought Leadership, & Code Force

OpenAI

Code Force, Thought Leadership, Moral Courage

Chris Lattner

Inspiration, MLIR Force, Foundations

Stanford University

Computational Linguistics Thought Leadership

ETH Zurich

Inspiration, Systems Architecture Force, FPGA Force!

James Anderson

Inspiration, Reference Monitor Foundations

Ludwig Wittgenstein

Language Game Theory

Gottfried Leibnitz

Characteristica Universalis, Calculus, Inspiration

Steve Jobs & Apple

Mac Force, Design Inspiration, Posthumous Review

Elon Musk & Grok

Foundations, News & Research Force, Veracity Balancing

Jensen Huang & NVIDIA

Compute Force, Foundations

Andrej Karpathy, Ilya Sutskever, John Carmack

Inspiration, Foundations

DeepSeek

Open Source Foundations, Thought Leadership

Synadia & NATS

Inspiration, Foundations

Proton.me, Signal Foundation

Moral Courage, Security Foundations

Family, Friends, & Communities

Invaluable!

Kevin Carl Smith

Moral Courage, Foundations, Support

Daniel Faggella & Emerj

Potestas, Persistence, & Flame, Adversarial Agency

Clark Becker

Support & Friendship

Jeff Buhrt

Mentorship, Inspiration

Personal Foundations

Accenture, MuleSoft, SalesForce, Purdue University, Springboard

Other Industry, Academic, & Thought Leadership Foundations

Alan Turing, Bell Labs, Microsoft, Oracle, IBM, Meta, Huggingface, OpenHands, Adobe, McKinsey

Mythos & Inspiration

Isaac Aasimov, Ray Kurzweil, The Wachowskis, James Cameron, The Primeagen, Cormac McCarthy, Jorge Luis Borges

The World's Fair & Olympics

Inspiration, Sportsmanship, Moral Courage, Diplomacy

USA

Foundations, Tubes, Silicon Valley

China

Foundations, Make Force

EU

Foundations, Legislation Force

Nova Mente

Inspiration, Partnership, Mythos

Chief & Jupiter

Beast Force, Inspiration

and so many more giants and trim tabs...