Developer Brief EPIC System Integration

EPIC.system Integration Developer Planning Brief DEMI Initiative — Environmental Assessment Office (EAO) Version: Working Draft — April 2026 Status: Pre-Walkthrough Distribution

How to Read This Document

This document is your pre-read for the EPIC.system Integration walkthrough session. It is not a technical specification and does not define your architecture. Its purpose is to give you enough business context, scope clarity, and working-rule grounding that you can arrive at the walkthrough with informed questions and a basis for roadmap planning.

What this document gives you

What this document does not give you

The business problem EPIC.system Integration must solve within DEMI The roles of EPIC.centre, EPIC.submit, and EPIC.public within the DEMI ecosystem Confirmed v1 scope and deferred items, with rationale Core interaction rules for upload, Metadata Verification Hold, verification, visibility, and status The tiered metadata editing authority model A set of suggested work packages to seed your roadmap A project artifact register (Appendix C) identifying every planning and delivery document this project needs to produce

A final UI/UX design — Service Design will define detailed screen behaviour A finalized permissions matrix — this is a separate controlling artifact and a hard gate for public-facing cutover A confirmed technology stack or integration architecture — to be confirmed at the walkthrough Approved acceptance criteria — these live in the Test and Acceptance Plan ETL runbooks or migration checklists — owned by the File ETL workstream

Artifacts that will follow this document: This planning brief is the first EPIC.system Integration-specific document after the DEMI strategic plan. The project will produce a defined set of downstream artifacts. See Appendix C for the full artifact register with owners and sequencing. Key artifacts include: EPIC.centre Permissions and Actions Matrix (Integration View), Upload and Verification Workflow Spec, Search UX and Requirements Spec, Metadata Edit Rules and Field Governance Matrix, and Test and Acceptance Plan.

Your primary contacts during delivery Product Owner: Geoff McDonald — business-rule interpretation and exception decisions DST Liaison and Scrum Lead: Alyd Llewellyn (DST) — day-to-day technical liaison and scrum lead System Architect: EPIC.system: Saravan Azhikoden — EPIC.system architecture Technical Lead: Mark Lisé (CIM Team) Product Owner: EPIC.system: Carly Greene Hill — EPIC.system product alignment and prioritization GIS Lead: Kate McAnally — geospatial project linkage and spatial metadata authority Privacy / Security Representative: TBD — must be assigned before design begins Records Management Advisors: To be identified — ORCS, retention, and disposition decisions

1. Document Purpose

This document is the business-aligned planning brief that should guide architecture decisions, backlog creation, milestone planning, and phased delivery for EPIC.system Integration under DEMI. It is not a final technical specification. EPIC.system Integration is described broadly because there is work to be done across EPIC.centre, EPIC.submit, and EPIC.public. However, the majority of user-facing change and developer effort will sit in EPIC.centre, and that is where this brief concentrates. Post-launch operational ownership of all DEMI components, including EPIC.system Integration, transfers to the Digital Services Team (DST).

2. Strategic Context and Business Problem

The EAO's project records are currently spread across multiple systems: EDRMS, EPIC holdings, the I:/ Drive, SharePoint, Teams, and legacy paper records. This fragmentation makes it hard to find the right file, slows down operational work, creates duplication, and increases risk in records management, public access, Freedom of Information response, and long-term continuity. DEMI was created to address this by building a unified digital ecosystem. Within DEMI, the DFL is the official file-of-record repository for operational project files. EPIC.centre is the operational interface through which staff and government partner users will search the DFL, upload files into the record, verify metadata, and manage sharing and visibility. The EPIC.system Integration work is driven by three practical needs in EPIC.centre: an improved search experience over DFL content and metadata; a clear and controlled mechanism to adjust key metadata and visibility; and a safe, AI-assisted upload workflow to bring new files into the DFL.

Plain-language goal EPIC.centre is where staff should be able to confidently find, upload, confirm, and share the right project files, knowing they are working with the official record.

Note on paper records: The EAO holds an estimated 27,000 physical paper records in offsite storage that will undergo scanning, OCR, and AICT classification as a separate future project. DEMI — including the DFL and AICT — is a dependency of that scanning project, not the reverse. The paper records workstream is out of scope for EPIC.system Integration v1.

3. Product Vision

EPIC.system acts as the interaction layer for DEMI. The DFL stores the authoritative files, AICT supports classification and metadata enrichment, and EPIC.centre provides the operational interface that staff use daily. EPIC.public is the modern public-facing service that will surface publicly accessible files from the DFL. EPIC.eagle is the legacy public-facing service being replaced over time. See Appendix B for the full DEMI component relationship diagram.

