Evidence & Scope
How LUXION separates product claims, demonstrated mechanisms, empirical results, research horizons, and founder commitments.
Every material claim must have an epistemic state, supporting evidence, an explicit boundary, and a path for correction.
Claims and evidence field
Claim → Epistemic State → Artifact → Limitation → Supersession — public credibility requires evidence, boundaries, versioning, and correction.
Current public evidence snapshot
This is a bounded public status summary. Exact artifacts, methods, and current versions are maintained in the Guardian evidence index.
- Current product
- Guardian Runtime — technical preview and bounded design-partner evaluation.
- Evidence environment
- Controlled harnesses, scenario suites, replay artifacts, and pilot-oriented validation.
- Production certification
- None. Public evidence does not constitute safety, compliance, regulatory, or sector certification.
- Independent review
- No independent certification is claimed. Reproducibility and review status remain artifact-specific.
- Artifact identity
- Current artifact and version identifiers are available through the linked Guardian evidence index.
- Correction rule
- Claims without current evidence are narrowed, demoted, marked developing, superseded, or removed.
Current Guardian claim map
This public snapshot ties material operational claims to their current status, evidence basis, and boundary. Detailed artifacts and versions remain available through the Guardian evidence index.
| Material claim | Current status | Evidence basis | Boundary |
|---|---|---|---|
| Guardian evaluates proposed AI actions before execution. | Product claim / demonstrated mechanism | Runtime decision flows, controlled scenario suites, replay artifacts, and the public technical evidence index. | Demonstrated in bounded environments; not universal prevention, production certification, or proof of safe behavior in every deployment. |
| Guardian checks evidence, authority, context, and policy before consequence. | Demonstrated mechanism | Decision records and controlled scenarios exercising evidence conflicts, mandate boundaries, contextual validity, and policy conditions. | Policies, evidence sources, thresholds, and uncertainty treatment remain domain- and version-specific. |
| Guardian can admit, constrain, repair, defer, monitor, escalate, or deny proposals. | Demonstrated mechanism | Gate-state scenarios, display mappings, repair paths, and replayable decision traces. | Decision quality and false-positive or false-negative behavior depend on policy design, evidence quality, and deployment context. |
| Guardian preserves replayable responsibility records. | Product claim / demonstrated mechanism | Structured evidence packs, decision provenance, audit artifacts, and deterministic replay mechanisms. | Records support inspection and accountability; they do not themselves establish legal compliance or complete causal responsibility. |
| Guardian observes post-execution outcomes. | Developing capability | Outcome capture where workflow instrumentation and observation hooks are configured. | Not a universal current capability across all integrations, workflows, or physical environments. |
| LUXION coordinates rollback, restitution, decommissioning, or successor-system governance. | Research horizon | Research architecture, planned evaluation methods, and future lifecycle-governance work. | Not a current Guardian Runtime product capability unless separately implemented and evidenced. |
The LUXION Claims and Evidence Constitution
Product evidence appears first. Philosophical and theological commitments remain visible, but they do not borrow the authority of engineering or empirical proof.
-
Product claim
A bounded statement about what an available LUXION product currently does.
-
Demonstrated mechanism
A working capability shown in a controlled environment with stated assumptions and limitations.
-
Empirical result
A measured outcome tied to a method, dataset, environment, version, and reproducibility status.
-
Engineering principle
A design rule supported through architecture, implementation, testing, and operational analysis.
-
Scientific hypothesis
A falsifiable proposition requiring defined methods, measurement, and empirical investigation.
-
Developing capability
A partially implemented or integration-dependent capability not represented as universally available.
-
Research horizon
A defined direction not represented as present product capability or demonstrated performance.
-
Open question
A question LUXION explicitly refuses to present as solved.
-
Philosophical doctrine
A proposition supported through reasoning, interpretation, criticism, and conceptual coherence.
-
Founder theological commitment
A founder-level belief supported through faith and theological argument; not scientific or product proof.
Minimum public ledger fields
- exact claim
- epistemic state
- artifact and version
- test environment
- result
- limitation
- date
- maturity
- superseded-by status
Operational evidence, not abstract assurance
LUXION produces evidence surfaces around proposed AI actions and decisions at the creation threshold — within controlled deployment pathways, not through certification or abstract safety promises.
Operational evidence surfaces include proposed action, applied constraints, evidence state, authority boundary, policy route, decision, repair, escalation, observed outcome where instrumented, and replayable responsibility record.
-
Proposed action
What the agent or workflow intends to execute before commit.
-
Applied constraints
Policy, risk, consequence, and governance limits evaluated against the proposal.
-
Evidence state
Whether supporting context and provenance are sufficient to proceed.
-
Authority boundary
Whether decision rights match the proposed action in this context.
-
Policy route
How institutional policy maps to admissibility at runtime.
-
Decision
Admit, constrain, repair, defer, monitor, escalate, or deny before consequence.
-
Repair path
How a legitimate objective can proceed through a safer, narrower, or better-authorized route.
-
Outcome observation
Where instrumentation exists, what occurred after execution rather than what the system predicted would occur.
-
Replayable responsibility record
Structured trace for incident review, near-miss analysis, responsibility reconstruction, and control updates.
Do not claim
- LUXION solves, eliminates, certifies, or guarantees AI safety.
Say instead
- LUXION creates execution-time control surfaces.
- LUXION applies action-admissibility checks before execution.
- LUXION produces evidence records and replayable responsibility traces.
- LUXION supports repair, deferral, escalation, and denial for consequential proposals.
- LUXION supports controlled deployment pathways—not certification.
Controlled deployment pathways
LUXION enters operational use through a deliberate sequence — architecture fit first, observation before enforcement, evidence review before domain expansion.
-
Architecture review
Bounded fit conversation — integration surfaces, action inventory, authority boundaries, evidence maturity, and deployment design.
Evaluate a consequential workflow -
Observation mode
Record proposed actions, constraints, risk signals, and decisions without interrupting production workflows.
-
Shadow-mode evaluation
Compare runtime decisions against live traffic to establish baseline fit before any enforcement.
-
Controlled enforcement
Graduated admit, repair, constrain, deny, and escalate with agreed policies, authority paths, and rollback.
-
Evidence review
Assess false-positive and false-negative patterns, latency impact, audit completeness, repair quality, and recommended control updates.
-
Domain expansion
Extend governed workflows and sector context as evidence matures — not instant enterprise rollout or certification.
Pathway outputs inform fit assessment and deployment design — they do not constitute production clearance, safety certification, or regulatory approval.
What can be evaluated
During shadow-mode pilots and controlled enforcement, institutions can review observable patterns — not universal prevention or guaranteed mitigation.
-
Unsupported actions detected
Proposals that lack sufficient evidence or context before execution.
-
Unsafe tool calls denied or escalated
Tool-use attempts evaluated at the runtime gate — not claimed as universal attack prevention.
-
Repairable proposals redirected
Legitimate objectives preserved through safer, narrower, reversible, or better-authorized routes.
-
Unauthorized data movement surfaced
Data access and memory operations flagged before commit.
-
Policy drift identified
Gaps between documented policy and runtime admissibility behavior.
-
Evidence gaps mapped
Where proposals proceed without sufficient provenance or context.
-
Silent failures made replayable
Near-miss and incomplete-action patterns captured in responsibility records.
-
Escalation quality reviewed
Whether routed cases carry structured context for accountable review.
-
Outcome and control patterns observed
Where instrumentation exists, constraints, interventions, repairs, and unintended consequences can be reviewed across workflows.
Evaluation surfaces describe what can be observed and reviewed during controlled deployment — not guaranteed detection, elimination of risk, or production certification.
Limitations and non-certification
LUXION does not eliminate AI risk, certify compliance, replace legal, clinical, cybersecurity, financial, or compliance review, or guarantee safe AI behavior. It provides execution-control infrastructure and evidence surfaces for controlled deployment pathways.
- LUXION does not certify robotic safety.
- LUXION does not replace functional-safety engineering.
- LUXION does not substitute for ISO/IEC, legal, medical, financial, cybersecurity, or regulatory compliance processes.
- Strategic research is not the same as deployed product maturity.
Institutional orientation
LUXION can support institutional risk, governance, evidence, authority, and accountability workflows — but it does not certify institutional compliance.
It is runtime infrastructure designed to support accountable AI deployment: execution-time decisions, evidence sufficiency, escalation paths, action provenance, and corrective signals where AI systems propose action.
Framework references are used for institutional orientation only. Guardian does not certify legal, regulatory, or standards compliance.
| Governance concern | Guardian technical surface |
|---|---|
| Risk oversight | Action risk signals, constraints, escalation thresholds |
| Decision rights | Policy-boundary and authority checks before execution |
| Semantic layer | Shared action context, evidence requirements, and constraint vocabulary at runtime |
| Auditability | Governed execution records, replay inputs, decision traces |
| Human oversight | Routed review for uncertain or high-risk actions |
| Corrective action | Incident review and control updates |
Institutional orientation describes where Guardian can support institutional workflows during bounded evaluation and controlled deployment pathways—not where it replaces counsel, compliance sign-off, or sector-specific approval.
Product evidence bridge
Guardian Runtime is the first operational implementation at the creation threshold — pre-execution control for agentic AI systems evaluated under the pathways above.
Claims remain bounded by evidence tier, benchmark protocol, deployment context, and reproducibility status. AgentDojo-compatible budget validation is an internal and pilot-facing discipline—not an official AgentDojo leaderboard submission and not a substitute for production certification.
Detailed product mechanics, control surfaces, and bounded empirical evidence materials live on guardianpilot.org for product evaluation.
Continue with bounded deployment context
Explore the Guardian-centered platform or evaluate one consequential workflow — scoped to evidence maturity and controlled pathways.
Or email [email protected]