CovCare V6.0 / Enterprise reference

Architecture & trust boundaries

Conceptual public-safe layers, information classes and approval gates. No private data, credentials, protected audit catalog or live system access.

Proposed design, not organizational approval or operational evidence. Public fictional demonstrations only; no sensitive information, live submissions or authority changes.

Youth choice

Public discovery → explicit goal approval

Trust-scoped human coordination

Current assignment → minimum necessary task

Verified reporting

Evidence → privacy review → permitted aggregate

Private reflections and restricted clinical notes do not flow into general coordination or executive reporting.

Prototype

ARCH-01 · Presentation layer

Id: ARCH-01
Status: Prototype
Boundary: Public youth discovery, explicit fictional practice, executive documentation and separate private account views.
Inputs: Public authored content; practice is local memory only.
Outputs: Navigation, proposed decisions and print/export documents; no authority is conferred.
Gate: A screen, menu or URL never establishes permission.
Dependencies: Accessible interfaces, professional language review and separately approved deployment.

Contained; positive lifecycle unverified

ARCH-02 · Identity and authorization

Id: ARCH-02
Status: Contained; positive lifecycle unverified
Boundary: Private-ID account lifecycle and independent Trust permissions, assignments, MFA and privileged provisioning.
Inputs: Verified caller identity and current scoped permission.
Outputs: Allow or deny only the authorized task; no staff override on youth owner-only policies.
Gate: Server/database checks, current role and assignment, verified activation, independent approvals and launch review.
Dependencies: Approved scoped lifecycle, revocation, recovery and cross-account tests; no synthetic production identities.

Proposed

ARCH-03 · Workflow coordination

Id: ARCH-03
Status: Proposed
Boundary: Human intake, triage, navigator assignment, referrals and supervised follow-up.
Inputs: Minimum necessary consented support request.
Outputs: Scoped task and verified outcome summary; referral does not equal delivery.
Gate: Current recipient eligibility, purpose, youth consent and qualified human judgment.
Dependencies: Staffing, safeguarding, training, vetted provider scope and recoverable operational services.

Classification unknown; backend changes blocked

ARCH-04 · Data and privacy

Id: ARCH-04
Status: Classification unknown; backend changes blocked
Boundary: Public content, temporary practice, youth-owned goals, separate private reflections, restricted clinical/financial evidence and audit.
Inputs: Only lawful purpose-limited information.
Outputs: Authorized owner/task views and privacy-reviewed aggregates; public documents read no account tables.
Gate: Owner-only youth access, separate clinical boundary, grants/RLS and retention/deletion review.
Dependencies: Classification attestation, actual backups, tested recovery and explicit migration approval.

Planned; live channels unconfigured

ARCH-05 · Integration boundary

Id: ARCH-05
Status: Planned; live channels unconfigured
Boundary: Future vetted communication, resource-provider and finance integrations; current AI/human examples are scripted.
Inputs: Only approved selected context and task identifiers; credentials remain server-only.
Outputs: Verified delivery/receipt evidence only after independent review.
Gate: Caller verification, scoped authorization, consent, provider contracts and independent finance duties.
Dependencies: Provider approval, monitoring, failure recovery and separate activation approval. No real phone number is supplied.

Proposed

ARCH-06 · Reporting and organizational intelligence

Id: ARCH-06
Status: Proposed
Boundary: Validated program evidence transformed to privacy-safe indicators.
Inputs: Authorized evidence with definitions, missingness and provenance.
Outputs: Suppressed aggregates for approved audiences, never youth histories or contributor identities.
Gate: Approved suppression and combination controls; no invented performance targets or causal impact claims.
Dependencies: KPI definitions, quality checks, permitted aggregation policy and executive interpretation review.

Existing containment; completeness unverified

ARCH-07 · Audit and observability

Id: ARCH-07
Status: Existing containment; completeness unverified
Boundary: Trust changes use authorization-checking functions with atomic audit writes; future workflow audit must be reviewed.
Inputs: Actor, scope, approved decision and minimal evidence references.
Outputs: Restricted audit trail and redacted diagnostics; no secrets or sensitive reflections.
Gate: Only authorized reviewers; logs are not a substitute for permission or verified evidence.
Dependencies: Incident ownership, retention, alerting, scope and tested failure/recovery behavior.

Shared environment; write and release gates remain

ARCH-08 · Environment and release

Id: ARCH-08
Status: Shared environment; write and release gates remain
Boundary: Existing project and shared preview/published backend. Drafts change code, not data isolation.
Inputs: Reviewed source and separately approved versioned migrations.
Outputs: Separately approved deployment with rollback; no publication in V6.0 documentation work.
Gate: No automatic migration, account creation, record modification, service activation or domain change.
Dependencies: Baseline, data classification, backup/recovery evidence, scoped testing and explicit release approval.

Information ownership and permitted flow

Public documentation

Owner: Public content reviewer
Access: Anonymous read; authored static content only
Retention: Source review/version policy to be agreed
Flow: Documentation → browser → print/export

Fictional practice

Owner: Explicit practice participant
Access: Memory-only session; no operational accounts
Retention: Exit, refresh and inactivity clear temporary content
Flow: Explicit entry → local practice → clearing

Youth goals

Owner: Young person
Access: Owner-only saved Journey; selected consent projection only
Retention: Organizational policy not yet approved
Flow: Owner goal → explicit approval → assigned task context

Private reflections

Owner: Young person
Access: Separate owner-only records; excluded from staff and public demonstrations
Retention: Organizational policy not yet approved
Flow: Owner → private reflection boundary; no general-network output

Clinical records

Owner: Qualified clinical authority
Access: Restricted assigned professionals under lawful policy
Retention: Clinical record policy and legal review pending
Flow: Limited lawful referral → clinical boundary → approved nonclinical summary

Financial evidence

Owner: Finance control owner
Access: Distinct request, approval, fulfillment and reconciliation duties
Retention: Finance record and appeal policy pending
Flow: Authorized need → independent approval → fulfillment → reconciliation

Contribution evidence

Owner: Development and verification owners
Access: Approved project/task scope; participation never grants youth access
Retention: Contribution/privacy policy pending
Flow: Offer → accepted commitment → independent verification; money/time/items separate

Aggregates and audit

Owner: Reporting and governance owners
Access: Permitted audience and suppression; restricted audit reviewers
Retention: Records and diagnostic policy pending
Flow: Authorized evidence → quality validation → suppression → leadership review