Enterprise Context Fabric — Design Partner Program

Products

Five products. One governed fabric.

Each product runs independently. Download, boot up, and tell us what you find. All five have runnable scenarios today.

🏗️

Live

ContextECF Fabric

Enterprise Context & Relationship Ledger

Ingests signals from email, calendar, Slack, and CRM into a tamper-evident ledger. Surfaces provenance-stamped context packs wherever your team works — CRM sidebar, calendar, meeting prep.

▶ See scenario ⬇ Download ZIP

⚡

Live

LLM Gateway

5-Layer Inference Control Plane

RunwayClass routing classifies tasks, selects optimal model tiers, estimates costs, and returns decision rationale before making any inference call. Every call logged, every decision attributable.

▶ See scenario ⬇ Download ZIP

🧠

Beta

Hyper-State Runtime

Governed agent continuity

Trajectory-aware runtime that gives AI agents persistent, governed activation state. Every cycle produces a tamper-evident audit entry — no external dependencies, local or ledger-connected.

▶ See scenario ⬇ Download ZIP

📦

SDK

FabricLedger SDK

Agent Runtime Enforcement SDK

TypeScript SDK for agents and AI runtimes to receive governed activation. Owns ActivationReceipt, RuntimeEnforcementManifest, DeniedCapabilityReceipt contract types. Free developer tier.

▶ See scenario ⬇ Download ZIP

🛡️

Security

Context Fabric Appliance

Edge Runtime Enforcement

Standalone edge appliance for destination guard decisions, runtime manifest enforcement, masking, denied-capability receipts, and SIEM export. Evaluates every governed action before it executes.

▶ See scenario ⬇ Download ZIP

Scenarios

Five problems we kept hearing. Run the proof yourself.

Below are the exact scenarios we built and ran — the problem, the signal we sent, and what the system produced. Copy the commands. Boot it up. Tell us what you found.

Story 1 of 5 · 🏗️ ContextECF Fabric — Enterprise Context Ledger

Your revenue team walks into renewal calls blind.

CRM has the records. It doesn't have the relationship. When an AE walks into a renewal call, they're piecing context together from six tabs — email threads, Slack history, call notes, deal room — while the customer expects them to already know everything. The signals exist. They're just not connected.

Here's what we ran

We created a MEETING_SCHEDULED signal for an Acme Corp Q3 renewal — two participants, champion engaged, renewal risk flagged, upsell vector present. Sent to the ECL writer with full provenance: source system, event ID, timestamp.

renewal_risk captured upsell_opportunity captured champion_engaged captured

What it showed

Before the call, you know who the champion is, what the risk signals are, and what has changed since the last touchpoint — provenance-stamped, deterministic, tamper-evident. Not a guess assembled by an AI. A ledger entry with a source, a timestamp, and a receipt.

🏗️

Fabric — Context Ingestion

API gateway + ECL writer + migrations, self-contained

# Download the ZIP, then:
$ cd contextecf-fabric-trial/
$ cp .env.example .env
$ docker compose up
#  Migrations run first. Ready when you see "Listening on :8080".

# Verify the platform is healthy:
$ curl http://localhost:8080/health/ready | jq

# Ingest the renewal meeting signal:
$ curl -X POST http://localhost:8080/v1/context/events \
    -H "Authorization: Bearer trial-dev-token" \
    -H "Content-Type: application/json" \
    -d @mock-nce.json | jq

What to look for in the response

01The signals array — do renewal_risk, champion_engaged, and upsell_opportunity map to signal types your team actually tracks?
02The provenance block — sourceSystem, sourceEventId, capturedAt. Can you replace google_calendar with your actual source system and still get a clean receipt?
03The response time — is sub-200ms fast enough for the real-time surfaces your team uses: CRM sidebar, Slack bot, calendar integration?

Tell us what you found. Was the context pack useful? What relationship signals were missing? Did the provenance model fit how your connectors actually work?

Share your findings →

Story 2 of 5 · ⚡ LLM Gateway — 5-Layer Inference Control Plane

