CueCrux Trust, Safety & Legal FAQ

“Know with certainty.” This document explains how CueCrux keeps evidence trustworthy, mitigates bias, protects users and the platform, and handles disputes or bad data. It is written to reassure evaluators and to make hostile actors think twice: the platform is designed for proof, not opinion, with cryptographically verifiable receipts and append‑only provenance at its core.

What CueCrux Is (and why it’s hard to game)

CueCrux’s Engine uses CROWN retrieval: Counterfactual, Reputation‑Weighted, Origin‑Verified, Workflow‑eNcoded. Every answer is assembled via QUORUM (MiSES) (Quorum of Unified Observations and Referenced Underlying Material), selecting a MiSES (Minimal Evidence Set) per claim, and can be replayed from a signed Receipt. Modes control depth and cost: light, verified, and audit (the latter adds counterfactuals and deterministic receipts).

Separation of powers keeps trust robust: the web app (WebCrux) never exposes Engine tokens; an independent operator (WatchCrux) supervises health and audits; infrastructure (InfraCrux) standardises /healthz + /metrics; the CRUX economy rewards verifiable contributions without creating a token.

All data is “biased”? How we minimise bias without censorship

CueCrux does weighting, not hiding.

1. Surfaces counter‑evidence by design (Counterfactual Challenger lane). Conflicts are displayed, not suppressed; contradiction rate is a first‑class metric.
2. Demands independent citations via QUORUM (MiSES) and domain‑diversity goals; weak quotes are flagged.
3. Penalises manipulation (brigading, collusion, quote‑mining) with explainable, reversible dampings; nothing is silently deleted.
4. Syncs retractions and venue risk (e.g., predatory journals) and adjusts weights promptly. Media with C2PA credentials gets a small boost.

Policy stance: Preserve viewpoint neutrality. We weight evidence quality and independence; we do not censor views for ideology. Appeals are supported with public reason codes.

How the platform protects users and itself (security & safety)

Proof integrity: Every artefact stores BLAKE3 content hashes; receipts are signed (ed25519), append‑only, and replayable. Audit mode refuses to answer if provenance fails.

Secret hygiene: All production secrets come from Vault; JWTs and receipts are signed with Transit (no private keys on disk), with frequent key rotation and JWKS overlap.

Least‑exposure app model: WebCrux uses a server‑side BFF. Browsers never hold Engine tokens; requests are proxied with org/user headers and server credentials.

Operational resilience: One observability plane (Prometheus/Grafana). WatchCrux runs independently to keep audits and health checks alive even if the API restarts. Backups + PITR are standard; restore drills are scheduled.

LLM safety: Ingestion paths include a prompt‑injection firewall; risky content is labelled and down‑weighted, not silently dropped.

Tenant isolation (Enterprise): Private Stack provides per‑tenant namespaces, schemas, keys and optional federated proofs (hash‑only verification) strong isolation without losing auditability.

Legal posture (licensing, privacy, money, defences)

Licensing & robots by design. Ingestion honours robots.txt, X‑Robots‑Tag, and captures licence/jurisdiction per artefact; incompatible licences are gated from public reuse (license_ok). We support metadata‑only mode if licence terms are unknown.

GDPR/UK DPA duties baked‑in. Data minimisation, retention windows, DSAR export/erasure workflows, and ledgered deletions are in the baseline checklist.

CRUX credits are not tokens or securities. They are non‑transferable, cost‑indexed participation credits with explicit legal disclaimers. Users retain IP in uploads but grant a platform licence for operational use.

Evidence‑first defence. For any claim, we can present timestamps, quote hashes, licence records, and a signed receipt. Corrections are append‑only: we supersede with new ledger rows; we never back‑date or mutate history.

Disputes, takedowns & corrections

If a result is wrong or disputed

1. Re‑run in audit mode (counterfactuals + receipt). If provenance fails or contradictions meet the policy gate, the answer is rejected or bannered.
2. Open an appeal with evidence; we log a public reason code and re‑weight sources rather than censor.
3. If a source is retracted or edited, our nightly sync updates weights and annotates receipts; downstream answers are refreshed on next run.

Endpoints (public contract)