Component	Role in DEMI
DFL	Authoritative file-of-record repository and storage layer
EPIC.centre	Primary internal and government partner interface for search, upload, metadata review, and visibility controls
AICT	Assistive metadata enrichment service; suggestions always require human verification
EPIC.submit	External intake channel; verification and approval gates before files become records
EPIC.public	Modern public-facing service surfacing DFL files marked for public release
EPIC.eagle	Legacy public-facing service and upload pathway being replaced over time
File ETL pipelines	Migration and ingestion from legacy source systems into the DFL
EPIC.engage	Out of scope for DEMI v1 and v2; may contribute files in v3 or later

Architecture note for the walkthrough A conceptual architecture diagram showing the DFL at the centre, with inflows from EPIC.submit and ETL, EPIC.centre as the internal operational UI, and EPIC.public as the public surfacing layer, will be presented at the walkthrough session. See Appendix B. The specific technology stack and integration patterns will be confirmed at that session.

EPIC.centre interface overview (original concept diagram): The three core interface areas shown above — DFL Share (attribute/sharing management), DFL Seek (search), and DFL Upload — map to the three interfaces described in §8. The AI File Classifier shown is AICT. This diagram illustrates the original interface concept and is provided as design context for the walkthrough.

4. Business Ownership and Governance

The day-to-day business owner for EPIC.system Integration is Geoff McDonald. Until the EPIC.centre permissions work and integration architecture are fully settled, Geoff acts as the escalation point for business-rule interpretation and exception decisions. Post-launch operational ownership of all DEMI components transfers to the Digital Services Team (DST).

Role	Person / Group	Notes
Product Owner	Geoff McDonald	Business-rule interpretation and exception decisions
Product Owner: EPIC.system	Carly Greene Hill	EPIC.system product alignment and prioritization
DST Liaison and Scrum Lead	Alyd Llewellyn (DST)	Day-to-day technical liaison and scrum lead
System Architect: EPIC.system	Saravan Azhikoden	EPIC.system architecture
Technical Lead	Mark Lisé (CIM Team)	Senior technical oversight
GIS Lead	Kate McAnally	Geospatial project linkage and spatial metadata authority
Privacy / Security Representative	TBD — must be assigned before design begins	Privacy impact and security sign-off
Records Management Advisors	To be identified	ORCS, retention, and disposition decisions
Post-launch operational owner	Digital Services Team (DST)	All DEMI components; effective at go-live

Developer liaison: During delivery, developers liaise day-to-day with Geoff McDonald and Alyd Llewellyn.

5. What EPIC.system Integration Is, and Is Not

5.1 What EPIC.system Integration Is

EPIC.system Integration is the set of changes required so EPIC.centre can search and manage DFL content, upload new files into the operational record, surface AICT suggestions for human confirmation, and safely manage file visibility and key metadata.

Category	Description
Interface build	New user-facing screens and workflows in EPIC.centre for search, upload/verification, and attribute/sharing management
DFL connection	Integration with DFL storage and metadata APIs to search, retrieve, stage, and admit files
AICT surfacing	Integration with AICT to run classification suggestions during upload and present them for human verification

5.2 What EPIC.system Integration Is Not

EPIC.system Integration does not replace the DFL. It does not store files. It does not change Responsible AI boundaries. AICT must never autonomously set visibility, make files public, set file status, redact content, or delete records. These decisions remain human-controlled and must follow DFL governance and EPIC.centre permissions at all times.

Business rule reminder AICT is always an assistant. Visibility, public release, and status decisions remain human-controlled and must follow DFL governance and EPIC.centre permissions.

6. User Roles for v1

The four roles below apply across all DEMI components, including DFL, AICT, EPIC.system Integration, and the File ETL workstream. The full role-to-action mapping is a named delivery artifact (Appendix C). In the interim, default visibility rules and the tiered metadata editing model below govern what users can and cannot do.

Role	Description
Project Team Member	Team-level access to files for their specific project; primary uploaders and classifiers of project files
EAO Staff	Broader internal access across projects; can edit content-derived and project-context metadata fields
DFL SuperUser	Advanced operational permissions; can edit protected metadata fields, resolve exceptions, and act across multiple roles. Approximately 6–10 in v1.
System Administrator / Developer	Full system-level access for administration and support; controls system-managed technical fields

Permissions matrix: open item The full EPIC.centre Permissions and Actions Matrix — mapping roles to screen access, file actions, metadata editing rights, and visibility transition rights — is a named delivery artifact (see Appendix C). It is a hard gate before public-facing cutover.