Your AI infrastructure is twelve teams picking twelve models with no audit trail.

Every team ships their own LLM integration. Anthropic for some, OpenAI for others, Google for a third. Costs are invisible until the invoice. There's no policy layer. When something goes wrong, no one knows which model did it, under what instructions, with what data. You can't govern what you can't see.

Here's what we ran

We sent a preflight governance request — no API key required. The gateway classified the task domain (code_generation), selected the optimal model tier using RunwayClass routing, estimated cost at scale, and returned the full decision rationale — before making a single inference call.

RunwayClass routing decision returned Model selection + fallback chain shown Cost estimate at 500 calls/day

What it showed

Before spending a single token, you can see exactly how the governance layer classifies your workload, which model it routes to, and what the fallback chain looks like. Add one API key and the same routing logic governs live inference — every call logged, every cost tracked.

⚡

LLM Gateway — Governance Demo

Preflight works without any API key

# Copy the config template (add a key when ready):
$ cp gateway.yaml.example gateway.yaml
$ docker compose up
#  Ready in ~20 seconds. Redis included.

# See governance decisions — no API key needed:
$ curl -X POST http://localhost:8090/v1/preflight \
    -H "Content-Type: application/json" \
    -d '{"estimated_calls":500,
         "task_domain":"code_generation",
         "context_tokens_avg":4000}' | jq

# Add a key — send a governed inference request:
$ curl -X POST http://localhost:8090/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model":"claude-sonnet-4",
         "messages":[{"role":"user",
           "content":"Summarise our Q1 pipeline risk"}]}' | jq

What to look for in the response

01The runway_class — A through E represent cost and capability tiers. Does that classification map to how your org thinks about workload types?
02The fallback chain — does the degradation order match your vendor preferences and data residency requirements?
03The cost_estimate at 500 calls/day — try changing estimated_calls and watch it scale. Is the magnitude in the right range for your team?

Tell us what you found. Does the RunwayClass matrix match your actual workload taxonomy? What task domains are missing? Did the cost estimate surprise you?

Share your findings →

Story 3 of 5 · 🧠 Hyper-State Runtime — Governed agent continuity

Your AI agents act. Can you prove what they were authorized to do?

AI agents are making decisions — drafting emails, querying databases, calling APIs. When a compliance officer asks "who authorized this action, under what context, with what constraints?" the answer today is "we think the model did it." That's not an audit trail. That's a liability.

Here's what we ran

We ran two sequential agent cycles on the same trajectory ID. Each returned a signed audit entry. The second entry's previous_receipt_hash references the first — forming a tamper-evident chain, persisted locally, with no external dependencies.

Entry 1: task + signed audit ID Entry 2: hash links to Entry 1 Chain persists to local volume

What it showed

Every governed action is recorded. The chain is verifiable. You can prove what was authorized, in what order, under what context — without trusting any single system, without a cloud connection. The audit trail lives in your environment. You own it.

🧠

Agent Activation Demo

Tamper-evident audit chain, standalone mode

# Start ACM standalone (no Pub/Sub, no Fabric needed):
$ cd acm-trial/ && docker compose up
#  Ready in ~20 seconds. Redis included.

# Cycle 1 — governed agent activation:
$ curl -X POST http://localhost:8095/v1/agent/cycle \
    -H "Content-Type: application/json" \
    -d '{"trajectory_id":"demo-traj-001",
         "task":"Summarise Acme renewal history"}' | jq

# Cycle 2 — same trajectory, watch the chain grow:
$ curl -X POST http://localhost:8095/v1/agent/cycle \
    -H "Content-Type: application/json" \
    -d '{"trajectory_id":"demo-traj-001",
         "task":"Draft renewal email for Alice at Acme"}' | jq

# Inspect the full receipt chain:
$ curl http://localhost:8095/v1/admin/control-tower | jq

What to look for in the response

01The receipt_id and previous_receipt_hash — Receipt 2 should reference Receipt 1. Does the chain break if you modify a receipt manually?
02The trajectory_id linking both receipts — can your compliance team trace an entire agent session from a single ID matching a real case number?
03Run docker volume inspect acm_outbox — receipts persist even if the container restarts. Does that match your air-gap or data residency requirements?