{
  "GET /v1/trust-report": "Subscores, evidence sets, and reasoned dampings for an answer",
  "POST /v1/appeals": "Submit counter-evidence; track status in UI"
}

Takedowns & DSAR (privacy)

• DSAR export/erasure processes are implemented with 30‑day targets; erasures are ledgered and cascaded to indexes.
• SupportCrux provides a first‑party helpdesk with cited AI answers; every auto‑reply carries answer_id + snapshot_id for audit.

Abuse, gaming & bloat: what happens and what we do

• Sybil/brigading/collusion: We maintain a small user↔device↔IP graph to detect coordination; suspicious clusters are quarantined (weight damped) with signed reasons in the ledger.
• Citation cartels / predatory venues: Venue reputation and retraction lists feed weight dampings; contradictions are labelled in results.
• Duplicate uploads: FactoryCrux dedupes by content hash and records lineage; rewards for duplicates are suppressed by policy.
• Cost abuse: C³ budgets cap compute per mode; OpsCrux shows burn and can auto‑downgrade or pause work.

Operator‑grade assurances (why hostile actors should hesitate)

1. Independent audits: WatchCrux is a separate service that keeps PASS/WARN/FAIL artefacts, ingests metrics, and flags version drift across services. Logs are checksum‑indexed.
2. Integration gates: No deploy without /healthz (build, compat, sdkVersion) and required Prometheus metrics; version drift is detected within ~60s and can trigger auto‑rollback.
3. Backups & DR discipline: PITR for Postgres (≤30 min), ClickHouse nightly, Vault snapshots; monthly restore drills.
4. Append‑only provenance: Tamper attempts are detectable via hash chains and signature checks; audit replays must match stored receipt hashes.

Architecture surfaces that make this work

• Engine (CROWN + QUORUM (MiSES) + C³): receipts, counterfactuals, reputation/time/licence signals.
• WebCrux (UI + BFF): mode badges, provenance indicators, token safety, server‑side headers.
• FactoryCrux (ingestion): robots/licensing/PII gates; dedupe; provenance rows.
• WatchCrux (operator): audits, health/ready, metrics ingest, version drift rules.
• InfraCrux (observability, DR): single Prom/Grafana plane; backups; budget dashboards.
• OpsCrux (control tower): agent budgets, prompts, interop/SLOs, receipts & cost panels.
• ATAM (Auth/Trust/Anti‑Manipulation): bias‑minimising, non‑censoring policy with appeals.
• CRUX economy: verifiable participation credits with legal clarifications.

“If you plan to use CueCrux, what should you tell your legal team?”

Developer & Operator FAQs

“What happens when sources disagree?”

We show both (support + counterfactual), label contradiction, and expose a Trust Report with subscores.

“Can you prove a specific answer was built correctly?”

Yes. Use audit mode to obtain a Receipt and replay it. WatchCrux replays a sample weekly.

“What if a site forbids indexing?”

We honour robots and X‑Robots flags and can switch to metadata‑only mode.

“Who owns uploaded content?”

Uploaders keep IP; the platform has a non‑exclusive licence to operate the service; CRUX is not a royalty.

“How do you stop hammering when a plane is down?”

Integration rules enforce circuit‑breakers, jittered retries and synthetic‑journey SLOs; OpsCrux coordinates rollbacks.

🧾 Example: Trust Report (simplified)

Artefact Example

{
  "answer_id": "ans_01HXYZ",
  "mode": "verified",
  "diversity": 2,
  "evidence_sets": [
    {"id":"evs_1","roles":["support","support"]},
    {"id":"evs_cf","roles":["counterfactual"]}
  ],
  "provenance_ok": true,
  "receipt_id": "rcpt_3ab2",
  "retraction_flags": []
}

Risk & Mitigation Matrix (abridged)

Implementation notes (where these rules live)

• Policies & checklists are baked into the Engine & Infra plans and enforced by tests and dashboards.
• Support flows (tickets, FAQ, triage) carry answer_id/snapshot_id to keep every response auditable.
• SDK discipline: shared types, error models, build/compat, and ed25519 verification helpers ensure client parity.

Glossary