A governed write-path substrate for enterprise AI execution

Infrastructure for stateful, effectful AI systems that must preserve authority, workflow truth, receipts, evidence, review, replay, and tenant boundaries while real work is performed.

99 repositories | @North-Shore-AI | nshkr.com

nshkrdotcom is the public workspace for NSHKR: a BEAM-native execution stack built on Elixir, OTP, Ash, Postgres, Temporal, and deliberately narrow boundary packages.

Enterprise AI is moving from suggestion to action. The first wave of AI applications helped users draft, summarize, search, and reason. The next wave changes records, coordinates workflows, invokes tools, reconciles systems, collects evidence, escalates exceptions, and asks humans for judgment at the right moments.

NSHKR is built for that transition. Its core execution path is:

intent -> authority -> workflow -> effect -> receipt -> evidence -> projection -> review -> replay

It is not a chat UI, a single agent runtime, or a generic workflow engine. It is write-path infrastructure: the layer where AI proposals become authorized operations and where each operation produces structured, replayable institutional memory.

The platform has one hard constraint: an AI runtime may produce language, plans, code, tool calls, and operator suggestions, but it does not get a direct path to mutate the world. Every consequential action crosses typed context, authority compilation, durable workflow state, lower-runtime dispatch, receipts, evidence, and replayable proof.

Enterprise software usually captures outcomes, not decisions.

A discount field records the number, not why the discount was justified. A contract system records the accepted clause, not the rejected fallback positions. A support tool records closure, not why one resolution path was chosen over another. The record preserves the end state while discarding the institutional judgment that produced it.

AI makes that gap operationally dangerous. As agents begin proposing and performing actions, the system has to capture the judgment around those actions: proposal, correction, policy decision, credential scope, external effect, receipt, evidence, review, and eventual outcome.

Without that substrate, enterprises get automation without institutional memory.

Every AI-mediated action should be able to answer these questions without reading a prompt transcript:

Who asked for this?
What authority did they have?
What workflow was active?
Which external effect was requested?
What actually happened?
What evidence supports the result?
Who reviewed or overrode it?
Can the entire chain be replayed?

In NSHKR, the durable chain is explicit:

Command
  -> OperationContext
  -> ResolvedOperationPlan
  -> AuthorityPacket
  -> GovernedInvocationEnvelope
  -> ExecutionInstruction
  -> EffectReceipt
  -> OperationReceipt
  -> EvidenceRecord
  -> Projection
  -> ReviewCase / Decision
  -> AITrace event DAG

That chain is the product surface. Operators, auditors, support teams, and future automation should be able to query how work moved from request to governed action to observed result.

The repos form a layered execution stack. Each layer owns one class of truth and has explicit boundaries for what it must not absorb.

Product / Operator
  -> AppKit
  -> Mezzanine
  -> Citadel
  -> Jido Integration
  -> Execution Plane
  -> AITrace
  -> Projections / Reviews / Replay

The stack is not a universal application framework. It is a governed runtime substrate for systems where product commands become durable workflow, authorized action, external effect, receipt, evidence, projection, review, and replayable proof.

A product does not call a vendor-specific runtime directly. It submits a product-level command through AppKit using product role references such as :issue_tracker, :runtime, :evidence, or :resource_effect.

Mezzanine records the command, creates an operation context, resolves the product role into a compiled binding, captures a run snapshot, and constructs a bounded operation plan. Citadel authorizes the resolved plan against actor, tenant, installation, capability, side-effect class, credential scope, and policy constraints. Jido Integration resolves the connector manifest and materializes the lower invocation. Execution Plane performs the raw mechanics. The resulting receipt returns upward and is reduced into evidence, projections, review state, and replayable trace events.

The important property is that every step is durable and joinable. Boundary envelopes may denormalize safety fields for local checks, but constructors reject mismatches. That prevents reference drift across workflow, receipt, projection, and replay records.

NSHKR is organized around ownership rather than product features:

• product repos own product behavior and operator journeys
• AppKit owns the public product boundary
• Mezzanine owns reusable operational invariants
• OuterBrain owns semantic context and normalized AI outcomes
• Citadel owns authority and policy compilation
• Jido Integration owns connector manifests, leases, and lower invocation envelopes
• Execution Plane owns raw runtime mechanics and lower receipts
• AITrace owns replayable proof
• StackLab owns acceptance gates and failure drills

The compact version is:

Products own meaning.
The platform owns operational invariants.
Connectors own vendor mechanics.
Execution owns raw effects.
Trace infrastructure owns replayable proof.

Provider choices are allowed as data in product packs, connector manifests, receipts, traces, fixtures, and documentation. They are not allowed to become reusable platform control flow. The invariant is explicit: no vendor noun below its proper boundary, and no generic platform method that secretly delegates to provider-shaped logic.

NSHKR's compounding asset is not chat history. It is governed execution memory.

Each run captures the institutional facts that ordinary software drops:

the proposed action
the authority context
the binding and manifest used
the credential scope
the external effect requested
the lower receipt returned
the evidence attached
the human review or override
the projection update
the causal replay path

