Oracle Trust Model
OmegaX needs a stronger oracle model than a simple single-signer feed because health events, claims, and outcomes carry privacy, review, and settlement consequences.
Use this page for the general oracle policy model before reading Genesis-specific claim review or professional oracle onboarding.
The public protocol can express oracle profiles, pool policy, permission sets, outcome schemas, and claim attestations. Product-specific trust models still depend on the plan and staffed review process.
Why
Health and coverage-relevant events can involve:
- noisy longitudinal behavior
- private clinical inputs
- claims evidence
- review and challenge requirements
- different trust standards across product families
That means OmegaX needs explicit oracle policy, not implicit trust.
Oracle roles
Supported plans can scope oracle responsibility across roles such as:
- outcome oracle
- quote oracle
- premium attestation oracle
- claim-evidence oracle
- adjudication or review oracle
- risk-reporting oracle
Not every plan needs every role, but the model can express them where a plan authorizes them.
That flexibility matters because a low-friction reward plan and a higher-trust coverage plan should not be forced into exactly the same oracle assumptions.
Trust profiles by product type
Different product families can justify different oracle policy:
- faster reward flows may tolerate simpler quorum and lower-friction review
- sponsor-led plans may need stronger auditability and clearer operator separation
- protection and coverage products may need stronger evidence discipline
- more regulated participation may need richer challenge and escalation paths
These are different policies over one shared health-plan foundation, not entirely different protocols.
| Product context | Trust pressure | Likely policy shape |
|---|---|---|
| Rewards | Low-friction recognition of outcome completion. | Simpler quorum, faster finality, lighter review. |
| Sponsor-led plans | Reporting quality and operator separation. | Clear role boundaries and audit trail. |
| Protection and coverage | Evidence discipline and fair claim handling. | Stronger review, holds, attestations, and challenge paths. |
| Regulated participation | Compliance and escalation requirements. | Permissioned operators, richer records, and explicit controls. |
Finality lifecycle
Oracle finality is easier to review when these steps are explicit:
| Step | Meaning |
|---|---|
| Event observed | An offchain source produces a relevant signal. |
| Event normalized | The signal maps to a recognized schema. |
| Attestation submitted | A permitted oracle signs or anchors the result. |
| Policy condition reached | The plan's threshold, role, or quorum rule is satisfied. |
| Review window, if any | Challenge, hold, or escalation logic can run. |
| Finality recorded | The event becomes a settlement-ready fact. |
| Settlement unlocked | Downstream rewards, obligations, or claims can move. |
Evidence commitments
OmegaX does not need raw evidence onchain.
It does need:
- signer identity
- policy and role boundaries
- evidence commitments
- finality consequences
- replay-resistant nonces, expiry, and expected protocol context for settlement-critical attestations
That is how the system stays private without becoming opaque.
It also gives OmegaX a path to auditability without forcing raw records or raw claims evidence onto a public chain.
Disputes and challenge windows
Not every plan needs a heavy dispute path, but the architecture needs room for:
- conflicting evidence
- late corrections
- suspect AI-assisted interpretation
- higher-trust claim and coverage products
External attestation rails
External public attestation systems can help around the protocol, for example with:
- operator credentials
- model or execution-environment claims
- upstream review receipts
They complement OmegaX trust policy rather than replacing it.
OmegaX still needs its own plan-level oracle policy, finality rules, and settlement discipline even when outside attestation systems are useful around the edges.
Genesis Protect launch path
For the current Genesis Protect Acute claim-review model, including Phase 0 staffed review, offchain evidence, holds, and disputes, use the dedicated Genesis page:
That page carries the launch-specific public trust model. This page stays at the broader OmegaX oracle-model layer.