Inspiration
Online creators sometimes encounter profiles that reuse familiar names, phrases, archive claims, or other recognizable signals. Those similarities may be meaningful, but they are not proof of profile ownership, authorization, or impersonation.
AI can help organize ambiguous evidence, but it can also overstate certainty or quietly replace the person who should make the final decision.
I started this project because even with strong guardrails, an AI can still over-interpret weak or mixed signals inside a narrowly bounded task, or express more certainty than the evidence supports. My central question was not whether a model could produce an assessment, but whether the surrounding system could keep uncertainty visible, constrain what that assessment is allowed to mean, and leave the final decision with the creator.
Creator-Controlled Presence Review explores a different model: the AI reviews a strictly bounded evidence packet, while the creator retains control over what the result means and what happens next.
The prototype is an experimental Build Week vertical slice based on pre-existing Sanctuary/CEM trust principles: provenance, uncertainty discipline, data minimization, human control, and review details that the creator can clear.
For a creator, “the model thinks this may be impersonation” can already feel like a verdict. This prototype deliberately treats that output as a review posture, not as authority.
What it does
The application presents a completely synthetic creator, a candidate profile, and a small evidence packet with stable source identifiers.
The review is bounded. It does not browse the web, scan platforms, monitor people, match images, infer location, or retrieve additional information.
GPT-5.6 Sol receives the supplied synthetic packet through Structured Outputs and returns:
- supporting evidence;
- contradicting evidence;
- missing evidence;
- limitations;
- an uncertainty summary;
- a bounded assessment category.
Every supporting, contradicting, or missing-evidence item must cite supplied source IDs.
The local validation layer rejects malformed output, unknown source references, unsupported protected identifiers, quantified confidence claims, identity-as-fact language, and attempts by the model to make the creator's final decision.
The creator then records a separate decision:
- This is mine
- Not mine
- Keep unresolved
- Possible impersonation
The model assessment and creator decision remain separate records and appear as separate actors in the report.
The creator can also clear the evidence, model output, decision, and note. After clearing, only a minimal event skeleton remains, without the review content.
How we built it
The prototype is a standalone FastAPI application using:
- Python and FastAPI;
- Pydantic schemas;
- OpenAI Responses API Structured Outputs;
- GPT-5.6 Sol;
- Jinja2 templates;
- YAML synthetic fixtures;
- an in-memory bounded review store;
- deterministic replay and explicit live modes.
Replay mode makes no API request and provides a stable, clearly labelled walkthrough for recording and review.
Live mode sends the synthetic packet once to GPT-5.6 Sol with store=False, validates the structured response locally, and fails closed before creating a review record if parsing or validation fails.
The repository also contains three single-fact contrastive engineering checks. They change or remove one observation at a time to test whether the structured assessment reacts appropriately while preserving unrelated uncertainty. These checks are not presented as a benchmark or a general accuracy result.
Codex was used throughout the Build Week implementation to inspect the existing architecture, maintain a strict file and repository boundary, implement the standalone vertical slice, extend validation, write regression tests, run security and isolation checks, and produce reproducible local commits.
Challenges
Keeping the creator in control
The most important design constraint was preventing the model assessment from becoming the final judgment about profile ownership, authorization, or possible impersonation. The model can organize evidence and preserve uncertainty, but the creator decision is stored separately and cannot be produced by the model schema.
Avoiding an embedded answer key
An early version included a known_gaps section in the model-facing packet. That made part of the missing-evidence task too easy because the input already described the expected gaps.
We removed that information from the model input and retained expected behavior only in local replay and evaluation fixtures. The current live path therefore requires the model to infer missing evidence from the supplied observations.
Designing fail-closed validation
Validation had to be strict enough to reject unsupported source references and protected identifiers without rejecting every cautious sentence containing words such as “confidence” or “possible impersonation.”
This required targeted regression tests and exact token grounding rather than substring matching.
Separating machine checks from semantic judgment
Some properties are objectively testable: schema validity, known source IDs, stale markers, prohibited categories, and unsupported identifiers.
Other properties, such as whether a host-level link supports a specific profile path, require semantic human review. We document that boundary rather than manufacturing a brittle gold answer.
Privacy versus useful evidence
Removing every identifying or distinctive detail can also remove the information needed to recognize meaningful similarities, paraphrases, and indirect references.
The current prototype avoids pretending this problem is solved. It uses only synthetic data. Privacy architecture for real sensitive evidence remains future work.
Accomplishments
- A working creator-facing evidence-review flow.
- GPT-5.6 Sol Structured Outputs integration.
- Deterministic replay and explicit live modes.
- A successful synthetic live assessment on the current committed path.
- Demonstrated fail-closed behavior when another live output violated local validation.
- Strict source-ID and protected-token checks.
- Separate model and creator records.
- Actor-separated reporting.
- Clear-details behavior with an event-only skeleton.
- Three contrastive engineering cases.
- 33 standalone regression tests.
- Production import isolation.
- Reserved synthetic domains only.
- Reproducible pinned dependencies and a clean standalone launcher.
What we learned
During Build Week, I found that generating a polished model answer was the easy part. The harder engineering problem was defining what the model may cite, what it must not conclude, what its assessment is allowed to mean, and which actions must remain explicitly human.
A useful AI review system needs more than a prompt. It needs bounded inputs, provenance, structured outputs, local validation, explicit uncertainty, human decision ownership, and a clear deletion model.
We also learned that much of a simple evidence case can be handled by deterministic code. The model's value is narrower: restrained synthesis, identifying open questions that were not prewritten, and explaining mixed evidence without collapsing it into false certainty.
The prototype therefore does not claim that a frontier model is necessary for every evidence comparison. Its main engineering contribution is the constraint and human-control layer around the model.
What's next
Future work may include:
- a locally controlled privacy gateway for sensitive evidence;
- stronger semantic grounding checks;
- safe server-side diagnostic reason codes;
- broader contrastive evaluation with human-reviewed cases;
- testing different model and reasoning configurations;
- persistent storage designed around explicit retention choices;
- creator-controlled export and deletion policies.
This prototype does not establish profile ownership, authorization, or impersonation as fact, and it is not ready for use with sensitive real-world creator data.
It is a bounded decision-support tool designed to prepare the creator's decision: it organizes the supplied evidence, highlights supporting and contradicting signals, identifies missing information, and keeps uncertainty visible. The final judgment and any subsequent action remain with the creator.
It demonstrates a narrower idea:
AI can help prepare and support decisions when the evidence is uncertain, without replacing the person who must make them.
Log in or sign up for Devpost to join the conversation.