Tell us what you found. Does the receipt schema cover your compliance requirements? What fields would your legal or security team need that aren't there yet?

Share your findings →

Story 4 of 5 · 📦 FabricLedger SDK — Agent Runtime Enforcement SDK

Your integration starts at the HTTP layer. It should start at an import.

Writing direct API calls against an enterprise context platform means managing headers, response parsing, error handling, and retry logic before your first signal lands in the ledger. That's not a signal ingestion problem — it's plumbing. The FabricLedger SDK removes the boilerplate so you define your vocabulary and start ingesting in the time it takes to read this paragraph. Zero npm dependencies. Copy one file.

Here's what we ran

We took a batch of 4 relationship events across 3 accounts — different source systems, different signal types — and ingested them with a single script. No package manager. No build step. One require('./contextecf') and a loop.

4 events, 3 accounts ingested Signal vocabulary defined in plain strings Ledger summary returned in <100ms

What it showed

The SDK abstracts the HTTP layer and gives you a typed surface for the ECL. Signal names are plain strings — use your vocabulary, not ours. Point FABRIC_URL at any running Fabric instance: local trial, shared dev server, or production endpoint. The same three lines work everywhere.

📦

FabricLedger SDK — Batch Ingest

Zero dependencies — requires Node.js 18+ only

# Fabric trial must be running first:
$ cd ../fabric && docker compose up -d
$ cd ../sdk

# Confirm both services reachable:
$ node examples/01-health-check.js

# Ingest 4 events across 3 accounts — no install needed:
$ node examples/03-batch-ingest.js

# Define your own signal vocabulary (interactive):
$ node examples/04-custom-signal.js

# Point at any running Fabric instance:
$ FABRIC_URL=http://shared-server:8080 node examples/03-batch-ingest.js

What to look for in the response

01The ECL sequence numbers — each event gets a monotonically increasing sequence. Does the ordering match what your integration would produce? Could you use the sequence as a cursor for replays?
02The signal vocabulary — renewal_risk, champion_engaged, new_logo are our defaults. Can you replace them with your internal taxonomy and still get clean receipts? Try example 04 to define your own.
03The FABRIC_URL env var — point the SDK at a shared Fabric instance your team is running. Does the ledger accumulate correctly across multiple SDK clients writing simultaneously?

Tell us what you found. Which signals mapped cleanly to your business? What fields are missing from the receipt contract? What language does your team use for relationship intelligence — we want to adopt it.

Share your findings →

Story 5 of 5 · 🛡️ Context Fabric Appliance — Edge Runtime Enforcement

Your AI agents can act. But you can't prove what they were allowed to do — or what they tried.

When an AI agent takes a governed action — writing to CRM, sending a draft, exporting data — there's no standard way to know whether it was authorized, masked, and logged before it executed. Post-hoc audit logs tell you what happened. The CFA tells you what was evaluated before it happened, issues a cryptographically chained receipt, and writes a SIEM event — regardless of outcome.

Here's what we ran

We submitted four governed actions to the CFA — two allowed, two denied — then passed a payload containing an email address, phone number, and credit card through the masking layer.

2 allowed · 2 denied decisions SHA-256 receipt chain across all 4 PII masked before SIEM write

What it showed

Every decision — allow or deny — gets a receipt whose hash chains to the previous one. You can't forge a receipt, reorder the chain, or drop an event without breaking the hash sequence. The SIEM log is ndjson: one event per line, ready for Filebeat, Splunk HEC, or Google Chronicle. PII never enters the log — it's masked at the enforcement layer before anything is written.

🛡️

Context Fabric Appliance — Edge Enforcement

Zero dependencies — requires Node.js 18+ only

# Start the CFA enforcement server:
$ node server.js

# Submit an allowed action — get a chained receipt:
$ bash examples/02-allowed-action.sh