7. v1 Scope Boundary

This section defines what EPIC.system Integration must deliver in v1, centred on EPIC.centre, and what is deferred. In scope for v1:

Capability	v1 Position	Notes
DFL search surfaced in EPIC.centre	v1 framework	Baseline aligned to DFL v1 search priorities; detailed UX defined by Service Design
Manual single-file upload to DFL via EPIC.centre	v1 essential	Primary staff intake channel for EAO-created and client-submitted files outside EPIC.submit
AICT metadata suggestions reviewed during upload	v1 essential	Human verification required; Metadata Verification Hold supported
Visibility and sharing management	v1 essential	Visibility changes must be controlled and logged
Tiered metadata editing (per-role)	v1 essential	EAO Staff / SuperUser / SysAdmin categories
View version history	v1	Users can see lineage and understand current vs older versions
File status attribute updates (manual)	v1 limited	Manual SuperUser-led updates; automation deferred to v2/v3

Deferred items:

Deferred item	Expected timing	Reason
Batch upload	v2	Deferred to reduce v1 complexity; interface will fall under the Upload screen-set when delivered
Bulk metadata changes	v2	Requires refined permissions, UX, and audit expectations
Saved searches	v2	Useful enhancement; not required for v1 cutover
Export of search results	v2	Not required for core record and intake workflows
Audit / activity history viewing	v2/v3	Minimum logging required from day one; UI surfacing deferred
AICT reclassification of existing DFL files	v2	Interface will fall under the Attribute/Sharing Management screen-set when delivered
Status automation rules (beyond EPIC.submit)	v2/v3	Manual updates in v1; automation planned as AICT matures
Side-by-side version comparison	Out of scope	Not required; adds complexity without proportional value
Redaction workflows	Out of scope	Redaction flags exist in the DFL model; workflow managed elsewhere

8. EPIC.centre Integration — The Three Core Interfaces

EPIC.centre requires three main user-facing interface areas to fully integrate the DFL into EPIC.system. Each is described below. Screen-level design is the responsibility of Service Design. See the EPIC.centre interface concept diagram in §3.

8.1 Interface 1: Search and File Discovery (v1 framework)

EPIC.centre must surface DFL-backed search so users can find files using DFL metadata, attributes, and metatags. The baseline v1 search priorities are defined and owned by the DFL brief.

DFL v1 Search Priority	Plain-language use case
Find all files for a specific project	"Show me the full project record."
Find the current file of record for a document type within a project	"Show me the current version that matters."
Find all public files for a project	"Show me what has been publicly released."
Find all files of a given file type across all projects	"Show me every file of this type."
Find all files with a given topic metatag across all projects	"Show me all files related to a topic."

Service Design dependency Beyond the five baseline search priorities above, detailed search behaviour, filter patterns, and usability will be defined through Service Design with users. These outcomes will be captured in a named UX and requirements specification artifact (see Appendix C).

Note on 'view' vs 'retrieve': The core v1 action is finding and viewing DFL files through the EPIC.centre interface. The concept of downloading or retrieving a local copy is separate and will be defined in the UX spec and permissions matrix.

8.2 Interface 2: Attribute and Sharing Management (v1 essential)

EPIC.centre must provide authorized users with the ability to view and edit key metadata and to manage sharing and visibility. This interface covers the broadest range of controlled actions:

• Visibility and sharing changes (controlled and logged)
• Metadata editing (within role-based tier limits)
• File status attribute updates (manual; limited in v1)
• AICT-assisted reclassification of existing DFL files (v2; interface will be here when delivered) Visibility must be treated as a high-safety control. EPIC.centre must make it easy to do the right thing and hard to do the wrong thing, especially for files intended for public release.

8.3 Interface 3: File Upload (v1 essential)

EPIC.centre must support single-file upload into the DFL for files entering the operational record outside of EPIC.submit. This covers:

• EAO staff uploading documents created during the assessment process (decisions, letters, evaluations, plans)
• EAO staff uploading files submitted by proponents, certificate holders, or consultants outside EPIC.submit Uploads must support AICT-assisted classification, human verification, and the Metadata Verification Hold (pause mechanic). See §9.

Target direction: Replace EPIC.eagle upload (planning assumption) The intent is for the EPIC.centre v1 upload interface to replace the current EPIC.eagle upload pathway. Achieving this requires coordinated readiness across EPIC.centre upload, DFL ingestion, AICT verification workflow, and EPIC.public surfacing from the DFL. This will need to be carefully validated by developers across all four components before it is confirmed. Status: target direction pending developer delivery validation.

