Design Partner Program — Limited Access

Three enterprise AI problems
we kept hearing.
Run the solutions 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 in your own environment. Then tell us honestly what you found.

🔒 IP-protected builds — no source exposed
🐳 Docker Compose — runs in your own sandbox
180-day trial entitlement included
🔄 Direct line to the engineering team

Story 1 of 3
🏗️ 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, a champion engaged, renewal risk flagged in the content signals, an upsell vector present. We sent it to the ECL writer with full provenance: source system, event ID, timestamp.
renewal_risk signal captured
upsell_opportunity signal captured
champion_engaged signal 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. The same context pack surfaces in your CRM, your calendar, your Slack — wherever your team works.
🏗️
Fabric — Context Ingestion
API gateway + ECL writer + migrations, fully 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".
#  First pull: 2–3 min. After that: ~30 seconds.

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

# Ingest the renewal meeting signal (mock-nce.json is included):
$ 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
  • 01 The signals array in the ingest response — do renewal_risk, champion_engaged, and upsell_opportunity map to signal types your team actually tracks?
  • 02 The provenance blocksourceSystem, sourceEventId, capturedAt. Every signal is attributed. Can you replace google_calendar with your actual source system and still get a clean receipt?
  • 03 The response time on the ingest endpoint. Is it 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 3
⚡ 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 to the LLM Gateway — no API key required. The gateway classified the task domain (code_generation), selected the optimal model tier using RunwayClass routing, estimated cost at the declared call volume, 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 would route to, and what the fallback chain looks like. Add one API key and the same routing logic governs live inference — every call logged, every decision attributable, every cost tracked.
LLM Gateway — Governance Demo
RunwayClass routing — 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

# Once your key is set — 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
  • 01 The runway_class field — RunwayClass A through E represent cost and capability tiers. Does that classification map to how your org actually thinks about workload types?
  • 02 The fallback chain — if the primary model is unavailable, which vendor does the gateway route to next? Does that degradation order match your vendor preferences and data residency requirements?
  • 03 The cost_estimate at 500 calls/day — is the magnitude roughly right for your team's actual usage pattern? Try changing estimated_calls and watch it scale.
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 3
🧠 ACM — Hyper-State Runtime — Agent Continuity Mode

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 cycle returned a signed activation receipt. The second receipt's previous_receipt_hash references the first — forming a tamper-evident chain, persisted to a local volume, with no external dependencies, no cloud account, no trust-us.
Receipt 1: trajectory task + signed receipt_id
Receipt 2: hash links back to Receipt 1
Chain persists to local outbox volume
What it showed
Every governed action is receipted. 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, without a vendor-managed ledger. The receipts live in your environment. You own them.
🧠
ACM — Agent Activation Demo
Governed cycles with tamper-evident receipt chain
# Start ACM in standalone mode (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 receipt chain in the Control Tower:
$ curl http://localhost:8095/v1/admin/control-tower | jq
What to look for in the response
  • 01 The receipt_id and previous_receipt_hash fields — Receipt 2 should reference Receipt 1's ID. That hash linkage is the chain. Does it break if you modify a receipt manually?
  • 02 The trajectory_id linking both receipts — can your compliance team trace an entire agent session from a single ID? Try using a trajectory ID that matches a real case number from your system.
  • 03 The local outbox volume — run docker volume inspect acm_outbox after the cycles. 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 and audit requirements? What fields would your legal or security team need that aren't there yet?
Share your findings →

Two more products for platform teams.

The SDK and appliance are designed to be embedded — in your agent runtimes, at your network edge. Docker scenarios coming in the next design partner cohort.

📦
SDK
FabricLedger SDK
Agent Runtime Enforcement SDK

The TypeScript SDK that coding agents and AI runtimes embed to receive governed activation. Owns the contract types — ActivationReceipt, RuntimeEnforcementManifest, DeniedCapabilityReceipt — plus context compiler and negative knowledge.

TypeScript npm package Schema versioned Free developer tier
ZIP published on each SDK release tag. Request early access via the form below.
🛡️
Security
Context Fabric Appliance
Edge Runtime Enforcement

Standalone appliance that runs at the edge — destination guard decisions, runtime manifest enforcement, masking, denied-capability receipts, and SIEM export. Evaluates every governed action against the active manifest before it executes.

Destination Guard SIEM export Sidecar mode Enterprise tier
ZIP published on each CFA release tag. Request early access via the form below.

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.

Request an Enhancement
Something's missing.
Tell us exactly what.
Enhancement requests go into our GitHub issue tracker — visible, trackable, and 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 labeled and prioritised separately from the public backlog
  • 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

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
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

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.