Policy before execution
Policy resolves authorization before execution can cross into production systems.
Authority Signal
OPHAELIS · DECISION GOVERNANCE LAYER
AI can advise.
Authority decides.
Ophaelis sits at the execution boundary and resolves whether proposed actions are allowed, constrained, or withheld before anything changes in production.
Policy authoritative
Human governed
Receipt backed
The system may propose the next step.
Ophaelis determines whether that step can cross.
Human-grade governance
Human authority defines governance boundaries and escalation paths for high-impact actions.
Receipts as proof
Each decision produces a receipt showing what was requested, what was authorized, and why.
Outcome
Credentials revoked. Funds transferred. Access removed. Or nothing happens.
Doctrine
AI can advise. Ophaelis authorizes.
Authority Layer
Decisions resolve against policy and intent packs under human governance.
SEE IT LIVE
See a real production run reach the boundary.
Watch proposal intake, policy evaluation, and authorization resolution unfold in sequence.
AI systems can propose actions. Ophaelis decides whether they are allowed to execute.
Internal environment. If enabled, external AI providers generate untrusted proposals; Ophaelis remains deterministic and policy-authoritative.
Decision Replay
Watch how a proposed action is evaluated and either allowed, limited, or stopped before execution.
Watch Ophaelis evaluate dangerous, ambiguous, and bounded account-recovery requests in sequence.
Latest evaluation: loading...
Replays one recent governed evaluation from cached authority receipts.
Schedule: 09:00, 15:00, and 21:00 UTC. Refresh after a run to load the latest result.
No recent evaluation available yet
Scheduled evaluation is active. This view updates after the next run.
Proposal → Governance → Outcome
Proposal Chamber
—
Execution boundary request received for governed review.
—
—
—
Authority Spine
Outcome Chamber
—
—
—
—
Real decision time: —
Receipt Artifact
Decision ID
—
Evaluated
—
Verdict
—
Authorization
—
Allowed / Denied
—
Policy Basis
—
Decision Explanation
—
Rationale
—
Shows one recent scheduled run from cached authority receipts. Results update after scheduled evaluations.
You just watched a real AI-proposed action reach the execution boundary — and Ophaelis determine what was allowed to happen.
Receipts
Recent governed decisions from real audit history.
Recent Receipts
Loading recent receipts...
Ophaelis Authority Console
Deterministic authority between AI-assisted intention and irreversible execution.
Governance Profile (Bounded)
Posture tuning only. Does not directly select outcomes.
Checks pending
Proposed Action
Governance Evaluation
Authority Decision
Receipt + Execution Authorization
Decision Snapshot
Final Authority Decision
Awaiting authority evaluation
Execution Authorization Status
Pending
Proposed Action
Run deterministic authority evaluation.
Compliant Alternative
A safer path will be surfaced after evaluation.
In Plain English
- The system is proposing a high-impact action.
- That action could materially change live operations.
- Ophaelis applies policy authority before any execution step.
- The next step follows the compliant path shown below.
Evaluation Path
- Request received Pending
- Policy pack resolved Pending
- Advisory/provider step Pending
- Deterministic authority decision Pending
- Authorization issued or withheld Pending
- Execution blocked or permitted Pending
Advisory Activity
Live Advisory
Pending
Providers Attempted
Pending
Fallback Used
Pending
Advisory Status
Pending
Latency Summary
Pending
Notes
Provider/advisory details will appear after evaluation.
Proposed Action
Intent Summary
Contain suspected admin privilege escalation in production.
Proposed Action
Revoke credentials, block source IP globally, and rotate access keys.
Target System
Identity provider and security control plane
Governance Evaluation
Authority Required
Pending authority evaluation
Human Approval
Pending
Evaluation Status
Checks pending
Policy Pack Selected
Security Policy Pack (version and hash pending)
Intent Pack Selected
Security intent semantics (version and hash pending)
Constraints Triggered
- Constraints will populate after decision.
Checks Performed
- Policy and intent pack resolution pending
- Capability gating pending
- Irreversibility and human-approval checks pending
Authority Decision
Final Outcome
Awaiting authority evaluation
Authority Meaning
Run evaluation to issue an authority decision.
Explanation
Run Authority Evaluation to receive a deterministic permit, block, or escalation decision.
What Happens Instead
A safer path will be surfaced after evaluation.
Compliant Alternative
- Compliant alternatives will be proposed after policy evaluation.
Receipt + Execution Authorization
Receipt
Authoritative receipt generated after decision.
Decision
Generated after decision
Execution Handoff
Generated after decision
Execution Authorization
Authorization details are populated after decision.
Authorization Status
Pending
Authorization ID
Generated after decision
Scope
Generated after decision
Authorization Expires
Generated after decision
Request ID
Generated after decision
Decision ID
Generated after decision
Timestamp
Generated after decision
Policy Pack ID / Version / Hash
Published with decision receipt
Intent Pack ID / Version / Hash
Published with decision receipt
Overlay Snapshot
Captured after decision
Triggered Rules
- Generated after decision
Rationale
Generated after decision
Guarded Execution Check
Attempted Action
Generated from proposed action
Authorization ID
Generated after decision
Authorized Scope
Generated after decision
Authorization Expiry
Generated after decision
Authorization Status
Pending
No simulated execution attempted.
Decision Lab
Internal policy decision workspace for operator validation.
Signals
—
•
Domain
—
•
Intent
—
Incident Detected
- Event: Admin privilege escalation attempt
- Environment: Production
- Location: New country login
- Confidence: High detection signal
- Requested Action: Immediate irreversible containment
Symptom Category
Severity
Duration
Red Flag Present
Demo-only. No PHI. This generates abstracted risk signals.
Event Type
User Role
Is the location unusual?
How sure are we?
Would this be hard to undo?
Environment
How sure are we? = how confident the detection signal is.
Hard to undo = could lock accounts / disrupt production.
Transfer Size
Account Age
Device
Location
Fraud Confidence
Beneficiary
Would this be hard to undo?
Fraud confidence = risk score from your fraud system.
Very large transfers and new devices usually require verification.
Request JSON
— •
Authority: —
Risk: —
Confidence: —
Reversibility: —
Authority Ceiling
—
Allowed Now
—
Confirmation Required
—
Blocked (and why)
- (none)
Authority Level
—
Recommended Next Step
Awaiting evaluation.
Decision Basis
- Environment: —
- Account Type: —
- Confidence: —
- Irreversibility: —
- Requested Actions: —
- Permitted Actions: —
- Blocked Actions: —
Ophaelis prevented:
- (none)
Domain
Context Environment
—
Context User Role
—
Computed Buckets
Policy Pack
—
Execution Mode
—
Intake Snapshot
Intent Description
—
AI Advice
Secondary advisory signals from model providers.
Requested Actions
- (none)
Model Advice (Optional)
OpenAI: Pending
Anthropic: Pending
AI advice is hidden in Basic view. Switch to Developer to view it.
- No proposals yet. Click Evaluate to generate proposals and run governance.
Model Proposal (Advisory)
AI Proposal vs Policy Verification
MATCHED
| Signal | AI Proposal | Policy Final |
|---|---|---|
| Risk | - | - |
| Confidence | - | - |
| Reversibility | - | - |
Adjustment Notes
Raw Proposals
Policy Evaluation & Trace
Secondary policy verification and explanatory trace details.
Policy Verification
Awaiting evaluation.
Ophaelis Scope
Security Decision Basis
Policy Pack (Human View)
Technical Details
Raw decision and trace payloads for debugging and audit.
Decision Response
Raw Trace
FOUNDER CONSOLE ACTIVE — DEV MODE / MOCK DATA
Data source: Mock
Awaiting refresh.
What this surface is
This is the Founder / Operator Control Room. It shows whether Ophaelis is healthy, what it recently decided, and what proof ran most recently. Commands stay disabled until admin auth is designed.
System State
Operational
Ophaelis is evaluating decisions. Execution halt is off.
Latest Proof
Finance audit-log export
Controlled enablement path. Safe actions can proceed with boundaries.
Authority Posture
Advisory != Authorized
Models can suggest actions. Ophaelis decides what may execute.
Mock values only. Real values will come from protected admin endpoints after auth is designed.
Flagship Guided Flow
This is the primary Ophaelis demo path for privileged account recovery and access governance.
1. Dangerous Request
AI or automation attempts to reset a CFO account and disable MFA.
2. Ambiguous Urgent Request
A rushed recovery request arrives before payroll closes, but identity and authority are unclear.
3. Controlled Recovery
Verified recovery support is allowed within approved boundaries.
4. Decision Receipt
Every authorization decision produces an auditable receipt showing what was requested, why it was allowed or denied, and what execution scope was approved.
The goal is not to stop all actions. The goal is to prevent unsafe execution while still allowing legitimate work to happen safely.
Decision Anatomy
Step 1: Request
System or AI proposes an action
Step 2: Interpretation
Intent and context are evaluated
Step 3: Policy Check
Policies determine what is allowed
Step 4: Capability Check
Requested actions must exist in the capability ledger
Step 5: Decision
Ophaelis returns allow, deny, or escalate
Step 6: Execution
Action only runs if explicitly authorized
FLAGSHIP
Example: CFO Account MFA Bypass Attempt
Request
Reset the CFO’s account and disable MFA
Interpretation
High-risk access change involving executive and finance identity
Policy
Privileged access and MFA removal require strict controls
Capability
reset_account and disable_mfa are known but restricted
Decision
Denied
Execution
Account reset and MFA bypass are blocked before execution
Ophaelis prevents AI or automation from changing sensitive account access without authorization.
CONTROLLED ENABLEMENT
Example: Verified CFO Recovery Support
Request
Create an IT ticket and send approved MFA recovery steps
Interpretation
Bounded support action using verified identity and approved recovery process
Policy
Safe recovery guidance may proceed without direct access changes
Capability
create_ticket and send_recovery_instructions are allowed with boundaries
Decision
Allowed with boundary
Execution
Only the approved support steps proceed
Ophaelis allows legitimate recovery support while preventing unsafe direct access changes.
Audit-log governance remains a secondary technical proof. Account access is the primary flagship demo because it is easier to understand across industries.
Ophaelis sits between decision and execution. Nothing runs unless it is authorized.
Ophaelis prevents destructive actions even when requested by an AI or system.
Ophaelis allows safe actions, but only within explicitly approved boundaries.
Reality Check
Real Now
- Deployed Worker gateway
- Protected decision endpoint
- Capability ledger
- Live Proof scenarios
- Audit persistence
- Smoke test validation
- Read-only admin endpoints pass terminal smoke test
Mock in This Console
- Top summary cards
- Decision Anatomy examples
- Command Preview
- Latest proof display
- System status display
Next to Wire
- Protected latest proof UI
- Protected capability coverage UI
- Protected status snapshot UI
- Protected recent decisions UI
- Protected operator events UI
Backend readiness does not mean browser wiring is enabled. The console stays mock-only until an auth boundary exists.
The engine exists. This console is becoming the safe operator surface around it.
Next Wiring Order Explained
1. Latest Proof Summary
Meaning: Shows the most recent Live Proof run and whether Ophaelis blocked, allowed, or constrained execution.
Why it matters: This tells the founder whether the authority engine is still proving the right behavior.
2. Capability Coverage
Meaning: Checks whether every scenario uses capabilities that exist in the ledger.
Why it matters: This prevents fake or ungoverned actions from sneaking into demos.
3. Status Snapshot
Meaning: Shows operational state, including whether execution halt is active.
Why it matters: This tells the operator whether Ophaelis is open for decision evaluation or intentionally halted.
4. Recent Decisions
Meaning: Shows real decision receipts produced by Ophaelis.
Why it matters: This proves the system is producing auditable outcomes.
5. Operator Events
Meaning: Shows admin/operator actions such as halt changes or fail-closed triggers.
Why it matters: This creates accountability around changes to the authority layer.
These should be wired as read-only data first. Commands come later, after admin auth and server-side protection.
Live Wiring Readiness
Required
Admin auth boundary selected
Choose Cloudflare Access or a server-side protected proxy before loading real admin data.
Required
No browser secrets
Admin and founder keys must never appear in frontend code, browser storage, or network-visible client config.
Required
Read-only endpoints first
Latest proof, capability coverage, status snapshot, recent decisions, and operator events should be wired before commands.
Required
Commands stay disabled
Run scenario, founder refresh, execution halt, and provider recommendation actions stay disabled until stronger auth and logging exist.
Required
Reality Check updated
When a mock item becomes real, move it into REAL NOW and remove it from MOCK IN THIS CONSOLE / NEXT TO WIRE.
Do not switch the console data source away from mock until every readiness item is satisfied.
Customer Integration Flow
This is how a customer system would use Ophaelis before any high-risk action executes.
Phase 1 Product Model
Customers keep their credentials, infrastructure, and execution systems. Ophaelis owns the authorization decision before sensitive actions run.
Customer owns execution
Ophaelis owns authorization
Receipt proves the decision
This keeps Ophaelis privacy-aligned while still enforcing the execution boundary.
Phase 1 is the product
The first sellable version of Ophaelis does not need to hold customer credentials or execute inside customer systems. The customer keeps execution. Ophaelis supplies the authorization decision and receipt.
Smaller surface area
Stronger privacy posture
Faster path to adoption
Simple integration does not mean simple product. The value is trust at the execution boundary.
1. Customer System
A product, workflow, or AI agent is about to perform a sensitive action.
2. Proposed Action
The system sends Ophaelis the intent, context, environment, and requested capabilities.
3. Ophaelis Authority Check
Ophaelis evaluates policy, intent, capability, risk, and execution boundaries.
4. Decision Receipt
Ophaelis returns an auditable decision: allow, deny, withhold, or allow with boundary.
5. Execution Gate
The customer system executes only if Ophaelis explicitly authorizes it.
The customer owns execution. Ophaelis owns authorization.
Example: before deleting logs, moving funds, changing access, or exporting sensitive data, the customer system calls Ophaelis.
Founder Console
Internal operator surface for Ophaelis.
Internal surface. Do not expose admin controls publicly. Admin endpoints remain server/API protected.
This is the Founder / Operator Control Room surface. It is currently mock-only until admin auth is designed.
System
—
Last Decision
—
—
—
—
—
Provider Status
OpenAI
—
—
Anthropic
—
—
Recent Activity
—
No decisions yet.
System Status
Not Wired
Tells the operator whether Ophaelis is allowed to evaluate decisions or whether execution is halted.
- Execution halt state will come from
/api/admin/status-snapshot. - Recent operator events will come from
/api/admin/events/recent. - Capability coverage will come from
/api/admin/live-proof/capability-coverage.
Live Proof
Not Wired
Shows the most recent proof scenario used to verify the authority engine.
Latest scenario, run source, verdict, and explanation will come from /api/admin/live-proof/latest-summary.
Decision Feeds
Not Wired
Shows recent governed decisions and why execution was allowed, constrained, withheld, or denied.
- Recent decisions
- Cybersecurity decisions
- Denied decisions
- Human authority decisions
- Missing context decisions
- Allowed with boundary decisions
Recent decisions and outcome-specific feeds will come from existing admin decision summary endpoints.
Provider / Index
Planned
Shows advisory model evidence later. Index can inform Ophaelis, but Ophaelis authorizes changes.
- Current live advisory providers: OpenAI + Anthropic
- Index role: evidence layer
- Ophaelis role: authority layer
Provider evidence remains advisory. Index informs; Ophaelis authorizes.
Index informs. Ophaelis authorizes.
Command Preview
Commands are intentionally disabled in this public/mock surface. Real commands require admin auth and server-side protection.
Next Wiring Order
Planned
-
Status snapshot
Source:/api/admin/status-snapshot
Purpose: execution halt state + recent operator signal -
Capability coverage
Source:/api/admin/live-proof/capability-coverage
Purpose: pre-demo scenario safety check -
Latest live proof summary
Source:/api/admin/live-proof/latest-summary
Purpose: operator-friendly view of latest proof state -
Recent operator events
Source:/api/admin/events/recent
Purpose: control-plane activity timeline -
Decision feeds
Sources:
-/api/admin/decisions/recent-summary
-/api/admin/decisions/recent-cyber-summary
-/api/admin/decisions/recent-by-domain
-/api/admin/decisions/recent-by-class
Purpose: inspect decisions by outcome/domain/class -
Provider / Index recommendations
Future source: Index/Ophaelis recommendation pipeline
Purpose: Index informs; Ophaelis authorizes
Admin wiring should not happen in the public browser until authentication and access boundaries are intentionally designed. This panel documents order, not active data access.
Detailed Logs
| created_at | tenant_id | domain | intent_id | verdict | authority_level | risk_level | confidence_level | reversibility_level | requires_human_confirmation | policy_pack_hash | intent_pack_hash | proposals_status | proposal_strategy_used | openai_ok | anthropic_ok |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| No decisions yet. | |||||||||||||||
Recent Decision / Audit Rows
| created_at | tenant_id | domain | intent_id | verdict | authority_level | risk_level | confidence_level | reversibility_level | requires_human_confirmation | policy_pack_hash | intent_pack_hash | proposals_status | proposal_strategy_used | openai_ok | anthropic_ok |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| No decisions yet. | |||||||||||||||
What This Console Is For
Internal founder/operator visibility into Ophaelis governance truth: provider health, recent governance decisions, and Decision Lab workflows.
What Each Tab Means
- Overview: fast operational pulse and latest decision snapshots.
- Decisions: fuller audit rows with lightweight filtering.
- Decision Lab: evaluator/testing flow; not source of production truth.
- Read Me: internal runbook and reminders.
Healthy vs Degraded
- Healthy: providers responding, low recent failures, decisions flowing.
- Degraded: repeated provider errors, stale timestamps, or failing refresh.
Deploy / Build Commands
Build / Deploy
npm install npm run build npm run deploy
Refresh / Cache-Bust Troubleshooting
Troubleshooting
1) Click Refresh in Overview. 2) Hard refresh browser (Ctrl+Shift+R). 3) Verify /api routes are returning JSON. 4) Re-run build and redeploy if UI is stale.
Ophaelis Today: Is / Is Not
- Is: deterministic governance authority with auditable policy enforcement.
- Is Not: autonomous destructive executor; delete/prune controls are not active.