Note on bulk upload: Batch upload is a v2 feature. The interface will be built as an extension of the Upload screen-set. Large-scale digitization or ETL-type ingestion (e.g., scanning paper records) may be handled through backend processes rather than the EPIC.centre interface; this is an open item for developer input during roadmapping.

9. Intake Workflow and Metadata Verification Hold

The intake workflow must support real operational work. The person uploading may not have all the information needed to complete classification in one sitting. The Metadata Verification Hold (informally: pause) allows the project team to complete verification collaboratively.

Admission and file-of-record rule During Metadata Verification Hold, the file may be physically stored in a staging area within the DFL platform, but it is not admitted as a DFL record (file of record) until verification is completed. Admission is the moment the record becomes searchable (per permissions), receives its final visibility, and is governed by the DFL status/visibility model.

Metadata Verification Hold — definition A workflow hold state used when metadata verification cannot be completed immediately. The file may be staged but is not yet admitted as a DFL record and is not broadly searchable. This is a workflow state, not a DFL Status value.

Visibility during hold:

Audience	Can see file during hold?	Notes
Uploader	Yes	Uploader always has access during hold
Project Team	Yes	Any project team member may complete classification collaboratively
All EAO	No	Visibility does not apply until admission
All IDIR	No	Even if intended visibility has been set, it does not apply until admission
Public	No	Public visibility cannot become effective until admission

Intended vs effective visibility rule During hold, intended visibility may be captured but is not effective. On admission, default visibility is Project Team Only unless a permitted user explicitly sets a different visibility.

No-bypass requirement Users may pause (hold) the workflow at any point, but they must not be able to circumvent metadata verification. Public or All IDIR release must not occur until verification is complete and the file has been admitted.

[Insert flowchart: EPIC.centre upload → AICT run → review → confirm → admission as DFL record; include pause/hold branch visible to project team only] [Insert flowchart: Intended visibility captured during hold; effective visibility applies at admission]

10. Metadata Editing and Tiered Authority Model

EPIC.centre must support metadata editing using a tiered authority model. EAO staff are the subject-matter experts for project context; SuperUsers handle records-management and exception fields; SysAdmins control system-managed technical fields. This brief defines categories by tier. The field-by-field permissions mapping is a named delivery artifact (Appendix C) and must be completed before go-live.

Tier	Role	Editable field categories (examples)
1	EAO Staff (Project SMEs)	Content-derived and project-context fields: title, creator, topics, project context, subject/topic metatags, stage, visibility and sharing settings. EAO Staff are the SMEs on what files are about, who they are for, and what topics they relate to.
2	DFL SuperUser	All Tier 1 fields, plus records-management and exception fields: ORCS/retention adjustments, protected metadata corrections, exception-case handling. SuperUsers sit between EAO Staff and SysAdmin — there are only a few fields here beyond Tier 1.
3	SysAdmin	System-managed certainty fields: file type/MIME, system IDs, version tokens, checksums, and technical properties. These are outside EAO Staff expertise and should be 100% reliable from the AICT/system layer.

Design caution Some fields must be intentionally view-only in the EPIC.centre UI to prevent accidental drift — for example, fields derived from controlled vocabularies or set by AICT with high confidence. The detailed lock-down list must be defined in the Metadata Edit Rules and Field Governance Matrix (Appendix C) before go-live.

11. Visibility and Status — EPIC.centre's Role

The DFL brief is the authority on the visibility model (four levels: Project Team Only, All EAO, All IDIR, Public) and the status model (Active, Superseded, Transitory, Retracted). EPIC.centre is the primary interface through which users view and change both.

Visibility Level	Plain-language meaning in EPIC.centre
Project Team Only	Default on admission; visible only to project team members
All EAO	Visible to all EAO staff across projects
All IDIR	Visible to broader BC Government IDIR users
Public	Surfaced in EPIC.public; requires explicit permitted human action

Visibility changes must be controlled and logged. The EPIC.centre Permissions and Actions Matrix will specify which roles can make which visibility transitions. Public release must always be an explicit human-initiated action and must be logged.

12. Versioning and Status Handling (v1 Approach)

EPIC.centre must allow users to understand file lineage and to manually set the status of files that are replacements, duplicates, or superseded versions. In v1, this is handled through manual attribute updates by SuperUsers and, where appropriate, Project Team Members. Broader automation is deferred.

