Document ID: ORVY-COMP-PLAN-001 Status: EXPLORATORY WORKING DRAFT — NOT APPROVED / NOT CANONICAL Prepared: 2026-10-18 Dependencies: ORVY-COMP-CHTR-001, ORVY-COMP-ARCH-001
1. Current instruction
Prioritize ORVY Companion competition preparation over new ORVY Core documentation work without affecting governed ORVY Core admission or the active MHERC 2.0 Codex implementation. Prepare charter, architecture, and web documentation first. Application coding remains blocked until implementation authorization G2.
2. Phase 0 — Define and review
Produce charter, prioritized feature matrix, demo storyboards, safety/privacy boundaries, architecture, acceptance criteria, ownership of source documents, and constraints. Maintain Markdown sources with HTML derivatives. Review before freezing; the current status is exploratory.
3. Phase 1 — Scaffold after G2
Create a separate Companion application repository and SQL database. Scaffold ASP.NET Core MVC / Web API, module boundaries, basic authentication, CI, configuration/secret management, staging IIS deployment, and architecture decision records. No reuse of MHERC business data or databases.
4. Phase 2 — Location discovery vertical slice
Provide mobile-first onboarding, interests, foreground device location with explicit browser permission, manual location selection, and attributed nearby Places results. Validate provider costs, rate limits, and failure handling.
5. Phase 3 — Agent and recommendation
Integrate OpenAI Responses API, backend function tools, structured recommendation schema, evidence checks, deterministic filtering, and useful recommendation explanations. Evaluate hallucination and prompt-injection risk.
6. Phase 4 — Memory and proactivity
Introduce explicit/inferred preference separation, memory editing/deletion, opt-in in-app discovery alerts, notification quiet hours, frequency caps, and feedback-driven suppression. Background location/native delivery remains conditional on demonstrated OS requirements.
7. Phase 5 — Pilot and security verification
Run source-attributed museum, quiet-workspace, consent-revocation, wrong-location, missing-hours, fake-event, health-safety, and denied-permission test cases. Measure relevance, notification fatigue, reliability, latency, and external API consumption.
8. Phase 6 — Competition readiness
Prepare functional demo, explanatory pitch, architecture walkthrough, reproducible simulated-location demonstration, pilot evidence, privacy summary, and submission materials. Verify the current official eligibility, category name, submission deadline, documentation requirements, and live-demo conditions in the organizer's portal rather than assuming historical dates.
9. Proposed priority sequence
- Charter and core use cases.
- Consent and contextual authority model.
- Real nearby-place discovery.
- Evidence-backed reasoning and explanation.
- Personal preference memory with corrections.
- Safe proactive suggestions.
- Health informational fallback / nearby care locator.
- Native background-location capability only if critical and technically feasible.
10. Start criteria for coding
- G0 charter approved and scope measurable.
- G1 architecture approved: storage, API quotas, consent, privacy, safety, and hosting.
- Initial acceptance tests and demo fixtures written.
- App repository and separate development database prepared.
- Secret storage and budget quotas available.
- Human authorization for G2 recorded.
11. Publication and source control
All competition documentation starts as draft in isolated GitHub branch/folder. HTML should always identify draft status. Do not merge into governed portal main or enable automatic publication until reviewed. Changes to Core authority remain excluded. Public release should expose derived text only, not private design history, secrets, raw PII, or unpublished source evidence.
12. Open design questions
- Which foreground location precision and update schedule provide the best privacy/utility trade-off?
- How will consent renewal, deletion, and retention defaults work?
- Which official sources will verify exhibitions and time-sensitive events?
- Which recommendation categories should be pilot-ready?
- Is an Android native shell needed for the final competition demo?
- Which domain/subdomain will host the public Companion documentation?
- Which location/geofence behaviors are allowed under Android/iOS app review policies?
Current gates: G0 OPEN · G1 OPEN · G2 NOT AUTHORIZED.