Determinism around probabilistic. Not determinism instead of probabilistic.
The architectural argument for deterministic-by-default AI. Read this if you want depth on the thesis before deciding whether Raptor's category bet matters to you.
AI proposes. Deterministic core disposes.
The core architectural principle from Raptor's canonical thesis: the AI proposes; the deterministic core disposes.
The AI does what AI is good at — interpreting fuzzy input, generating candidates, inferring intent. The deterministic layer does what rules are good at — validating those candidates, gathering evidence, applying the same ranking and trust-marking rules every time, and producing the output the user depends on.
The guarantee is process. Every Raptor response — every one — was produced by the same flow. The same evidence requirements. The same rules. The same trust boundary logic.
Two questions phrased differently get different answers, but they get answers produced the same way, with the same kind of structure backing them. This is why "deterministic by default" is not the same as "no AI." AI is allowed in the proposal layer. It is never allowed in the commit layer. The output the user acts on — the provisioning decision, the published document, the compliance attestation, the answer of record — comes from rules, not from sampling.
Proposal Layer
AI operates with full flexibility
- Fuzzy input interpretation
- Candidate generation
- Intent inference
- Any model, any prompt
Commit Layer
Rules dispose
- Evidence validation
- Governance enforcement
- Trust-boundary marking
- Same process every time
Trust. Discovery. Knowledge.
Raptor is three infrastructure layers. Each has a distinct responsibility, distinct data ownership, and a strict dependency direction. All native Go. All connected. All governed.
01 Trust Layer
Deterministic execution. Hash-chained provenance.
Every workflow execution, governance decision, and state transition is recorded in an append-only, hash-chained event log. Replay-verifiable. Tamper-evident. The substrate that makes audit claims defensible.
02 Discovery Layer
Domain-agnostic signal detection.
Statistical analysis of observation streams. Change-point detection, entropy profiling, representation analysis, synthetic calibration, and signal adjudication with 13 classification types. Pure computation, no state, no domain assumptions.
03 Knowledge Layer
Governed self-learning.
The platform observes its own governance event stream, detects structural deviations, and composes them into governed Learnings — scoped, challengeable relationship claims that require authority disposition and ship with their own weakening conditions. The platform learns, and the learning itself is governed.
The dependency direction is strictly downward. The Trust Layer does not know the other layers exist. Each layer has a different confidence model: Trust confidence is cryptographic, Discovery confidence is statistical, Knowledge confidence is governance. Conflating them would be an architectural error.
Five trust boundaries, enforced by architecture.
Every Raptor response segment carries one of five trust boundaries. These are not labels Raptor invents per-response; they're a canonical taxonomy enforced across the substrate.
| Boundary | Meaning | Evidence required |
|---|---|---|
| CONFIRMED | Cryptographically or operationally proven | Hash, signature, attestation, or operational confirmation |
| EXECUTED | Action actually occurred in the real system | Execution receipt, state change confirmation |
| RETRIEVED | Externally sourced from a named system | Source identifier, retrieval timestamp |
| INFERRED | Synthesized probabilistically | Model identification, confidence score |
| UNKNOWN | Insufficient evidence to classify | Explicit statement of what's missing |
Boundary propagation is enforced architecturally: a conclusion built on INFERRED inputs cannot be classified higher than INFERRED. Mixed-boundary responses segment explicitly. The boundary is not advisory metadata; it's a property of the response that downstream systems can act on.
Hash-chained execution events.
Each tenant has an execution_events table with a per-execution hash chain. Every governance event, every action, every state transition writes an immutable event with event_hash computed over the canonical payload plus previous hash plus sequence number.
Eleven of the platform's tables are immutable — append-only with database-level triggers enforcing it. The chain is verification-ready: independent re-computation catches tampering.
This is the substrate that lets you make process-level claims about what your system did, defensible to a regulator.
Model choice is orthogonal to governance.
internal/provider/ defines a unified Provider interface implemented by AnthropicProvider, OpenAIProvider, GeminiProvider, TogetherProvider.
Phase B-1 empirical result
The empirical claim Raptor makes about the substrate: open-weight and frontier models can both clear the deterministic governance threshold. The substrate is not model-dependent. As frontier and open-weight models improve, the substrate absorbs them. Both providers score 100% on the 20-scenario decision truth set; the open-weight model runs at materially lower token count and latency.
Four shapes. Same governed process.
Raptor's response shape is determined by the evidence available and the question being asked, not by a fixed default.
01 Insufficient information
When evidence needed to answer doesn't exist or isn't accessible, Raptor reports that directly. Factual report of state, not a refusal.
02 Ranked options
When evidence supports several reasonable approaches, Raptor returns a ranked list with evidence and tradeoffs. User remains in the decision loop.
03 Single answer with disclaimer
When evidence clearly supports one answer, Raptor takes a position. The disclaimer surfaces basis, confidence level, and what would change the answer.
04 Autonomous action
When directed to operate autonomously, Raptor acts on its own decisions. Every decision is traceable, auditable, and evidence-backed.
Across all four shapes, the same governed process produces the output. The shape varies with the evidence and the question; the process does not.
What you can do with this substrate.
- Audit-quality outputs by architecture. A regulator or auditor pulling any response can verify the process that produced it.
- Model choice without governance rewrite. Swap providers, versions, or open-weight alternatives without touching governance code.
- Provable claims about what your AI was permitted to do. Not "we have logs" — actual cryptographic substrate.
- Honest uncertainty surfaces. When the AI is guessing, the response says so plainly.
- Composable trust. Trust-bearing segments combine within a single response with clear rules about trust propagation.
Canonical sources.
For depth beyond this page, the canonical documents are committed to the repo.
docs/thesis/raptor-canonical-v1.md— the product thesisdocs/thesis/raptor-interaction-model-v1.1-addendum.md— the trust-content semanticsdocs/adr/ADR-021-phase-b-managed-open-weight.md— the multi-provider bridge architecture and amendments
Reach out.
Email for an architectural conversation. Reference the section that's load-bearing for your evaluation.
info@harpyits.com