Capability	v1 treatment	Who acts	Notes
View version history	In scope	All roles	Users can see lineage and understand current vs older versions
Set status attributes manually	Limited in v1	SuperUser	Supports duplicates, replacements, and older versions
Auto-status rules for bulk/ETL scenarios	Deferred	—	High complexity; plan for v2/v3 as AICT and ETL mature
EPIC.submit automated status behaviour	Out of this brief's scope	—	EPIC.submit workflow applies its own logic; EPIC.centre must respect it

Status changes are achieved by updating the status attribute on a DFL record. The four status values (Active, Superseded, Transitory, Retracted) are defined and owned by the DFL brief. EPIC.centre provides the interface; the rules live in the DFL.

13. EPIC.submit and EPIC.public (Integration Context)

This brief focuses on EPIC.centre. EPIC.submit and EPIC.public are included here as integration context and dependency information only.

13.1 EPIC.submit

EPIC.submit is the external intake channel for files coming from proponents, certificate holders, and consultants. Changes to EPIC.submit workflows will be delivered primarily by the current EPIC.submit development team with input from DEMI developers to ensure alignment with DFL and AICT rules. EPIC.centre and EPIC.submit must agree on verification states, visibility defaults, and DFL admission rules.

13.2 EPIC.public

EPIC.public is the modern public-facing service that will surface publicly accessible DFL files. EPIC.eagle is the legacy service it will replace. The connection of EPIC.public to DFL-stored files is expected to be implemented as part of the File ETL and cutover workstream, after the DFL has been populated with the existing EPIC.eagle public files. This is described further in the File ETL Developer Planning Brief.

13.3 Client-submitted files outside EPIC.submit

Some files submitted by EAO clients (proponents, certificate holders, consultants) may arrive outside EPIC.submit — for example, from proponents not yet onboarded to the system. These files must be processed through the EPIC.centre Upload interface to enter the DFL. They follow the same intake workflow as other manual uploads, including AICT-assisted classification and the Metadata Verification Hold.

14. Permissions and Access Control

EPIC.centre functionality is controlled by the EPIC.centre permissions matrix, which governs screen access, file access, metadata editing rights, and visibility transition rights. The integration work must design to this matrix. The EPIC.centre Permissions and Actions Matrix (Integration View) is a named delivery artifact. It must cover:

• Admission and verification actions (who can complete, pause, or override hold)
• Visibility transitions (who can change visibility, and from what level to what level)
• Public-release actions (who can set or withdraw public visibility)
• Metadata editing by field and tier

Hard gate The EPIC.centre Permissions and Actions Matrix is a dependency that must be resolved before public-facing cutover. See Appendix C.

15. Minimum Logging Expectations

Full enterprise audit capability is not required on day one. The following minimum operational logs must be preserved from the start, aligned to DFL minimum logging requirements. Audit-history viewing in the UI is deferred, but the underlying logs must exist and be queryable.

Event	What to log
File upload / staging	Who uploaded, when, from which source
File admission (verification completion)	Who completed verification, when, intended vs effective visibility set
Visibility change	Who changed visibility, from what level to what level, when
Status change (supersession / retraction)	Who changed status, from what value to what value, when, reason if applicable
Public publication	Date and time of publication to EPIC.public
Public withdrawal	Date and time of withdrawal from EPIC.public, reason if applicable

16. Must-Not-Fail Conditions (Integration Gates)

These are hard gate criteria and must be built into testing, migration validation, and the Cutover Checklist. No public file loss No exposure of internal-only files to public channels No bypass of metadata verification — users may hold, but cannot circumvent No visibility change without logging No public surfacing without an explicit human-initiated release action No file visible to the wrong audience at any time

Must-not-fail condition	Why it matters
No public file loss	Public record continuity is essential during and after cutover
No exposure of internal-only files publicly	Security and public trust depend on preventing accidental exposure
No bypass of metadata verification	Users can pause, but cannot circumvent verification or trigger broad release prematurely
No visibility change without logging	Visibility decisions must be controlled, traceable, and auditable
No public surfacing without explicit human action	Public release must be intentional and logged
No file visible to the wrong audience	Visibility model integrity is an essential safety control

17. Non-Functional Requirements for v1

Requirement	Target
Integration with DFL	EPIC.centre must read and write DFL metadata and file records via agreed integration patterns
Search response time	10 seconds or less (aligned to DFL requirement); progress indicator if over 2 seconds
Upload confirmation	Normal single-file upload acknowledged within 20 seconds (aligned to DFL requirement)
Public publishing	Near-real-time; 30 seconds or less from release action to EPIC.public surfacing
Minimum logging	Defined in §15, operational from day one
Visibility controls	Controlled, logged state transitions; no unintended public exposure
Security	Malware and virus scanning on every upload (via DFL layer)
Availability	5% or less acceptable downtime

