Documentation

Seldon is a meaning-custody enforcement kernel. It wraps data in schema-validated tokens, evaluates them against fixed-order policy rules, and records every decision in an append-only hash-chain ledger. Below is a reference guide to the core concepts.

Kernel Specification

The authoritative specification for Seldon v0.1. Defines token schema, PDP/PEP rules, ledger structure, canonicalization, and all invariants. This is the sole authority for implementation.

SPEC_KERNEL_V0_1.md

Full specification: 26 sections covering mission, scope, schemas, PDP rules, ledger, concurrency, conformance, and constitution constraints.

Constitution (spec/constitution.md)

Seldon constitutional invariants: default deny, re-entry quarantine, append-only ledger, schema-only I/O.

Glossary (spec/glossary.md)

Formal definitions for Token, Port, PEP, PDP, Ledger, Decision, Quarantine, and all Seldon-specific terms.

Forbidden Terms (spec/forbidden_terms.md)

Terms that must never appear in Seldon documents without formal redefinition. If it sounds like AI marketing, it does not belong.

Token Schema

Every data payload crossing a Seldon boundary is wrapped in a Token. The token schema defines envelope (identity, TTL, lineage), labels (sensitivity, allowed ports), payload (content), and proofs (provenance hash).

Envelope

token_id, issuer_domain, subject_domain, actor_id, created_at, ttl_seconds, lineage (parent_token_id, sequence, hop_budget_remaining).

Labels

sensitivity (public/internal/confidential/regulated), class, purpose, allowed_ports, reintroduction_allowed.

Payload

content_type (json/text/bytes/ref), content, content_schema_id.

Proofs

policy_receipt_id, provenance_hash (SHA256 of JCS-canonicalized envelope+labels+payload), issuer_signature (null-only in v0.1).

Decision Engine (PDP)

The Policy Decision Point evaluates tokens against a fixed-order rule set. 14 ingress rules and 6 egress rules. First match wins. No runtime override.

Ingress Rules (14)

Schema validation, field check, signature check, JSON payload check, TTL, hop budget, port direction, unknown port, port allowlist, telemetry port, re-entry quarantine, default admit.

Egress Rules (6)

Schema validation, port direction, unknown port, port allowlist, telemetry port, default admit.

Decisions

admit (all rules passed), deny (with specific reason code), quarantine (re-entry or foreign domain).

Reason Codes (12)

Closed enum: schema_invalid, field_missing, signature_present, payload_json_invalid, ttl_expired, hop_exhausted, port_direction_mismatch, unknown_port, port_denied, telemetry_port_mismatch, reentry_quarantine, admitted.

Ledger

Append-only hash chain. Every decision (admit, deny, quarantine) produces a ledger record. Records are cryptographically linked via prev_record_hash. Genesis record anchors the chain.

Record Structure

record_id, record_type, timestamp, token_hash, decision_id, policy_hash, prev_record_hash, record_json, record_hash.

Hash Chain

record_hash = SHA256(JCS(record_without_record_hash)). Each record references prev_record_hash. Genesis has null prev_record_hash.

Concurrency

Single-writer model. PostgreSQL advisory lock serializes all ledger appends. No parallel admission.

Playground API

The playground runs real Seldon enforcement against a sandbox database. Each session gets isolated kernel tables. Runs are rate-limited and time-bounded.

GET /api/catalog

Returns industries, verticals, stacks, scenarios, connectors, and compatibility matrix.

POST /api/run

Execute a scenario against a stack. Returns run_id, session_id, events timeline, and scenario result.

GET /api/export/stack/{id}.json

Download resolved stack configuration as canonical JSON.

GET /api/export/run/{id}.json

Download run evidence bundle with selection context, results, and evidence hashes.

Deployment Model

Seldon deploys as a Docker Compose appliance (single-host) or container orchestration (Kubernetes). Catalog and policy packs are version-pinned YAML, enabling deterministic upgrades via container image replacement.

Hardware Baseline

2 vCPU, 4 GB RAM, 20 GB storage. PostgreSQL 15+ required. Single-node deployments serve most use cases.

Network Requirements

Port 443 (HTTPS) for external access. Port 5432 (PostgreSQL) internal only. No outbound connections required — Seldon operates air-gapped by architecture.

Upgrade Model

Versioned catalog + container image tags. Rolling upgrade via container replacement. Catalog version pinning prevents silent decision changes across upgrades.

Backup & Recovery

PostgreSQL pg_dump for ledger data. Catalog is source-controlled YAML — version-pinned and reproducible. No application-level backup agent required.

Compliance Alignment

Seldon provides evidence artifacts and enforcement controls designed to support compliance workflows. These mappings indicate alignment intent, not formal certification.

Audit Trail (SOC 2 CC7.2, ISO 27001 A.12.4)

Append-only hash-chain ledger with SHA256 verification. Every enforcement decision recorded with timestamp, token hash, decision reason, and cryptographic binding to prior records.

Access Control (NIST SP 800-82, IEC 62443-3-3 SR 2.1)

Schema-validated tokens with port allowlists. Policy-bound PDP with fixed-order rule evaluation. No runtime override of enforcement decisions.

Change Detection (CFR 21 Part 11 §11.10(e))

Catalog versioning with semantic version bumps. Policy pack versioning with hash-pinned references. catalog_hash included in every evidence export for tamper detection.

Evidence Export (SOC 2 CC7.3)

Deterministic canonical JSON exports with evidence hashes. Same inputs always produce byte-identical outputs via JCS canonicalization.

Incident Response Data (NERC CIP-008-6)

Decision records with reason codes, timestamps, and token lineage. Full replay capability from ledger chain for forensic analysis.

Versioning & Migration

Catalog and policy pack versions are tracked independently. All run exports include version references for reproducibility. Breaking changes follow semantic versioning.

Catalog Versioning

Semantic versioning (major.minor.patch). Breaking changes require a major bump. All exports include catalog_version and catalog_hash for precise reference.

Policy Pack Versioning

Each policy pack carries a version field. Changes produce new versions. Old versions are retained for historical reference and ledger chain continuity.

Backward Compatibility

Minor and patch catalog changes are backward compatible. Major version changes may alter decision outcomes. Existing exports remain valid — they reference their catalog_hash.

Migration Process

Upgrade catalog, re-run pre-compute, compare results against previous version. If decisions change, major version bump required. Migration guide published per major version.

Ledger Compatibility

Ledger records are immutable. New catalog versions append to existing chain. No retroactive changes to historical records. Chain integrity preserved across upgrades.