NSHKR is a governed write-path substrate for enterprise AI execution. It captures how AI-mediated actions move from typed intent through authority, workflow, external effect, receipt, evidence, projection, review, and replay.

Why does the write path matter for enterprise AI?

The write path is where a proposed action becomes binding and where an external effect actually happens. Capturing that moment gives operators durable proof of who asked, what authority applied, which effect was requested, what happened, what evidence supports it, and whether the chain can be replayed.

How does NSHKR avoid provider lock-in?

Products can bind roles to concrete providers such as GitHub, Linear, Codex, Slack, Jira, Notion, or internal APIs. Reusable platform surfaces still operate on product roles, operation classes, manifests, receipts, and projections, while provider mechanics live in connector packages.

Why is NSHKR built around Elixir, OTP, and the BEAM?

Enterprise AI execution is a distributed systems problem before it is a model problem. OTP provides supervised processes, explicit failure handling, durable state machines, message passing, and high-concurrency runtime surfaces.

What proof does the platform produce?

NSHKR produces compact receipts, evidence records, projection updates, review decisions, AITrace causal DAGs, release evidence, and StackLab scanner results so governed execution can be audited and replayed.

Elixir / OTP / BEAM · governed write path · open source

Governed write-path infrastructure
for enterprise AI execution.

NSHKR is the substrate where AI proposals become authorized operations: commands enter through typed product boundaries, resolve authority and workflow state, execute lower effects through governed connectors, and return receipts, evidence, projections, reviews, and replayable proof.

intent authority workflow effect receipt evidence projection review replay

GitHub → Execution Contract Ecosystem

Execution Contract

The stack is built around the questions an enterprise has to answer after an AI-mediated action. The important artifact is not a prompt transcript. It is a durable chain from request to authorized operation to external effect to receipt-backed replay.

01Who asked?

Actor, tenant, installation, request context.

02What authority?

Capability, policy, scope, review gate.

03Which workflow?

Operation context, causation, idempotency.

04Which effect?

Operation class, manifest, lower instruction.

05What happened?

Effect receipt, status, failure class.

06What evidence?

Evidence refs, attached artifacts, proof tokens.

07Who reviewed?

Review case, decision, override, escalation.

08Can it replay?

AITrace DAG, predecessor refs, merge semantics.

Command OperationContext ResolvedOperationPlan AuthorityPacket GovernedInvocationEnvelope ExecutionInstruction EffectReceipt EvidenceRecord Projection ReviewDecision AITrace DAG

AppKit boundary product-facing commands, reads, reviews, leases, traces

app_kit is the northbound surface product code is allowed to touch for governed platform behavior. It accepts product-level commands and stable DTOs, exposes operator reads and review controls, and keeps products from stitching lower execution paths together by hand.

app_kit extravaganza stack_lab

Mezzanine substrate workflow truth, ledgers, receipts, evidence, projections

mezzanine owns reusable operational truth: binding registry, compiled run snapshots, workflow handoff, execution ledgers, operation receipts, evidence, projections, review state, audit, and operator actions. It records the facts that make the write path replayable.

mezzanine execution_engine decision_engine

Semantic and authority chain context, normalized outcomes, capability and policy compile

outer_brain owns semantic context, recall, normalized AI outcomes, and semantic failure carriers. citadel authorizes after resolution, when the operation class, manifest, side-effect class, required scope, and credential constraints are known.

outer_brain → citadel

Connector spine manifests, operation descriptors, leases, governed invocation

jido_integration resolves connector manifests, operation descriptors, and credential leases into governed lower invocation. It lets provider mechanics be specific without leaking provider-shaped control flow into reusable platform surfaces.

jido_integration core/contracts control_plane

Execution plane HTTP, process, CLI, sandbox, filesystem, raw effects

execution_plane performs raw mechanics across HTTP, CLI, process, JSON-RPC, sandbox, terminal, filesystem, and future execution lanes. It emits receipts and raw facts. Product meaning, review state, and operational projections stay above it.

execution_plane pristine prismatic cli_subprocess_core

Trace and proof causal DAGs, replay, redaction, lineage, failure drills

AITrace records causal execution events with predecessor references so replay is not just emission order. stack_lab adds scanners, acceptance gates, negative controls, failure drills, and second-product validation so generality is tested instead of assumed.

AITrace stack_lab ground_plane

Products own meaning. Platform owns invariants. Connectors own vendor mechanics. Execution owns raw effects. Trace owns proof. switchyard ElixirScope

149

Repository nodes

525

GitHub stars

Write-path stages

Audit questions

Authority follows resolution

A broad product request is not enough. Citadel authorizes the resolved operation plan after Mezzanine knows the operation class, manifest ref, binding ref, side-effect class, credential scope, and review constraints.

Provider specificity is data

A pack can bind issue tracking to Linear, code hosting to GitHub, or runtime work to Codex. Reusable surfaces still speak product roles, manifests, operation classes, receipts, and projections.

Proof is executable

stack_lab scenarios, AITrace DAGs, schema registries, release manifests, no-bypass scans, projection hashes, and proof tokens are not documentation after the fact. They are acceptance gates.