18. Risks

• Misalignment with EPIC release schedules may force sequencing constraints on EPIC.centre feature delivery
• Permissions matrix delay is a hard gate: if the EPIC.centre Permissions and Actions Matrix is not completed before public-facing cutover, go-live cannot proceed
• Service Design dependency: detailed search behaviour and upload UX cannot be fully built without Service Design output; plan this dependency carefully
• AICT integration timing: AICT must be available and tested before the upload workflow can be fully verified
• Replacing EPIC.eagle upload requires coordinated readiness across four components (EPIC.centre, DFL, AICT, EPIC.public); inadequate coordination risks a partial or broken replacement
• Privacy and security advisor is not yet assigned; this unblocks the Privacy Impact Assessment and security sign-off (both hard gates)

19. Success Measures for v1 (Draft)

These success measures describe what a successful v1 looks like in practice. They are not formal acceptance criteria. Formal criteria will be developed in the Test and Acceptance Plan.

v1 success measure	What it looks like in practice
Staff can find DFL files through EPIC.centre	Users can reliably locate project files and current records using DFL metadata and metatags
Staff can upload files into the DFL safely	Upload works, AICT runs, metadata is verified, and files are correctly admitted as DFL records
Metadata Verification Hold supports teamwork	Project team can complete verification collaboratively without premature exposure to broader audiences
Visibility controls are safe and traceable	Visibility changes are logged; accidental public exposure does not occur
Version history is visible and usable	Users can understand file lineage and avoid working with outdated versions
Status updates are controlled	SuperUsers can manually update file status for replacements and duplicates; changes are logged

20. Recommended Developer Work Packages

These work packages seed your roadmap. Each maps to the v1 scope defined in §7. Effort sizing, sprint assignment, and detailed ownership will be established at and after the walkthrough session.

Work Package	Description	Key dependency
WP1: EPIC.centre search surfacing	Surface DFL-backed search aligned to the five v1 priorities; build the framework for Service Design–informed UX refinement.	DFL metadata contract and search API
WP2: Upload + AICT verification + hold	Single-file upload workflow with AICT classification suggestions, human verification, Metadata Verification Hold, and no-bypass enforcement. Includes client-submitted files via manual upload.	AICT integration pattern and verification rules
WP3: Attribute/Sharing management	Metadata view and edit screens with tiered authority model; visibility and sharing controls with logging; version history viewing.	Permissions matrix and Field Governance Matrix
WP4: Status attribute handling	Manual status updates for SuperUsers; version lineage display; groundwork for future automation.	DFL status model and version lineage approach
WP5: EPIC.submit alignment support	Integration alignment with EPIC.submit team on intake gates, verification patterns, and DFL admission rules.	EPIC.submit workflows and AICT rules
WP6: EPIC.public connection planning (ETL-led)	Coordinate to ensure EPIC.public reads from DFL after ETL population and cutover; plan EPIC.eagle replacement.	ETL sequencing and DFL public release model
WP7: Security, logging, and operational readiness	Confirm logs, controls, and testability of must-not-fail conditions; prepare sustainment handoff.	Permissions matrix and Test/Acceptance Plan

21. Open Items and Clarification Questions

Items below are either in progress, architect-dependent, or require answer before specific design decisions can be finalized. They are not blockers to roadmapping, but each will constrain design choices as it resolves. See Appendix C for the artifact register that tracks resolution ownership.

Item	Current assumption / position	Implication if unresolved
EPIC.centre search UX beyond baseline priorities	Service Design defines detailed behaviour; captures in a named UX spec artifact	Search interface cannot be fully built without Service Design output
Metadata Edit Rules and Field Governance Matrix	Tiered model is confirmed; field-by-field detail produced during delivery	Must be completed before go-live to prevent metadata drift
EPIC.centre Permissions and Actions Matrix (Integration View)	Provisional role model in §6; full matrix is a named delivery artifact	Hard gate for public-facing cutover
SuperUser visibility during Metadata Verification Hold	SuperUsers can see and act on held files by default (to be confirmed)	Affects hold workflow design and delegation model
Reason-for-change prompts on high-safety actions	Not yet defined; recommended for visibility and status changes to improve traceability	Affects logging design and UX for high-risk actions
Search performance targets	10 seconds or less, aligned to DFL; detailed SLOs in Test and Acceptance Plan	Performance testing design depends on agreed targets
Staging storage placement during hold	Working assumption: same DFL storage container, held state flagged in metadata	Affects DFL infrastructure design
record_id generation timing	Working assumption: generated immediately on upload, before admission	Affects DFL and EPIC.centre integration design
Privacy and Security Advisor assignment	TBD — must be assigned before design begins	Blocks Privacy Impact Assessment and security sign-off (both hard gates)
Bulk paper-record digitization intake path	Backend/ETL process assumed for large-scale paper scanning; EPIC.centre Upload for smaller batches; open for developer input	Affects scoping of Upload interface and ETL workstream coordination

