What these systems do not guarantee.
These systems work and are being actively built. They are not complete safety solutions. For each system, we document what it does, what has been demonstrated, what assumptions are required, and what it does not guarantee.
What it does
- Single-binary Go gateway that intercepts machine-driven actions and evaluates allow/deny/escalate decisions.
- ed25519 machine identity and capability leases with scope and expiry.
- Trust scoring with sliding-window drift detection.
- HMAC-SHA256 execution receipts for every decision.
- 2 interceptor implementations wired (shell, Git); evaluator recognizes 14 action types.
What has been demonstrated
- Gateway compiles and runs; HTTP endpoint is functional.
- In-process microbenchmarks for policy evaluation.
- 2 of 14 action types have interceptor implementations (shell, Git); GitHub and CI/CD surfaces are planned.
What assumptions are required
- Actions must pass through the gateway. Bypassed actions are not controlled.
- Hardening artifacts (AppArmor, eBPF, Seccomp) are included but not automatically applied.
- Operator must configure persistent receipt signing keys.
What it does not guarantee
- That a model is aligned or will only request safe actions.
- Cryptographic signature verification is not yet enforced in the V1 runtime check.
- GitHub and CI/CD execution surfaces are planned, not implemented.
- The sub-10 µs / 1.2 M/s numbers are in-process microbenchmarks, not end-to-end throughput.
- Actions that bypass the gateway are not controlled.
What it does
- Policy gate that evaluates registered agent actions before execution.
- Allow, deny, or require-approval decisions with hot-swap policy.
- Cryptographically signed receipts (HS256/RS256 JWS, typ MAPSIG) with operator-managed keys.
- Human-in-the-loop approval workflows via webhooks.
- Built-in adapters for HTTP, payments, and database reads.
- TypeScript SDK published on npm (
@sidianlabs/mapv0.1.0).
What has been demonstrated
- Package published and installable on npm.
- Policy evaluation, receipt generation, and approval workflows implemented and tested.
- Conformance harness with reference profiles.
What assumptions are required
- Actions must pass through a registered adapter. Unregistered capabilities are not governed.
- Operator must configure a persistent signing key for receipts to be verifiable after restart.
- Production deployments need a durable approval backend (core wrapper is in-memory).
What it does not guarantee
- MAP does not inspect the internal reasoning of an LLM and cannot guarantee that an agent's intended action is benign.
- It is not a compliance certification.
- Python and Go SDKs are in preview and not yet contract-aligned with TypeScript.
- Synthetic microbenchmark numbers (~1µs, 1.2M/s) exclude HTTP, signing, persistence, and network overhead.
What it does
- Rust-based vector database with Claim + Evidence + Edge data model and provenance.
- Contradiction handling and temporal validity windows.
- OpenAI-compatible
/v1/embeddingsendpoint. - WAL-backed store with hash-chained audit log.
- Multi-tenancy with JWT auth, scoped API keys, and rate limiting.
- SDKs for Python, Go, and TypeScript.
What has been demonstrated
- Rust workspace tests pass (
cargo test --workspace, 416 tests at last run). - Single-node implementation working with Docker deployment.
- Performance benchmark suite (
perf_bench) with ingest, retrieve, ANN, and WAL-replay benchmarks.
What assumptions are required
- Single-node deployment. Distributed operation is under development.
- Operator is responsible for volume encryption (redb is not encrypted at rest).
What it does not guarantee
- Provenance records where a claim came from, not that the claim is true.
- Contradiction handling surfaces contradictions; it does not resolve which source is authoritative.
- Distributed operation (quorum, failover, leader election) is under development - 40% distributed readiness.
- HNSW ANN build is currently O(N²). usearch-backed HNSW and 1B-claim scale are design goals.
POLICY.md
Portable policy representation
Working Specification
Full non-guarantees in the POLICY.md repo What it does
- Markdown-native specification with machine-enforceable YAML frontmatter.
- allow / deny / require_approval actions with 12 condition operators.
- Scope targets: project, skill, agent, or department.
- CLI for validate, check, read, init, install, sync, and list.
- OpenAI Codex adapter for
command.runandnetwork.*rules.
What has been demonstrated
- Specification v0.2.0 with working implementation and tests.
- Authorization engine implemented in TypeScript with 21 vitest tests passing.
What assumptions are required
- A host runtime must call the authorization engine. POLICY.md does not enforce itself.
- Write access to the policy file allows modification (no signature verification on installed policies).
What it does not guarantee
- Default behavior is fail-open (allow when no rule matches).
- The OpenAI Codex adapter covers only
command.runandnetwork.*rules; other rule types are silently dropped. - The specification is a working draft (v0.2.0), not a finalized industry standard.
- The package is not yet published to npm.
Sidian
AI-native development environment
Beta
What it does
- AI-native code editor with Context Engine, multi-provider AI support, and MCP server integration.
- Project memories, rules, task planning, and agent-assisted workflows.
- Live at sidian.dev.
What it does not guarantee
- Sidian is not an AI safety mechanism.
- Provider integration claims have not been independently audited.
- No published threat model, security audit, or reproducible benchmark for the editor itself.
Read with
ResearchThe research programme the projects are built to investigate.Claims & evidenceEvery public claim, its status, and the source that supports it.Threat modelWhat the stack protects against, what it records, and where it stops.BenchmarksMeasured numbers with the command, configuration and environment that produced them.