# Submit a denied action — get HTTP 403 + deny receipt:
$ bash examples/03-denied-action.sh

# Pass PII through masking — inspect what hits the SIEM:
$ bash examples/04-masking.sh

# View the full SIEM event log:
$ bash examples/05-siem.sh

What to look for in the response

01The receipt hash chain — each receipt's previous_receipt_hash links to the prior one. Copy the receipt_hash from example 02 and verify it appears as previous_receipt_hash in example 03. Could you use this chain as a compliance artifact?
02The manifest policies — open manifest.json and add your own agent with your own capability vocabulary. Restart the server and govern actions against it. How closely does the dot-notation capability model map to your agent's action surface?
03The SIEM log format — siem.log is newline-delimited JSON. Can you pipe it to your SIEM? What fields does your security team need that aren't there yet?

Tell us what you found. Which capabilities matter most to your governance team? What does your agent action surface look like — REST calls, tool use, function calls? What would a production receipt need to contain to satisfy your compliance team?

Share your findings →

Design Partner Program

Run it. Break it. Tell us everything.

Your findings go straight to the engineering team. We aim to respond within 24 hours. Every friction point you hit shortens the path for the next enterprise evaluating this.

Share Your Results

What did you find when you ran it?

We want the honest verdict — what worked, what broke, what surprised you, and what's missing. 180-day trial entitlement included. No credit card, no auto-renewal.

Your name

Work email

Which scenario did you run?

Your verdict

What worked? What broke? What's missing?

May we share your feedback publicly?

Request an Enhancement

Something's missing. Tell us exactly what.

Enhancement requests go into our GitHub issue tracker — visible, trackable, tied to the engineering backlog. If ten design partners ask for the same thing, it moves to the top of the queue.

What makes a good request

Name the specific scenario and the step where you hit the gap
Describe what you expected vs. what actually happened
Tell us the business consequence — what can't you do without this?
Include your environment: Docker version, OS, team size, use case

What to expect

We triage every issue within 48 hours and leave a public comment
Design partner requests are labelled and prioritised separately
If we can't build it, we'll tell you why — no issue goes silent

Open enhancement request →

Design partner benefits

180-day trial on any tier — no credit card
Direct engineering access — not a sales queue
Co-design roadmap influence
First access to each new scenario as it ships

Pricing

Simple, transparent plans.

Design partners get 180 days free on any tier. No credit card. No auto-renewal. Tell us what you think at the end.

Basic

$29_/mo

Individual operators and small teams getting started.

1 user
2 connectors
10K NCEs/month
1K API calls/day
5 GB storage
Community support

Start 180-day trial

Pro

$99_/mo

Growing teams who need shared context and integrations.

5 users
5 connectors
100K NCEs/month
10K API calls/day
25 GB storage
Priority email support
CRM intelligence
Drift detection

Start 180-day trial

Max

$299_/mo

Larger teams with full governance and compliance needs.

25 users
15 connectors
500K NCEs/month
50K API calls/day
100 GB storage
Dedicated support
RBAC + SSO
BYO data plane

Start 180-day trial

Enterprise

Custom

Unlimited scale, air-gapped deployment, custom SLA.

Unlimited users
Custom connectors
On-prem or VPC deploy
AWS / GCP Marketplace
SCIM + SAML
Dedicated CSM
LLM Gateway + CFA + ACM
SLA & audit exports

Talk to us

From Design Partners

Early results.

Collected from design partners who ran these scenarios in their own environments. No staging accounts. No curated demos.

Testimonials appear here as design partners complete their trials and share their findings.
Be the first.

Stop the AI agent stampede.

Five products. One governed fabric.

Five problems we kept hearing. Run the proof yourself.

Your revenue team walks into renewal calls blind.

Your AI infrastructure is twelve teams picking twelve models with no audit trail.

Your AI agents act. Can you prove what they were authorized to do?

Your integration starts at the HTTP layer. It should start at an import.

Your AI agents can act. But you can't prove what they were allowed to do — or what they tried.

Run it. Break it. Tell us everything.

Simple, transparent plans.

Early results.