22. Conclusion

EPIC.system Integration is the operational bridge that makes the DFL usable in everyday work. The DFL stores the authoritative files, AICT supports metadata quality, and EPIC.centre is where staff will find files, upload files, confirm metadata, and control visibility. In v1, the priority is a safe and practical outcome: EPIC.centre must provide reliable search surfacing, a single-file upload workflow with AICT assistance and a Metadata Verification Hold mechanism, and controlled metadata and sharing tools that prevent accidental public exposure while enabling staff to do their work efficiently.

Next step Bring your questions from this document to the walkthrough session. The walkthrough will confirm the integration architecture, walk through the component relationships, and give you the opportunity to identify gaps, raise risks, and align on the planning approach before roadmapping begins. After the walkthrough, priority artifact production is: EPIC.centre Permissions and Actions Matrix, Upload and Verification Workflow Spec, and Test and Acceptance Plan. See Appendix C.

Appendix A — Canonical Terms / Glossary

The terms below are canonical across all four DEMI developer planning briefs. Use these definitions wherever the terms appear.

Standard paragraph: Admission and file-of-record rule During Metadata Verification Hold, the file may be physically stored in a staging area within the DFL platform, but it is not admitted as a DFL record (file of record) until verification is completed. Admission is the moment the record becomes searchable (per permissions), receives its final visibility, and is governed by the DFL status/visibility model.

Standard paragraph: Intended vs effective visibility rule During hold, intended visibility may be captured but is not effective. On admission, default visibility is Project Team Only unless a permitted user explicitly sets a different visibility.

Term	Definition	Notes
Admission	The moment a staged file becomes a DFL record. At admission the record becomes searchable (per permissions), receives effective visibility, and is governed by the DFL status/visibility model.	See standard paragraphs above
AICT	AI Classifier Tool. An assistive metadata enrichment and classification service. AICT never makes business-critical decisions autonomously.
DFL	Digital File Library. The authoritative repository and storage layer for EAO operational project files.
DFL record / File of record	A file admitted into the DFL through an accepted intake path, governed by DFL metadata, status, visibility, and logging rules.
EDRMS	Electronic Document and Records Management System. The BC Government-sanctioned system of record.
Effective visibility	The visibility level that actually controls access to a record. Begins at admission.
EPIC.centre	The internal and government-partner operational interface for search, upload, metadata verification, and visibility management.	Canonical spelling: 'centre'
EPIC.eagle	The legacy public-facing service and historic upload pathway, being replaced by EPIC.public over time.
EPIC.engage	An EPIC.system application not in scope for DEMI v1 or v2. May contribute files to the DFL in v3 or later.	Out of scope — v3+
EPIC.public	The modern public-facing service that surfaces publicly accessible DFL files.
EPIC.submit	The invitation-only external intake portal for Proponents and Certificate Holders.
EPIC.system Integration	The DEMI workstream delivering EPIC.centre changes for DFL search, upload, verification, and visibility management. Informally: EPIC Integration.	This document
ETL	Extract, Transform, Load. The pipeline process for migrating files from legacy source systems into the DFL.
File ETL	The DEMI workstream migrating legacy files from EDRMS, EPIC.eagle, I:/ Drive, SharePoint, Teams, and other sources into the DFL.
Intended visibility	A visibility selection captured during Metadata Verification Hold. Not effective until admission.
Metadata Verification Hold	A workflow hold state (informal: pause). File is staged but not yet admitted and not broadly searchable.	Not a DFL Status value
Public surfacing	A DFL record with Public effective visibility displayed in EPIC.public. Requires explicit permitted human action; logged.
Status (DFL)	The lifecycle state of a DFL record: Active, Superseded, Transitory, or Retracted.	Owned by DFL brief
Visibility (DFL)	The audience access level of a DFL record: Project Team Only, All EAO, All IDIR, or Public.	Owned by DFL brief

Appendix B — DEMI Component Relationship Map