Over time, that becomes an enterprise decision graph grounded in actual work. It can answer:

How did we handle this last time?
Which policy allowed it?
Which exception was approved?
Which connector performed the action?
What evidence supported the decision?
Did the outcome validate the action?
What should be done differently next time?

That is the enterprise analogue to the behavioral compounding loops that powered consumer platforms, adapted to enterprise realities: authority, confidentiality, tenant boundaries, credential scope, review, evidence, and auditability.

Enterprise AI systems need real tools: GitHub, Linear, Codex, Slack, Jira, Notion, internal document systems, local deterministic connectors, custom APIs, and future providers that do not exist yet.

A product pack can declare concrete bindings:

issue tracker -> Linear
code host -> GitHub
coding runtime -> Codex
document source -> local deterministic document connector

But reusable AppKit and Mezzanine surfaces operate on product roles, operation classes, manifests, receipts, and projections. Provider mechanics live in connector packages or explicit adapter zones.

A system that merely renames sync_linear_issues to sync_source while still hardcoding Linear underneath has not become generic. NSHKR's scanners and proof gates are designed to catch exactly that failure mode.

The stack is not allowed to claim generality based on one product.

extravaganza is the first proving-ground product: a coding-operations product that uses provider-specific product semantics while routing governed work through the generic substrate. It preserves product-level concepts such as Linear issues, GitHub pull requests, Codex sessions, workpads, evidence, and cleanup, but those details remain product or connector data rather than platform control flow.

The substrate must also support a neutral second product, toy_document_review, through the same path:

source event
  -> work item
  -> runtime/classification
  -> evidence
  -> review
  -> publication
  -> resource effect
  -> receipt
  -> projection
  -> replay

If extravaganza passes but the neutral product fails, the generic substrate claim is false. StackLab exists to make that visible before the platform decays into glued provider code.

NSHKR's defensibility comes from several compounding technical choices:

• Durable operation context. Every governed action joins back to one operation context carrying actor, tenant, installation, trace, request, idempotency, workflow, authority, binding snapshot, and causation references.
• Binding registry and run snapshots. Product roles resolve into compiled binding records, connector manifests, credential scopes, and compatibility checks. A run captures the operation plan it will use, so steady-state dispatch does not chase mutable provider configuration on every operation.
• Authority after resolution. Citadel authorizes the resolved operation plan after Mezzanine knows the operation class, manifest ref, binding ref, side-effect class, required scope, and credential constraints.
• Compact receipts plus lineage. Operation receipts are compact outcome records. Detailed lineage is attached through trace and evidence records, keeping projections efficient while preserving replay depth.
• Causal replay. AITrace records execution as a causal DAG with predecessor references. Replay is not raw emission order; concurrent events reduce through deterministic tie-breakers and declared merge semantics.
• Fail-closed operator semantics. Missing bindings, stale registry epochs, manifest mismatches, side-effect expansion, scope expansion, missing credential leases, missing confirmation policies, and registry unavailability produce stable, operator-visible failure classes.
• Static gates and negative controls. StackLab enforces no-bypass, no-vendor-noun, supervised-process, generic-dispatch, manifest-dependency, Citadel-policy, and legacy-residue gates.

Enterprise AI execution is a distributed systems problem before it is a model problem.

NSHKR is naturally aligned with the BEAM model: supervised processes, explicit failure handling, durable state machines, message passing, long-running workflows, and high-concurrency operational systems. The broader ecosystem includes OTP-native components for agent sessions, tracing, connector integration, subprocess-backed AI runtimes, and governed execution.

That is why the stack separates workflow truth, authority, connector mechanics, runtime mechanics, and trace proof instead of hiding them inside one convenient agent process.

NSHKR sits between several existing categories but is not reducible to any of them.

• One owner per durable fact. Execution records, decision records, lower receipts, source publications, memory fragments, and operator projections each need a clear writer.
• Semantic richness stops at the boundary. LLMs can propose, summarize, repair, and classify. Durable mutation requires typed intent, authority, idempotency, and an owner that can replay or reject the operation.
• Lower runtimes emit receipts, not meaning. Execution Plane and provider-family packages own transport fidelity, session mechanics, placement, sandbox posture, and raw facts. Product meaning and review state live above them.
• Read paths still need tenant proof. A caller-supplied run id, receipt id, issue id, or workflow id is never enough. Tenant scope has to match at the public surface, substrate authorization layer, and lower-facts boundary.
• Long-lived work is workflow state. Temporal owns active workflow lifecycle where durable orchestration matters. Postgres owns facts and projections. Local queues are delivery and cleanup tools only where explicitly retained.
• Proof is a product surface. Trace ids, causation, idempotency, source positions, schema hashes, release manifests, projection hashes, audit facts, and proof tokens are part of the operator contract.
• Generate scaffolding, keep meaning explicit. DTOs, mappers, manifests, and bridge code can be generated when that reduces drift. Policy interpretation, pack semantics, and owner decisions remain explicit source.

This inventory is generated from live GitHub metadata and grouped by nshkr-* topics so it stays current as the ecosystem grows.

Updated 2026-05-20