# Optic: The Problem Is Inference **Formation-stage technical whitepaper - v0.6 rewrite** Optic is a private, local-first identity audit system for consenting users. It helps a person inspect what different audiences, platforms, advertisers, institutions, and future AI agents may infer from their digital traces. It does not define the person. It audits the evidence surface around them. The product contract is simple: source -> signal -> inference -> confidence -> counterargument -> repair. Every finding must show where it came from, what it might imply, who might care, how confident the system is, what weakens the claim, and what the user can do next. This document is not a claim that Optic already has the final model, the final market, or the final legal architecture. It is a formation-stage doctrine and build spec: what Optic is, what it refuses to become, what can be built now, and what would need to be proven before the 2030 version exists. ## 1. Thesis: What Optic Is Optic is a user-side audit layer for inferred identity. The core object is not a score, a personality profile, or a compliance badge. The core object is a repairable inference: a claim about how some audience might read the user from evidence currently available to that audience or supplied by the user. The product exists because identity is no longer only self-presentation. It is also assembled by search results, public posts, profile fragments, broker files, ad categories, financial metadata, documents, images, and machine-readable traces. Optic gives the subject a way to inspect that assembly without turning them into another productized dossier. The important distinction: Optic never says, "this is who you are." It says, "given this source, this signal, and this audience lens, this is a plausible reading, with these caveats, risks, and repair paths." That difference is the company. ## 2. One-Sentence Definition Optic turns user-authorized data into evidence-backed inference cards that show what a person's digital traces may signal, to whom, with what confidence, and what can be repaired. The sentence matters because it prevents category drift. Optic is not a data broker, reputation bureau, AI therapist, social credit layer, employer screen, or dating score. It is a mirror with receipts. A card is valid only if it has six fields: source, signal, inference, audience, confidence, and repair. If any field is missing, the system should mark the result incomplete rather than hiding the uncertainty behind fluent language. ## 3. The World Optic Assumes Optic assumes that people are increasingly read through fragments. A recruiter may read a LinkedIn gap one way. A stranger may read an old post another way. An advertiser may classify intent from browsing behavior. A bank, landlord, insurer, school, or employer may rely on structured records, third-party reports, or automated review systems. The point is not that every system knows everything. The point is worse and more practical: many systems know partial things, and partial things can still affect price, trust, access, visibility, and opportunity. Optic treats modern identity as an evidence environment. The user lives inside it but rarely sees the environment as a system. Optic's first job is to render the environment visible without exaggerating its completeness. ## 4. Algorithmic Identity Already Exists Algorithmic identity is the operational model others form from a person's traces. It does not need to be metaphysically true to matter. A low-confidence category can still shape an ad, a search result, a fraud flag, an underwriting question, or a human first impression. Optic should be careful with language here. Platforms may infer; advertisers may classify; institutions may screen; people may judge. Optic should not claim secret access to proprietary models it cannot inspect. The product's useful claim is narrower: from the evidence available, Optic can estimate plausible readings, compare them across audiences, and show the user where those readings are strong, weak, stale, misleading, or repairable. ## 5. The Invisible Data-Shadow A data-shadow is the external shape cast by a person's traces. It is not the person. It is the pattern left behind when their life is compressed into records, posts, metadata, accounts, photos, payments, forms, and searchable fragments. The danger of the metaphor is mysticism. Optic should not imply that the shadow is total, hidden, or omniscient. A better product version is brutally specific: this source exists, this signal is visible, this audience may read it this way, and this source gap limits the conclusion. The user value is immediate. People already clean resumes, curate public profiles, remove broker listings, manage credit, and worry about screenshots. Optic unifies those instincts into one audit loop. ## 6. Why Users Cannot Inspect or Repair It Most privacy tools answer the wrong layer. They help users download data, delete accounts, block trackers, freeze credit, or remove listings. Those are useful, but they do not show the inference chain. A user can know that a platform has their activity history without knowing what that activity implies. They can remove a broker listing without seeing what other surfaces still support the same reading. They can edit a profile without knowing whether the ambiguity was solved or merely moved. Repair requires three things: visibility into the source, translation into audience-specific meaning, and a concrete next action. Optic is built around that triad. ## 7. Existing Tools Are Fragmented Credit monitoring tracks credit files. Data removal services chase broker listings. Search cleanup tools manage discoverability. Password managers secure accounts. Privacy browsers limit collection. Reputation tools polish public surfaces. Optic sits between those categories. It does not replace them. It explains how their outputs compose into identity readings. The wedge is not "privacy dashboard." That category is too broad and too passive. The wedge is inference legibility: what am I currently signaling, who might read it, what is wrong, and what should I do first? ## 8. What Optic Does Optic ingests consented sources, stores or processes them under a local-first model, extracts signals, maps signals into candidate readings, and renders an audit report. The report does not just say "risk." It says: this profile says X, this old post suggests Y to a recruiter lens, this missing context weakens the claim, this financial artifact is too sensitive for cloud processing, this broker listing should be removed, this ambiguity is harmless, and this one should be clarified. The product loop is import -> parse -> classify -> explain -> repair -> re-audit. If the user cannot inspect or contest a finding, the finding should not ship. ## 9. What Optic Does Not Do Optic does not generate public scores, employer dashboards, dating rankings, credit judgments, tenant screens, insurance eligibility predictions, school admissions predictions, criminality labels, or dossiers on non-consenting people. This refusal is not branding. It is category defense. The fastest way to destroy Optic is to make it useful for judging other people at scale. The product must hard-code this boundary. No batch lookup. No "rate my employee." No "scan this person." No hidden buyer dashboard. No non-user identity graph. The subject must be the customer, not the raw material. ## 10. User Doctrine: Ownership, Consent, Revocation Optic starts with the subject. The user chooses what sources to include, what purpose the audit serves, what stays local, what can be temporarily processed, what can be deleted, and what can be exported. Consent must be operational, not decorative. A checkbox is not enough. Each source needs a scope, sensitivity level, retention rule, processing boundary, deletion path, and export warning. Revocation must be visible. If the user deletes a source, Optic should show what findings depended on it, what cached outputs remain, and what can no longer be supported. The audit should degrade honestly when evidence disappears. ## 11. Primary Users and First Wedge The first users are people whose opportunities depend on being read correctly: founders, creators, job seekers, students, public-facing professionals, and anyone entering a high-stakes evaluation moment. This wedge is emotionally obvious and commercially testable. A founder wants to know what investors see. A job seeker wants to know what recruiters infer. A creator wants to know whether their public surface signals credibility, chaos, expertise, risk, or inconsistency. The first paid product should probably be an assisted audit, not a fully automated app. The earliest trust will come from a sharp report, a narrow source set, and a before/after repair loop. ## 12. Primary Use Cases The core use case is a question: "What would this audience infer from my current evidence?" The first lenses should be practical: recruiter, investor, stranger, search, advertiser, and institution-adjacent. Each lens should inspect the same evidence differently. A gap in employment history may matter to a recruiter, not to an advertiser. A public political joke may matter to a stranger, not to a credit bureau. A messy search result may matter to an investor, not to a platform model. The product becomes powerful when it separates audience logic instead of collapsing everything into one universal score. ## 13. The Optic Audit An Optic audit is a bounded procedure. The user states a goal, selects sources, approves processing, reviews extracted signals, receives inference cards, and chooses repair actions. The audit should begin narrow: public web, profile links, user-uploaded files, screenshots, and manually supplied context. Later versions can support platform exports, email, browser data, financial records, device metadata, and deeper local parsing only after the safety model is proven. A good audit is not maximal. A good audit is proportionate. More data is not always more truth; sometimes it is just more liability. ## 14. The Optic Report The report is the visible artifact. It should read less like a personality test and more like a forensic interface. Each finding should include: claim, audience, source, evidence span, confidence band, counterargument, sensitivity, repair action, and status. The report should also include source gaps: what Optic did not see, what it cannot know, and what would change the conclusion. Export is dangerous. A report can become coercive evidence if a school, employer, partner, parent, or institution demands to see it. Optic should support selective export, watermarking, and warnings by default. ## 15. Human / Audience Mirrors Human mirrors estimate how people may read the user. This includes strangers, recruiters, investors, journalists, peers, dates, collaborators, and critics. The model should not pretend people are rational. Human reading is noisy, status-sensitive, context-dependent, and often unfair. That is why Optic should frame these findings as "possible audience readings," not truth claims. The repair layer matters most here. The answer is not always deletion. Sometimes it is adding context, separating audiences, making a stronger public anchor, clarifying a timeline, or doing nothing because the supposed risk is not worth self-erasure. ## 16. Platform and Advertiser Mirrors Platform and advertiser mirrors estimate how commercial systems may classify the user from behavior, profile data, interests, purchases, clicks, follows, exports, and visible activity. This must be written with precision. Optic can compare user-supplied platform exports, ad preference dashboards, public signals, and known industry practices. It cannot claim to know TikTok's, Meta's, Google's, or any other platform's internal model unless the user provides actual records or the platform exposes them. The product value is still real. Even a plausible advertiser mirror can show the user which signals are shaping their machine-readable persona, which categories are sensitive, and which assumptions are unsupported. ## 17. Institutional Mirror Boundaries Institutional mirrors are the most legally radioactive part of Optic. Banks, insurers, landlords, schools, employers, and government-adjacent systems can make eligibility decisions. Optic must not become a consumer reporting agency by accident. The safe version is educational and user-side. Optic can say: this source may be relevant in an employment context, this discrepancy may create confusion, this public record should be checked, this document is sensitive, this claim should not be exported. The unsafe version predicts whether a landlord, lender, employer, or insurer will accept the user. That version should be refused unless the company deliberately enters that regulated domain with counsel, licensing, compliance, and a different product architecture. ## 18. Contradiction Layer Contradiction is where the user's evidence points in different directions. A resume says one thing, LinkedIn says another. A founder bio signals discipline, public posts signal volatility. A bank statement shows stability, search results suggest chaos. Contradiction is not moral failure. It is an interpretation problem. Optic should show which audience might care, what source creates the conflict, how severe it is, and whether the conflict is truthful complexity or accidental confusion. This layer is one of Optic's best product differentiators. Most tools clean surfaces. Optic can explain when surfaces disagree. ## 19. Risk Layer Risk is a plausible negative reading that conflicts with the user's goals. It depends on audience, visibility, sensitivity, recency, confidence, and repairability. Optic should not maximize fear. It should triage. A high-visibility, high-confidence, easily repairable issue should come before a speculative, low-visibility, emotionally charged issue. The product should reduce panic by sorting action. Risk language must stay bounded: possible, plausible, unsupported, sensitive, stale, contradicted, repairable, not repairable, not worth acting on. The worst version of Optic makes users neurotic. The good version gives them control. ## 20. Coherence Layer Coherence means the evidence can be understood in context. It does not mean blandness, obedience, professionalism cosplay, or algorithmic conformity. A coherent surface lets the right audience understand the user's intent. A chaotic surface leaves important claims to be reconstructed from fragments. Optic's job is not to flatten the user; it is to show where the available evidence fails to carry the intended meaning. This distinction should be explicit in the product. "Clarify" is different from "sanitize." "Separate audiences" is different from "hide yourself." "Add context" is different from "perform acceptability." ## 21. Repair Layer Repair is source-aware action. It can mean deleting, redacting, clarifying, separating, opting out, freezing, contesting, publishing context, changing privacy settings, updating profiles, or leaving the record alone. Every repair action should have effort, risk, reversibility, verification, and expected impact. "Delete this" is not always safe. "Clarify this" may be better. "Do nothing" should be a first-class outcome. The repair layer is where Optic becomes more than a mirror. The user does not just learn what their data says. They learn which parts can be changed, which should be left alone, and which require outside process. ## 22. Data Source Philosophy Optic should not collect everything by default. A source is worth ingesting only when its inference value justifies its sensitivity, storage risk, legal risk, and user burden. The source ladder should start with low-risk, high-interpretability data: public profiles, user-supplied links, uploaded resumes, screenshots, and search results. Then move to platform exports, ad dashboards, people-search listings, email, financial files, browser history, device metadata, and deep local logs only after clear value is proven. The governing rule: source hunger is surveillance in disguise. Optic should win by extracting more meaning from fewer sources before asking for the intimate stuff. ## 23. Data Source Matrix Every source should be classified before ingestion. The matrix should include source type, access method, sensitivity, retention, local/cloud boundary, parsing method, inference value, failure mode, deletion path, and legal review status. Example: a LinkedIn URL is low sensitivity, public, easy to parse, useful for recruiter/investor mirrors, and easy to re-scan. A bank export is high sensitivity, local-only, useful for stability or financial-context audits, and dangerous to retain. Email is extremely rich but high-risk because it contains third-party data and private communications. This matrix should drive the product roadmap. Sources should not be added because they sound powerful. They should be added because they pass a value-to-risk gate. ## 24. Consent and Permission Model Consent should be attached to purpose. "Analyze my public founder surface for investor perception" is different from "analyze my emails for relationship coherence" or "analyze my bank transactions for institutional risk." The permission model should include source-level consent, purpose-level consent, retention period, local/cloud boundary, export permissions, and revocation. The user should be able to see a consent receipt for each source. This matters because Optic's trust architecture is not just encryption. It is legibility. The user should always know what was processed, why it was processed, what it produced, and how to destroy it. ## 25. Local-First Architecture The default architecture is local-first. Raw personal data should live on the user's device whenever possible. Cloud assistance should be treated as an exception requiring minimization, redaction, and explicit purpose. The local app should maintain a vault, parser, source ledger, identity graph, inference cache, report renderer, and deletion ledger. Sensitive sources should never leave the device unless the user explicitly chooses a cloud-assisted mode. Local-first is not just a privacy claim. It is product positioning. Optic can only ask for intimate sources if the user believes the company is structurally prevented from exploiting them. ## 26. Cloud Assist Boundary Cloud assist exists for tasks that are too heavy, too fresh, or too connected for the device alone: public web search, source discovery, large model reasoning, deduplication, or report drafting. The boundary must be visible. The app should show when a task is local, when it is cloud-assisted, what data is sent, whether it is redacted, how long it persists, and whether the output can be reproduced locally. The safest pattern is ephemeral orchestration: send the minimum needed, avoid raw vault upload, return structured results, and delete transient state. Cloud should enhance the audit, not become the real vault. ## 27. Neuontology Engine Neuontology is the backend inference engine: the system that turns traces into structured readings without pretending those readings are final truth. The pipeline is: raw source -> artifact -> extracted signal -> normalized feature -> candidate inference -> audience lens -> confidence band -> counterargument -> repair action. The engine should preserve provenance at every step. Neuontology should not begin as a giant model. It should begin as a schema plus rules plus small models plus human review. The moat is not "we ran an LLM on your life." The moat is an auditable ontology of identity signals, audience readings, source sensitivity, and repair logic. ## 28. Identity Graph The identity graph is the internal map connecting users, accounts, platforms, artifacts, signals, inferences, audiences, risks, and repairs. A good graph keeps evidence and interpretation separate. A post is not a trait. A purchase is not a personality. A missing profile field is not a defect. Each edge should state what it connects, why it exists, how confident it is, and which audience lens uses it. This graph enables re-audits. When the user deletes a source, adds context, updates a profile, or removes a broker listing, Optic can show which findings changed and which remained. ## 29. Signal and Inference Taxonomy Signals are observable traces. Inferences are claims derived from signals under context. The taxonomy should keep them separate. Signals may include recency, frequency, inconsistency, omission, visibility, sentiment, affiliation, credential, transaction category, public association, search prominence, profile completeness, and source reliability. Inferences may include credibility risk, expertise signal, volatility signal, financial stability signal, audience mismatch, privacy exposure, or contradiction. Sensitive inferences need gates. Health, sexuality, religion, politics, race, disability, minors, finances, criminality, immigration, and intimate relationships should be blocked, minimized, or handled only under explicit safe contexts. ## 30. Evidence, Confidence, Explainability Every inference should be explainable without asking the user to trust the model. The user should see the evidence span, the reasoning path, the confidence band, and the counterargument. Confidence should not be a fake percentage. Better bands: weak, plausible, strong, contradicted, stale, unsupported, sensitive, disallowed. These labels are easier to understand and harder to overinterpret. Explainability is also a safety feature. If the model cannot explain why it made a finding, the user cannot repair it, and Optic should not ship it as a finding. ## 31. Report Schema A report should have scope, source ledger, audience lenses, findings, assumptions, source gaps, refusals, repair queue, export policy, and deletion controls. Each finding should include: title, claim, audience, source IDs, evidence spans, signal class, confidence band, caveat, counterargument, sensitivity class, repair action, and verification state. The schema matters because it keeps the product from becoming prose sludge. Optic should produce structured objects first and narrative explanation second. ## 32. Repair Action Schema A repair action should include target, action type, reason, expected effect, effort, risk, reversibility, verification method, and follow-up date. Action types include clarify, redact, separate, update, delete, opt out, freeze, contest, publish context, change permissions, monitor, or do nothing. "Do nothing" matters because not every uncomfortable reading deserves action. The schema should also flag destructive actions. Deleting a source, changing a public claim, or contesting a record may create consequences. Optic should make the tradeoff visible before the user acts. ## 33. MVP Scope The weekend MVP should prove the loop, not the entire vision. The first version can be a local web app or iPhone prototype where a user imports a small bundle of sources and receives inference cards. Minimum source set: public profile links, one uploaded resume/bio, screenshots or copied text, public search snippets, and manual context. Minimum output: source ledger, three audience lenses, ten inference cards, confidence bands, counterarguments, and repair actions. The MVP is successful if a user says, "I did not realize this is what I was signaling, and now I know exactly what to change." ## 34. Technical Stack and Model Strategy The first stack should be boring. Use a local-first frontend, encrypted local storage, structured JSON schemas, deterministic parsers where possible, and small local models for classification or summarization. For mobile, the long-term direction is Swift, Core ML, Keychain/Secure Enclave-backed storage, and a small on-device model. For the weekend, a web prototype with local storage, file import, manual source entry, and an LLM-assisted report generator is enough. The model strategy should be layered: rules for safety, embeddings for retrieval, small local models for classification, larger models for optional cloud assist, and human review for early paid audits. ## 35. Threat Model Optic handles dangerous data. Threats include stolen devices, cloud leakage, prompt injection, malicious uploaded files, screenshots, coerced exports, abusive partners, employers demanding reports, future acquirer incentives, and the company itself drifting toward buyer-side scoring. The safety design should assume that the report may be misused. It should include local encryption, source minimization, export warnings, selected sharing, watermarking, sensitive inference gates, refusal modes, and deletion receipts. The hardest threat is not a hacker. It is incentives. If Optic's best monetization path becomes selling judgment tools to institutions, the product has failed its founding premise. ## 36. Abuse Prevention and Refused Features The refused feature list should be public. No non-consenting dossiers. No batch search. No public leaderboards. No employer screen. No dating score. No "is this person safe?" lookup. No eligibility prediction. No hidden data resale. No API for third-party judgment. Abuse prevention also needs interface rules. The app should reject prompts asking to analyze another person without consent, infer protected traits, rank people, generate blackmail, or optimize deception. Optic can still support self-audit. The distinction is consent plus control. The subject can inspect their own surface. Others cannot weaponize Optic against them. ## 37. Regulatory Surface Optic touches privacy, consumer protection, data portability, biometrics, financial data, minors, employment screening, credit reporting, and AI governance. The exact legal exposure depends on sources, users, outputs, exports, and customers. The safest early posture is user-side, educational, local-first, non-eligibility, non-decisioning, and narrow-scope. Anything involving employment, credit, housing, insurance, or education requires counsel before productization. The regulatory thesis should be humble: Optic can be built safely only if it refuses certain markets, treats sensitive data carefully, and separates self-understanding from institutional judgment. ## 38. Competitive Landscape and Business Model Optic competes across fragments: data removal, reputation management, credit monitoring, privacy tools, personal AI, search cleanup, and identity protection. Its differentiated category is inference audit plus repair. Near-term monetization should be user-paid audits: founder audit, job seeker audit, creator audit, public profile audit, and premium re-audit. This avoids the poison of selling the user's data before trust exists. Later monetization could include local app subscription, paid repair workflows, privacy partner referrals, verified consent receipts, or user-controlled data licensing. But data resale should not be the default pitch. The trust cost is enormous. ## 39. Roadmap and Validation Agenda The validation agenda should be concrete. First, prove that users care after seeing an audit. Second, prove that repair actions change the surface. Third, prove that the source set can expand without destroying trust. Fourth, prove that local-first architecture can handle enough data to be useful. Milestones: weekend MVP, five manual audits, ten paid audits, source matrix, safety policy, local vault prototype, mobile proof, repeat audit loop, and a small validation study comparing audience readings before and after repair. The investor story is not "we built social credit for yourself." It is: inferred identity already affects people, existing tools are fragmented, and Optic is the private user-side control panel for seeing and repairing that layer. ## 40. 2030 Thesis By 2030, more of life will be mediated by AI agents, automated screening, personalized feeds, generated search, identity graphs, and machine-readable context. People will not only ask, "what do humans think of me?" They will ask, "what do systems think I am?" Optic's long-term version is a personal glass box for algorithmic identity. It lets the user inspect, simulate, contest, and repair the machine-readable version of themselves across audiences and contexts. The future is not inevitable. Optic only deserves to exist if the early product proves the trust loop: consented sources, local control, evidence-backed inferences, refusal boundaries, and real repair. The 2030 vision is earned by refusing the easy evil version now. # Appendices ## Appendix A: Glossary - Source: Any user-authorized artifact, record, profile, export, link, screenshot, file, or data stream used in the audit. - Signal: An observable trace extracted from a source. - Inference: A claim derived from signals under an audience and context. - Audience lens: A model of how a recruiter, investor, stranger, advertiser, platform, or institution-adjacent reader may interpret evidence. - Repair action: A source-aware step that can clarify, remove, separate, contest, or monitor a finding. ## Appendix B: Source Matrix Fields - Source type, access method, owner, sensitivity, retention rule, local/cloud boundary, parser, inference value, failure mode, deletion path, legal review status, MVP status. ## Appendix C: Identity Graph Objects - User, account, platform, artifact, source, signal, inference, audience lens, confidence band, counterargument, repair action, verification event, deletion receipt. ## Appendix D: Inference Classes - Weak, plausible, strong, contradicted, stale, unsupported, sensitive, disallowed, speculative, user-confirmed, user-contested. ## Appendix E: Report Sections - Scope, sources, assumptions, audience lenses, findings, source gaps, contradictions, sensitive refusals, repair queue, export warning, deletion controls. ## Appendix F: Repair Actions - Clarify, redact, separate, update, delete, opt out, freeze, contest, publish context, change permissions, monitor, do nothing. ## Appendix G: Threat Model - Stolen device, coerced export, cloud leakage, prompt injection, malicious file, screenshot misuse, intimate partner abuse, employer misuse, buyer-side drift, acquirer incentive drift. ## Appendix H: Safety Policy - No third-party dossiers. No public scores. No eligibility outputs. No batch lookup. No protected-trait inference. No coercive export defaults. No hidden data resale. ## Appendix I: MVP Screens - Consent screen, source import, source ledger, audience selector, inference cards, evidence drawer, repair queue, export warning, delete vault. ## Appendix J: Open Questions - Which first wedge pays fastest? Which source mix creates the strongest holy-shit moment? What repairs are measurable? What can run locally on iPhone? Which source types are too dangerous for v1? What legal lines require hard refusal? ## Master Claim Ledger ### CL-001 — FACT Opaque commercial profiles already exist around people. Sources: Data Brokers: A Call for Transparency and Accountability; A Look Behind the Screens. Caveat: Use as problem evidence, not as proof Optic exists. Forbidden overclaim: Do not imply any cited agency endorses Optic. ### CL-002 — FACT Digital traces can support sensitive or mistaken inferences. Sources: Surveillance Pricing Study; California Consumer Privacy Act. Caveat: Cite narrowly. The claim is about possibility and risk. Forbidden overclaim: Do not say Optic can reproduce every outside model. ### CL-003 — FACT Inferences can be personal information or regulated profiling. Sources: California Consumer Privacy Act; General Data Protection Regulation. Caveat: Treat inference outputs as sensitive product objects. Forbidden overclaim: Do not flatten jurisdiction-specific law into universal law. ### CL-004 — FACT Eligibility use can trigger consumer-reporting risk. Sources: Employment Background Screening and the FCRA. Caveat: Block employer, lender, landlord, insurer, and school surfaces. Forbidden overclaim: Do not call Optic a background-check or eligibility product. ### CL-005 — DESIGN_DECISION Optic is user-side by default. Sources: Employment Background Screening and the FCRA; California Consumer Privacy Act. Caveat: No buyer dashboard, batch lookup, or non-user dossier. Forbidden overclaim: Do not ship third-party scoring. ### CL-006 — DESIGN_DECISION Local-first is the trust architecture. Sources: Keychain Data Protection; Core ML. Caveat: Raw artifacts, graph state, report cache, and keys stay local. Forbidden overclaim: Do not make cloud the hidden default. ### CL-007 — DESIGN_DECISION Optic scores surfaces, not people. Sources: Four Principles of Explainable Artificial Intelligence; AI Risk Management Framework. Caveat: Allowed scores cover legibility, exposure, repair, and confidence. Forbidden overclaim: Do not create a moral, worth, dating, or universal rank. ### CL-008 — DESIGN_DECISION Every inference needs evidence, confidence, audience, and repair. Sources: PROV-O: The PROV Ontology; Four Principles of Explainable Artificial Intelligence. Caveat: Render each claim as a traceable card, not a loose paragraph. Forbidden overclaim: No source, no factual claim. ### CL-009 — RISK Exported reports can become coercive evidence. Sources: Employment Background Screening and the FCRA; General Data Protection Regulation. Caveat: Use warnings, selected export, re-auth, and watermarking. Forbidden overclaim: Do not make full report export the casual default. ### CL-010 — RISK Sensitive inference can harm even when technically accurate. Sources: California Consumer Privacy Act; General Data Protection Regulation. Caveat: Health, religion, sexuality, politics, biometrics, minors, exact location, and financial vulnerability need gates or refusal. Forbidden overclaim: Do not label protected traits as settled facts. ### CL-011 — THESIS The next privacy category is inference legibility plus repair. Sources: Data Brokers: A Call for Transparency and Accountability; Data Defense: People-Search Site Removal Services. Caveat: Frame as thesis until pilots show demand. Forbidden overclaim: Do not claim deletion is obsolete. ### CL-012 — THESIS The first wedge is public-facing people whose opportunities depend on being read correctly. Sources: NEEDS_SOURCE. Caveat: Needs interviews and paid-pilot data. Forbidden overclaim: Do not claim broad consumer inevitability yet. ### CL-013 — NEEDS_SOURCE Repair actions improve external perception after publication. Sources: NEEDS_SOURCE. Caveat: Requires before/after tests and blinded rating. Forbidden overclaim: Do not promise repair outcomes. ### CL-014 — NEEDS_SOURCE A local vault increases user trust enough to affect conversion. Sources: NEEDS_SOURCE. Caveat: Requires user research. Forbidden overclaim: Do not sell trust as measured until measured. ## Source Ledger ### Data Brokers: A Call for Transparency and Accountability Publisher: Federal Trade Commission. Year: 2014. Support: Data brokers create transparency and control gaps. https://www.ftc.gov/reports/data-brokers-call-transparency-accountability-report-federal-trade-commission-may-2014 ### A Look Behind the Screens Publisher: Federal Trade Commission. Year: 2024. Support: Major platforms can collect, retain, share, and monetize broad data. https://www.ftc.gov/news-events/news/press-releases/2024/09/ftc-staff-report-finds-large-social-media-video-streaming-companies-have-engaged-vast-surveillance ### Surveillance Pricing Study Publisher: Federal Trade Commission. Year: 2025. Support: Personal data can affect targeted prices or offers. https://www.ftc.gov/news-events/news/press-releases/2025/01/ftc-surveillance-pricing-study-indicates-wide-range-personal-data-used-set-individualized-consumer ### California Consumer Privacy Act Publisher: California Department of Justice. Year: 2024. Support: The CCPA includes inferences and sensitive personal information. https://oag.ca.gov/privacy/ccpa ### General Data Protection Regulation Publisher: European Union. Year: 2016. Support: Profiling and automated decisions carry rights and safeguards. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng ### Employment Background Screening and the FCRA Publisher: Federal Trade Commission. Year: current. Support: Eligibility reports can trigger consumer-reporting duties. https://www.ftc.gov/business-guidance/resources/what-employment-background-screening-companies-need-know-about-fair-credit-reporting-act ### AI Risk Management Framework Publisher: NIST. Year: 2023. Support: AI risks should be governed, mapped, measured, and managed. https://www.nist.gov/itl/ai-risk-management-framework ### Four Principles of Explainable Artificial Intelligence Publisher: NIST. Year: 2021. Support: Explanations need meaning, accuracy, and knowledge limits. https://www.nist.gov/publications/four-principles-explainable-artificial-intelligence ### PROV-O: The PROV Ontology Publisher: W3C. Year: 2013. Support: Provenance can model entities, activities, agents, and derivation. https://www.w3.org/TR/prov-o/ ### Verifiable Credentials Data Model v2.0 Publisher: W3C. Year: 2025. Support: Secured claims can carry issuers, subjects, evidence, and status. https://www.w3.org/TR/vc-data-model/ ### Decentralized Identifiers v1.0 Publisher: W3C. Year: 2022. Support: Identifiers can separate subject, controller, and proof of control. https://www.w3.org/TR/did-core/ ### Data Defense: People-Search Site Removal Services Publisher: Consumer Reports. Year: 2024. Support: Removal services help, but results vary and need maintenance. https://innovation.consumerreports.org/new-report-data-defense-evaluating-people-search-site-removal-services/ ### Keychain Data Protection Publisher: Apple Platform Security. Year: current. Support: Vault keys should use platform key-protection primitives. https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web ### Core ML Publisher: Apple Developer. Year: current. Support: On-device models can run across Apple compute targets. https://developer.apple.com/machine-learning/core-ml/ ### Foundation Models Publisher: Apple Developer. Year: current. Support: On-device language tasks are possible where device support exists. https://developer.apple.com/documentation/FoundationModels ### Structured Outputs Publisher: OpenAI. Year: current. Support: Cloud assist should return schema-bound output when used. https://platform.openai.com/docs/guides/structured-outputs ## Source Gaps - Exact market size and revenue claims. - First wedge selection without paid-pilot interviews. - Human perception simulation accuracy. - Advertiser profile simulation accuracy. - Repair action effectiveness. - Shame and agency outcomes. - Local vault conversion impact. - Legal status of every importer and scraping path. - FCRA exposure from user-shared reports despite warnings.