-
-
Explainable synthetic decision candidate with evidence, uncertainty, deadline, and no external effect.
-
Gate A safety boundary: live Calendar permission and reads are blocked.
Inspiration
Calendars are good at storing events, but the recurring burden remains with the owner: noticing what changed, connecting it to existing commitments, and deciding whether action is needed now. OpenCarita explores a disciplined product question:
Of all the changes in my life, what do I need to know or decide now, and why?
The goal is not another archive or noisy dashboard. It is a small, evidence-backed decision queue that stays quiet when no decision is needed.
What it does
The current public Gate A prototype demonstrates one narrow Calendar scenario using only compiled synthetic data. A deterministic engine establishes a baseline with two non-overlapping synthetic events. In a later observation, one event changes time and creates a positive-length overlap.
OpenCarita turns that change into one reviewable decision candidate containing:
- the reason the item matters
- evidence linked to the synthetic observations
- a decision deadline
- explicit uncertainty
- a recommended next step
- a clear boundary stating that no Calendar write or external effect can occur
The interface also makes the safety boundary visible. Live Calendar permission, Calendar lists and events, network access, personal data, LLM calls at runtime, and external actions are blocked or absent.
How I built it
OpenCarita is a native macOS prototype built with Swift, SwiftUI, Xcode, and Swift Package Manager.
The implementation separates three responsibilities:
- A sandboxed SwiftUI app using compiled fixtures and memory-only state.
- A deterministic Calendar core with versioned projections, idempotent observation, canonical decision pairs, supersession, atomic state handling, and fail-closed deletion.
- A held EventKit SDK compatibility probe that always returns a Gate B error and is not linked into the app.
The public repository includes 40 synthetic tests, build and test instructions, an architecture document, provenance notes, and an MIT license.
OpenCarita was designed, implemented, tested, reviewed, and packaged in the ChatGPT Codex Desktop app using GPT-5.6. Codex helped translate product and safety constraints into SwiftUI code, deterministic fixtures, tests, build verification, documentation, and the public release.
Challenges
The hardest challenge was useful restraint. A personal assistant can easily become a noisy dashboard, hide uncertainty, or blur the line between suggesting an action and executing it.
The prototype therefore treats evidence, uncertainty, source authority, permission state, and external-effect boundaries as first-class product elements. It also fails closed: the public app cannot silently cross from synthetic demonstration into live Calendar access.
A second challenge was making source-state behavior deterministic and testable. Stable digests, idempotent observations, canonical pair ordering, supersession, corruption detection, and deletion recovery were implemented and exercised entirely with fictional fixtures.
Accomplishments
- A signed and sandboxed native macOS prototype
- A visible synthetic-only safety boundary
- A deterministic baseline-to-observation decision flow
- Explainable decision candidates with evidence and uncertainty
- 40 synthetic tests
- No EventKit runtime link in the app
- No personal data, network service, or external effect
- A separately authored public repository with documented provenance
What I learned
The most important product lesson is that a useful personal system should reduce decision cost, not maximize collected data or generated summaries. Silence is a valid output.
The main engineering lesson is that safety claims are strongest when they are structural and testable: remove live entry points from the app, keep fixtures synthetic, separate compatibility probes, and verify the resulting binary and state transitions.
What's next
OpenCarita is not a production personal-data system. The next step is to validate the decision-queue value with users and, only under a separately reviewed Gate B contract, evaluate live Calendar access with explicit permission, stable code-signing identity, source activation rules, and owner-controlled deletion.
Future expansion would add only sources with clear decision value and verified platform access. Any external data transfer or real-world action would require a separate privacy and effect authorization boundary.
Log in or sign up for Devpost to join the conversation.