The diagram below shows the full DEMI ecosystem. See also the EPIC.centre interface diagram in §8 which shows the three core interface areas within EPIC.centre specifically. Note on EPIC.engage: EPIC.engage is an EPIC.system application not in scope for DEMI v1 or v2. It appears in this diagram for completeness. In a future version (v3 or later), files collected in EPIC.engage may flow into the DFL. No developer action is required in the current scope.

Appendix C — Project Artifact Register

This register identifies every planning and delivery document the EPIC.system Integration workstream needs to produce. Owners, dates, and sequencing will be confirmed at and after the walkthrough session.

This document in context This Developer Planning Brief is the first EPIC.system Integration-specific document after the DEMI Strategic Plan. All artifacts listed below are downstream of this brief.

Artifact sequencing legend:

• Phase 1: Pre-build / design (must exist before build begins)
• Phase 2: During build (produced as part of delivery)
• Phase 3: Pre-cutover (must exist and be signed off before go/no-go)
• Phase 4: Post-launch (operational and ongoing)

Artifact	Description	Phase	Owner	Status
EPIC.system Integration Developer Planning Brief (this document)	Business context, scope, workflows, tiered authority model, work packages, open items.	1	Geoff McDonald	DRAFT — pre-walkthrough
EPIC.centre Permissions and Actions Matrix (Integration View)	Roles-to-actions mapping for integration screens and file actions; covers admission/verification, visibility transitions, metadata editing by tier, and public-release actions. Hard gate before public cutover.	1	Product Owner: EPIC.system + DST + Geoff	NOT STARTED
Privacy and Security Assessment	Privacy impact assessment and security review for EPIC.centre integration and public-release path.	1	Privacy/Security Advisor (TBD)	BLOCKED — advisor not yet assigned
EPIC.centre Upload + Verification Workflow Spec	Detailed specification for single-file upload, AICT classification review, Metadata Verification Hold, and no-bypass enforcement.	2	WP2 Lead	NOT STARTED
EPIC.centre Search UX and Requirements Spec	Service-design-informed search experience definition beyond the five baseline DFL priorities.	2	Service Design Lead + WP1 Lead	NOT STARTED
Metadata Edit Rules and Field Governance Matrix	Field-by-field definition of editable, view-only, and system-managed fields by tier. Must be completed before go-live.	2	WP3 Lead + Geoff + DST	NOT STARTED
Architecture Decision Record(s)	Key integration decisions and patterns captured as ADRs.	2	Saravan Azhikoden + Alyd Llewellyn	NOT STARTED
Test and Acceptance Plan	Formal acceptance criteria, methods, thresholds, and procedures. Covers upload/verification, search, visibility controls, and operational readiness.	3	Geoff + DST + Dev Lead	NOT STARTED
Operational Runbook (EPIC.centre integration)	Support procedures, incident handling, escalation, and sustainment for EPIC.centre integration functions.	4	DST + EPIC Ops	NOT STARTED

Immediate priorities after the walkthrough 1. Assign the Privacy and Security Advisor — unblocks Privacy Impact Assessment and security sign-off (both hard gates) 2. Begin the EPIC.centre Permissions and Actions Matrix — hard gate for public-facing cutover 3. Confirm Service Design engagement and timeline — search and upload UX cannot be finalized without it 4. Confirm AICT integration pattern with the architect — upload and verification workflow cannot be fully designed without it

Appendix D — Key External Dependencies

The following are external inputs or approvals that the EPIC.system Integration development team must design to accommodate.

Dependency	Required for	Owner / Source	Timing
EPIC.centre Permissions and Actions Matrix	Public-facing cutover gate; governs all user-facing actions in integration screens	Product Owner: EPIC.system + DST + Geoff	Hard gate — must exist before public-facing cutover
Service Design output — search and upload UX	Detailed search behaviour and upload interface design beyond baseline priorities	Service Design workstream	Must precede detailed build of search and upload screens
AICT integration pattern	Upload and verification workflow cannot be fully designed without confirmed AICT integration approach	Saravan Azhikoden + AICT dev team	Confirm at walkthrough
Privacy and Security Advisor assignment	Privacy Impact Assessment and security sign-off	EAO / Ministry	Must be assigned before design begins — currently TBD
DFL metadata contract and search API	Search surfacing and upload integration depend on confirmed DFL metadata structure and APIs	DFL development team	WP1 complete before EPIC.centre integration builds
Metadata Edit Rules and Field Governance Matrix	Field-by-field lock-down list required before metadata editing screens go to production	WP3 Lead + Geoff + DST	Must be completed before go-live