Developer Brief AI Classifier Tool

AI Classifier Tool (AICT) 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 AICT walkthrough session. It is not a technical specification and does not define your architecture. Its purpose is to give you enough business context, confirmed decisions, and working-rule grounding that you can arrive at the walkthrough with informed questions and a basis for design planning. The AICT is one of four DEMI components that require developer delivery. The other three are the Digital File Library (DFL), EPIC.system Integration, and the File ETL workstream. This brief should be read alongside the DFL Developer Planning Brief, which is the companion document and the authority on file-of-record rules, the visibility model, the status model, and the minimal metadata contract.

What this document gives you

What this document does not give you

The business problem AICT must solve and its role within DEMI and the DFL Confirmed v1 scope: what AICT does, what it does not do, and why Hard limits on what AICT must never do autonomously Working business rules for intake workflows, outputs, and human review The DEMI Responsible AI principle and how it shapes AICT design Confirmed confidence thresholds as a starting position for development Open items flagged for walkthrough discussion and design resolution

A finalized output field schema — Appendix C field list is the working prototype scope, not a locked contract Confirmed controlled vocabularies — these come from the Information Architecture workstream A confirmed technology stack or model choice — design decisions for the development team Approved acceptance criteria — success measures are in §20 and are pending sponsor review Government email classification rules — a named delivery dependency (§11)

Artifacts that will follow this document: This planning brief is the first AICT-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: AICT Output Field Contract, Controlled Vocabulary Files, 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

1. Purpose of the AI Classifier Tool

The AI Classifier Tool reads files entering the Digital File Library, uses file content together with available intake context, and returns metadata suggestions or system-applied values that improve findability, support ORCS-related tagging, and reduce manual classification effort. In plain language, AICT's job is to help the DFL answer three practical questions more consistently and with less manual effort:

• What kind of file is this?
• What should this file be called, tagged, and linked to?
• What records-management metadata should staff be prompted to confirm? AICT is a core enabling service for the DFL — not an independent application. Its value is not in replacing staff judgment. It is in doing the first pass of classification work reliably, using document content and structured context, and giving EAO staff a faster, better-grounded starting point for confirming DFL metadata. Post-launch operational ownership of all DEMI components, including AICT, transfers to the Digital Services Team (DST).

2. Strategic Context

AICT sits inside DEMI and directly supports the DFL's core goals: consistent metadata, better search, reduced duplication, and improved records-management readiness. Within the DFL delivery plan, AICT corresponds to Work Package 6: Metadata and AI Integration. Baseline metadata and AI-assisted enrichment are in scope for v1. The full enterprise metadata model and advanced disposition automation are deferred. This means AICT should be built as a practical v1 service that improves intake quality and discovery now, while leaving room for later maturity in areas such as advanced OCR, richer entity extraction, broader automation, and post-v1 vocabulary self-service.

Future workstream: Paper records digitization 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. AICT v2 or v3 will be required to handle OCR-processed files and support batch loading into the DFL. This workstream is out of scope for AICT v1 but must not be foreclosed by v1 architecture decisions.

3. What AICT Is, and Is Not

3.1 What AICT Is

AICT is a metadata enrichment and classification assistive service. It runs at intake, reads file content and contextual signals, and returns suggestions and a small set of auto-applied values that support DFL intake quality. It is re-runnable as rules and vocabularies evolve — though reprocessing of already-ingested backfiles is a post-v1 capability.

3.2 What AICT Is Not

AICT is not the decision-maker for any business-critical outcome. It has no authority over:

• Visibility — which audience can see a file (Project Team Only, All EAO, All IDIR, Public)
• Public release or EPIC.public exposure
• File status (Active, Superseded, Transitory, Retracted)
• Redaction or sensitive-content determination
• Records disposition decisions
• Source-precedence decisions during ETL conflict resolution These decisions belong to EAO staff, DFL SuperUsers, and the governance processes defined in the DFL Planning Brief. AICT may generate signals and suggestions that inform those decisions, but it must not make them autonomously.

4. Hard Limits: What AICT Must Never Do

The following are absolute business boundaries for v1 and all subsequent versions. These limits are not design options — they are non-negotiable constraints that must be reflected in the system architecture from the outset.

Hard Limit — AICT must never, under any circumstance, autonomously: Set or change file visibility in v1 Make any file public or set any file to All IDIR or Public Set or change file status Redact or alter file content Delete, cull, or flag a file as transitory without human confirmation Override metadata entered by an uploader Override source-precedence decisions made during ETL Apply final records disposition decisions Visibility and public exposure are human decisions. In v1, AICT must not set visibility at all. In a future v2 state, AICT may be allowed to set visibility to All EAO only where all relevant tags are at very high confidence, but human review will still be required for any file to be set to All IDIR or Public. This is a hard architectural requirement, not a UX preference.

5. The DEMI Responsible AI Principle

All AI components within DEMI — including AICT — operate under the DEMI Responsible AI Principle. This principle has two parts, both of which must be reflected in AICT's design:

Component	What it requires of AICT
Reduce hallucination through curated lists	Wherever a controlled vocabulary exists for a field, AICT should select from that list. AICT should not invent values for controlled-list fields. Free-text generation is permitted only for inherently free-text fields such as title or explanatory text. This is the intended v1 operating rule and should be treated as a strong design requirement, subject to further validation through development and testing.
Human verification of AI-suggested attributes	All AICT suggestions must be reviewed and confirmed by a human before they become part of the DFL record. In v1, visibility, security-relevant attributes, and records-management decisions must not be set by AICT. In a future v2 state, AICT may be allowed to set visibility to All EAO only where all relevant tags are at very high confidence, but All IDIR and Public must always remain human-set values. The human reviewer is always the authority.

These two requirements shape every output, workflow, and interface decision described in this brief. Explainability (§14) and the Metadata Verification Hold (§16) are the primary mechanisms through which the second component is implemented.

6. Business Ownership and Governance

The AICT is an all-EAO tool. Post-launch operational ownership of all DEMI components, including AICT, resides with the Digital Services Team (DST). During development, the governance model is as follows:

Role	Person / Group	Notes
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)	Senior technical oversight
Product Owner: EPIC.system	Carly Greene Hill	EPIC.system product alignment and prioritization
GIS Lead	Kate McAnally	Geospatial project linkage and spatial metadata authority
Post-launch operational owner	Digital Services Team (DST)	All DEMI components; effective at go-live
Records-management advice	GIMO representatives, as needed	ORCS mapping and retention rules
Privacy and security advice	Ministry Information Security Officer (MISO), as needed	Security review and AI policy compliance

6.1 Business Rule Change Authority

Rule type	Change authority
Curated vocabularies	OpsDiv SMEs and DST
ORCS mapping logic	GIMO representative
Confidence thresholds	DST and developers
What AICT may auto-apply vs. suggest only	OpsDiv SMEs, DST, and developers

7. v1 Scope: What AICT Does

AICT's three primary jobs in v1 are:

• Apply or suggest the DFL minimum viable tag set
• Use EAO curated lists to suggest topic metatags
• Suggest file titles using a standardized naming convention derived from document content

Function	Output type	Notes
Identify document type	Suggest	Up to three candidates with confidence scores
Identify topic metatags	Suggest	Selected tag set with per-tag confidence
Suggest ORCS classification	Suggest	Primary suggestion with confidence and short rule explanation
Suggest retention class	Suggest	Linked to ORCS suggestion
Extract or infer file title	Suggest	Single value with rationale
Extract or infer creator / organization	Suggest	Single value with confidence
Extract or infer created date	Suggest	Single value with confidence
Identify file type	Auto-apply	Determined from file properties, not AI inference
Extract search-index text	Auto-apply	Full text extraction for DFL search indexing
Flag duplicate or near-duplicate	Auto-apply (signal only)	Signal passed to DFL duplicate handling logic; AICT does not act on it

Business rule The output field list above is the working prototype scope for development and testing. The final output contract will be shaped by the Information Architecture workstream, ORCS and retention requirements, and validated search needs. It should not be treated as a permanently locked schema.

8. v1 Scope: What AICT Does Not Do

Out of scope item	Classification
Set or suggest visibility (Public, All IDIR, All EAO, Project Team Only)	Hard limit — all versions
Set or suggest file status	Hard limit — all versions
Redact or determine sensitive content	Hard limit — all versions
Automated culling or deletion	Hard limit — all versions
Automated final records / disposition decisions	Hard limit — all versions
Override source-precedence decisions made during ETL	Hard limit — all versions
Reprocessing of already-ingested backfiles	Post-v1 (v2/v3)
Deep OCR processing of scanned files	Post-v1 (v2/v3) — required for paper records workstream
Batch classification of OCR-processed paper records	Post-v1 (v2/v3)
Advanced fine-tuning and model self-improvement from corrections	Post-v1
Deeper duplicate analysis beyond signal generation	Post-v1 — BC Government evaluating dedicated deduplication tools
Image, audio, and video understanding	Deferred
Advanced SharePoint promotion-flow integration	Deferred
Vocabulary self-service and list management by staff	Post-v1

9. Intake Points and Run Pattern

AICT runs at three intake points in v1. Each has a distinct run pattern and human review model.

9.1 EPIC.submit

EPIC.submit is an invitation-only, externally facing portal used by Proponents and Certificate Holders to submit documentation and information to the EAO on their projects. It is not accessible to the general public. Submitters authenticate through a separate external mechanism; they are not IDIR users.

Step	Rule
1	AICT classification runs when a file is saved into EPIC.submit
2	Every saved version is classified independently
3	AICT suggestions are presented to the appropriate EAO staff user during the built-in EPIC.submit verification step
4	The file enters the DFL as a file of record only after both the AICT verification and the EPIC.submit approval process are complete
5	Default visibility on entry: Project Team Only

Business rule AICT classification must be verified before a file can be approved into the DFL through EPIC.submit. Verification and approval are separate steps. Completion of classification verification is a gate on approval, not a substitute for it.

9.2 EPIC.centre Manual Upload

EPIC.centre is the primary internal-facing interface for EAO staff and any BC Government user with a valid IDIR credential. Access to file content within EPIC.centre is controlled by the visibility model defined in the DFL Planning Brief.

Step	Rule
1	The user uploads the file using the EPIC.centre intake form
2	AICT runs when the user confirms the upload action
3	AICT suggestions are displayed to the uploader for review and confirmation
4	The file is not findable by other users until AICT classification has been verified and confirmed — the file is in Metadata Verification Hold (see §16)
5	Final confirmation places the file into the DFL as a file of record
6	Default visibility on admission: Project Team Only

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.

9.3 File ETL and the Training Corpus

The Priority 1A ETL stream transfers approximately 65,000 existing EPIC.eagle public files from AWS S3 storage to the EAO's Azure Blob Storage container. These files — all of which are public-facing — represent the operational project record for nearly all of the EAO's projects. They already carry a basic set of metatags. This corpus serves a dual purpose in v1:

• It is the backbone of the DFL, forming the substantive starting content of the repository.
• It is the primary training and evaluation dataset for AICT. Because the files are all public-facing, already project-linked, and carry existing tags, they represent an ideal training set with no security risk.

MISO sign-off required Even though EPIC.eagle public files are publicly accessible, using them as an AI training corpus may have implications under BC Government AI policy or provincial data governance rules. The distinction between 'publicly accessible' and 'approved for AI training use' must be confirmed with the Ministry Information Security Officer before training proceeds. This is a named delivery dependency (see Appendix D). Development may proceed on the assumption that approval will be granted, but training must not commence without it.

ETL priority	Source	AICT role in v1
1A	EPIC.eagle public files (AWS S3 → Azure Blob)	Primary training and evaluation corpus; AICT enrichment applied
1B	Additional EPIC.eagle public files (gap fill)	AICT applied operationally where ETL team determines it is safe and useful
2	EPIC.submit (ongoing intake)	Full AICT classification per §9.1
3	EPIC.centre manual upload (ongoing)	Full AICT classification per §9.2
4+	EDRMS, I:/ Drive, SharePoint, Teams	Post-v1 migration streams; AICT role to be confirmed

10. When a File Becomes a File of Record

Intake path	File-of-record rule
EPIC.submit	AICT classification runs early in the submission process. The file becomes a file of record only when the EPIC.submit approval process is complete and AICT verification is confirmed. Both gates must be passed.
EPIC.centre manual upload	The file may be uploaded before classification is complete, but it is not a file of record and is not visible to other users until AICT classification has been reviewed and confirmed by the uploading staff member.
File ETL (1A / 1B)	Files enter the DFL as files of record through the ETL pipeline. AICT enrichment is applied during or after ingestion. Human review of ETL-classified files is managed through testing, spot checks, and trial runs — not file-by-file verification.

11. Inputs AICT May Use

In v1, AICT may use the following inputs where they are available. Inputs are weighted: document content is the primary signal; all other inputs are secondary and supplementary.

Input	Weight / notes
Full document text	Primary signal — highest weight
Project ID and project name	Strong contextual anchor
Submission form fields (work type, submitter-entered metadata)	Strong contextual signal for EPIC.submit intake
Uploader-entered metadata	Treated as high-confidence context; AICT must not override it
EPIC.centre folder path or source location	Secondary contextual signal
Existing EPIC.eagle metatags (from training corpus)	Secondary — lower weight than document content
File name	Secondary — lower weight than document content
Prior versions of the same file	Secondary — lower weight than current document content
Project-level context from EPIC	Secondary contextual signal
Geospatial metadata (via ProjectID / EPIC.map)	Used as a project identification signal only; AICT does not generate or validate spatial data — EPIC.map and Kate McAnally govern geospatial attributes
Email headers and message metadata (for MSG files)	Subject to government email classification rules — see §11.1
First Nations names (via EPIC.track)	Drawn from authoritative list only — see §11.2

Business rule AICT must not use SharePoint project files as a grounding or tuning source in v1.

11.1 Email File Classification

Email and MSG files are a supported file type in v1. The BC Government maintains a defined set of rules governing how email files must be classified for records management purposes. AICT will adopt those rules when classifying email content.

Open item The specific government email classification rules are a named delivery dependency (see Appendix D). The rules are prescribed externally and will be provided to the development team during delivery. Architecture must be designed to accommodate them. Development of email classification capability must not proceed to production without the rules in hand. Confirm the source and delivery timeline for these rules with GIMO at the walkthrough.

11.2 First Nations Names

First Nations names must be drawn exclusively from the authoritative list maintained by EPIC.track, which sources from the BC Government's official database. AICT must never free-text generate a First Nations name. This prohibition is absolute and applies regardless of confidence level — it is a harder constraint than the general rule against inventing controlled-list values.

12. Supported File Types in v1

File type	AICT treatment in v1
Text-based PDFs	Full classification
Word documents (.docx)	Full classification
Excel workbooks (.xlsx)	Full classification
PowerPoint files (.pptx)	Full classification
Email / MSG files	Classification subject to government email rules (§11.1)
Scanned PDFs requiring OCR	Storage only in v1; OCR-based classification is a post-v1 capability required for the paper records workstream
Image-only files	Storage only
ZIP packages	Storage only; contents not unpacked for classification
GIS / spatial files	Storage only; spatial attributes governed by EPIC.map
Audio and video files	Storage only

13. Outputs, Suggestions, and Auto-Applied Fields

In v1, most AICT outputs are suggestions for human review — not final decisions. This directly implements the DEMI Responsible AI Principle (§5). The small set of auto-applied fields are objective determinations that require no human judgment.

13.1 Confidence Thresholds

The following thresholds are illustrative placeholders for early development and discussion. They are not approved business thresholds and are subject to revision based on testing results, developer input, and walkthrough decisions.

Threshold type	Working value	Effect
Auto-apply threshold	95% confidence or above	AICT applies the value without presenting it for review. Applies only to the three auto-apply fields.
Suggest threshold	80% confidence or above	AICT presents the suggestion to the human reviewer with confidence score and rationale.
Suppress threshold	Below 80% confidence	AICT does not present a suggestion for that field. The field is left blank for the human reviewer to populate.

Open item Illustrative threshold placeholders may be used during early development, but final confidence thresholds are not yet approved and must be tested and calibrated against real EAO documents. Changes to thresholds follow the governance model in §6.1.

13.2 Auto-Applied Fields

Field	Rationale
File type	Determined from file properties — not AI inference. No judgment required.
Search-index text	Full text extraction for DFL search. No metadata decision involved.
Duplicate / near-duplicate flag	Signal only. Passed to DFL duplicate handling logic. AICT does not act on it.

13.3 Suggested Fields (Human Review Required)

Field	Presentation format
File title	Single suggested value with rationale
Creator / organization	Single suggested value with confidence score
Created date	Single suggested value with confidence score
Document type	Up to three candidate values with confidence scores
Topic metatags	Selected tag set with per-tag confidence scores
ORCS classification	Primary suggestion with confidence score and short rule explanation
Retention class	Primary suggestion linked to ORCS suggestion

14. Explainability and User Experience

Explainability is a strong v1 design objective. Staff should be able to understand why AICT has made a suggestion in order to review it meaningfully, especially for records-management fields such as ORCS classification and retention. If full explainability proves too heavy for v1, the presentation may be simplified, but confidence scoring and basic reasoning support should still be preserved where feasible.

Field / output	What the user sees
Title	Suggested value + short rationale (e.g., 'Derived from document header and project name')
Document type	Up to three candidates + confidence percentage per candidate
Topic metatags	Selected tags + confidence percentage per tag
ORCS / retention	Primary suggestion + confidence + short rule explanation (e.g., 'Matched to ORCS schedule X based on document type Y')
Duplicate flag	Yes / Possible / No + rationale
Creator / created date / file type	Single value + confidence percentage

Note Explainability is a strong design goal for v1. If full implementation proves too heavy for the initial release, the presentation may be simplified — but the underlying confidence scoring must still be generated and stored. Service design and user testing should determine the final presentation pattern.

15. Controlled Vocabularies and Curated Lists

AICT must be grounded in controlled vocabularies and curated lists wherever those lists exist. This is the first component of the DEMI Responsible AI Principle. Grounding in curated lists is the primary mechanism for reducing hallucination and maintaining classification consistency across the DFL.

Vocabulary / list	Source / authority
Document types	EAO / Information Architecture workstream
Topic metatags	EAO / Information Architecture workstream
ORCS classification codes	BC Government ORCS manual — externally prescribed
Retention schedule values	BC Government retention schedules — externally prescribed
Naming convention patterns (for title suggestion)	EAO / Information Architecture workstream
Project IDs and project names	EPIC.system
First Nations names	EPIC.track (sourced from BC Government authoritative database)
Existing EPIC.eagle metatags	EPIC.eagle — used during training; lower weight than document content

Business rule If a field has a controlled list, AICT should select from that list. AICT should not invent alternate values for controlled-list fields. Free-text generation is permitted only where the field is inherently free text — title and explanatory rationale text. For First Nations names, this prohibition is absolute (§11.2).

Final controlled vocabulary lists will be delivered by the Information Architecture workstream. Development should proceed against placeholder or sample lists and be designed to accept the final lists without architectural change.

16. Human Review and the Metadata Verification Hold

16.1 Who Reviews

Intake path	Reviewer
EPIC.submit	The appropriate EAO staff user verifies suggestions during the submission verification step. EAO staff complete the approval step separately.
EPIC.centre manual upload	The EAO staff member uploading the file reviews and confirms suggestions before the file enters the DFL.
File ETL (1A / 1B)	No file-by-file review. Quality is managed through testing, spot checks, and trial runs with known data before production ingestion.

16.2 The Metadata Verification Hold

Metadata Verification Hold This is a workflow hold state, not a DFL file status value. It does not appear in the DFL status model (Active, Superseded, Transitory, Retracted). A file in Metadata Verification Hold has been uploaded but has not yet become a file of record. Intended vs effective visibility: 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. EPIC.submit: The hold may persist until the point of approval. AICT verification must be completed before approval can proceed. EPIC.centre: The hold persists until the uploader confirms the classification. The file is not findable by others during this time.

17. Special Handling and Flags

Where AICT encounters conditions that require attention but do not warrant blocking, it should flag rather than block. This is consistent with the DFL's light-touch v1 approach, which avoids hard automated upload blocking.

Condition	AICT behaviour
Likely ARCS / administrative content	Flag for staff review — do not block
Poor-quality or unreadable file	Flag — classification may be incomplete or low-confidence
Unsupported file type for AI classification	Flag — file is stored but not classified
Duplicate or near-duplicate detected	Signal passed to DFL duplicate handling logic — AICT does not act
First Nations name cannot be matched to EPIC.track list	Flag — do not attempt free-text generation

18. Relationship to Search and Records Management

18.1 Search

AICT exists in large part to strengthen DFL search and findability. The five confirmed v1 search priorities from the DFL Planning Brief are:

Priority	Search requirement	AICT relevance
1	Find all files for a specific project	Project ID linkage and project-level metadata
2	Find the current file of record for a document type within a project	Document type suggestion
3	Find all public files for a project	Not an AICT function — visibility is set by humans
4	Find all files of a given file type across all projects	File type auto-apply
5	Find all files with a given topic metatag across all projects	Topic metatag suggestion

18.2 Records Management

AICT supports ORCS classification and retention tagging through suggestion and assistive tagging — not through autonomous final assignment. ORCS and retention suggestions must always be confirmed by a human reviewer before they become part of the DFL record. This is both a DEMI Responsible AI requirement and a records-management governance requirement.

19. Performance, Privacy, and Security

AICT operates within the broader DFL performance and security envelope established in the DFL Planning Brief.

Requirement	Detail
Processing environment	All processing must remain within approved BC Government / Microsoft environments
Privacy and security review	AICT must undergo privacy and security review before production deployment. Whether a separate review is required or whether it is covered under the broader DFL review will be assessed during delivery.
Search performance	Search results within 10 seconds or less (DFL requirement; AICT metadata quality directly affects this)
Upload performance	Normal single-file upload within 20 seconds (DFL requirement)
Malware / virus scanning	Required on every upload — DFL responsibility, not AICT
Release path	Standard DEV → TEST → PROD

Note Detailed technical decisions — synchronous vs. asynchronous processing, queue behaviour, failure handling, retry model, model versioning across environments, and evaluation harness design — are design decisions for the development team, subject to the business constraints above.

20. Success Measures for v1

Priority	Success measure	What 'good' looks like
1	Low hallucination	AICT suggestions are grounded in controlled vocabularies and document content, not invented
2	Metadata and tagging accuracy	Suggestions are correct at a rate that meaningfully reduces staff correction effort
3	ORCS and retention support	Suggestions reduce staff effort without over-automating records decisions
4	Improved search and findability	DFL search outcomes are more consistent and useful as a result of AICT tagging
5	Usable ETL metadata enrichment	AICT contributes usable metadata for ingestion scenarios where adopted
6	Reduced manual tagging effort	Staff spend less time on first-pass classification
7	Maintainability of vocabularies	Curated lists can be updated by DST without requiring a development release
8	Speed and responsiveness	Classification does not materially slow down the intake workflow

21. Open Items and Developer Questions

The following items are intentionally left open for the development team to design within the business rules above, or are dependencies that must be resolved during delivery.

Open item	Type
Synchronous vs. asynchronous processing pattern	Architecture decision — development team
Queue and retry model	Architecture decision — development team
Failure behaviour and recovery pattern	Architecture decision — development team
Exact confidence display conventions and UX presentation	Service design — to be user-tested
Model and rules deployment pattern across DEV / TEST / PROD	Architecture decision — development team
Whether a separate evaluation harness is required	Architecture decision — development team
Final field-by-field output contract	Pending Information Architecture workstream completion
Final controlled vocabularies and list management process	Pending Information Architecture workstream completion
Government email classification rules	Delivery dependency — confirm source and timeline with GIMO (see Appendix D)
MISO approval for use of EPIC.eagle corpus as AI training data	Delivery dependency — must be confirmed before training commences (see Appendix D)
Quantified acceptance criteria and confidence threshold calibration	To be developed in Test and Acceptance Plan

22. Conclusion

The AI Classifier Tool should be designed as a practical, human-supervised DFL service that improves metadata quality, search performance, and ORCS-related tagging without overreaching into visibility control, public release, or autonomous records decisions. AICT's v1 value is straightforward: do the first pass of classification work reliably, using document content and structured context, ground every suggestion in a curated list wherever one exists, and give EAO staff a faster and better-grounded starting point for confirming DFL metadata. The human reviewer is always the authority. AICT is always the assistant. The DEMI Responsible AI Principle — reduce hallucination through curated lists; require human verification for all suggested attributes — is not a constraint layered on top of the design. It is the design.

Next step Bring your questions from this document to the walkthrough session. The walkthrough will confirm the AICT architecture, integration patterns with the DFL, and the approach for development and testing. After the walkthrough, priority actions are: confirm MISO approval process, confirm IA vocabulary timeline, assign Privacy and Security Advisor, and confirm government email classification rules source. See Appendix C and Appendix D.

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. EDRMS files take precedence over transformed or fragmented counterparts in other systems.
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. Files enter the DFL after AICT verification and EPIC.submit approval.
EPIC.system Integration	The DEMI workstream delivering EPIC.centre changes for DFL search, upload, verification, and visibility management. Informally: EPIC Integration.
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.
Visibility (DFL)	The audience access level of a DFL record: Project Team Only, All EAO, All IDIR, or Public.

Appendix B — DEMI Component Relationship Map

The diagram below shows the full DEMI ecosystem: intake channels, the AI Categorizer (AICT), the Digital File Library, and the public and operational interfaces through which files are surfaced. 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 — v1 Output Field Reference

This table is the working prototype output contract for AICT v1. It is not a locked schema. The final contract will be shaped by the Information Architecture workstream, ORCS requirements, and validated search needs.

Field	Output type	Controlled list?	Confidence displayed?	Notes
File type	Auto-apply	Yes — file extension / MIME	No	Derived from file properties
Search-index text	Auto-apply	N/A	No	Full text extraction
Duplicate flag	Auto-apply (signal)	N/A — Yes / Possible / No	Yes	Signal only; DFL handles action
File title	Suggest	No — free text	Yes + rationale	Derived from document content
Creator / organization	Suggest	Partial — EPIC.track for FN names	Yes	Free text otherwise
Created date	Suggest	No — ISO 8601 format	Yes	Extracted or inferred from content
Document type	Suggest	Yes — EAO curated list	Yes — up to 3 candidates
Topic metatags	Suggest	Yes — EAO curated list	Yes — per tag
ORCS classification	Suggest	Yes — BC Gov ORCS manual	Yes + rule explanation
Retention class	Suggest	Yes — BC Gov schedules	Yes	Linked to ORCS suggestion

Appendix C — Project Artifact Register

This register identifies every planning and delivery document the AICT project 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 AICT-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
AICT Developer Planning Brief (this document)	Business context, scope, hard limits, Responsible AI principle, intake patterns, output contract, open items.	1	Geoff McDonald	DRAFT — pre-walkthrough
AICT Privacy and Security Assessment	Privacy impact assessment and security review for AICT. Whether standalone or covered under DFL review to be determined.	1	Privacy/Security Advisor (TBD)	BLOCKED — advisor not yet assigned
Permissions Matrix (shared with DFL)	Full role-to-action mapping confirming which roles can trigger AICT and confirm suggestions.	1	Geoff McDonald + Alyd Llewellyn	NOT STARTED
AICT Output Field Contract	Final field-by-field output schema, shaped by IA workstream and ORCS requirements.	2	IA Workstream + Dev Lead	NOT STARTED — pending IA delivery
Controlled Vocabulary Files	Document type list, topic metatag list, naming convention patterns. Delivered by IA workstream.	2	IA Workstream (EAO)	IN PROGRESS
Architecture Decision Record(s)	Key AICT architecture decisions: processing pattern, model versioning, evaluation harness.	2	Saravan Azhikoden + Alyd Llewellyn	NOT STARTED
Test and Acceptance Plan	Formal acceptance criteria and confidence threshold calibration. Covers accuracy, ORCS suggestion quality, search improvement, and operational performance.	3	Geoff McDonald + Alyd Llewellyn + Dev Lead	NOT STARTED
AICT Operational Runbook	Vocabulary update procedures, model versioning, incident handling, and sustainment for DST.	4	DST	NOT STARTED

Immediate priorities after the walkthrough 1. Assign the Privacy and Security Advisor — unblocks privacy review (hard gate) 2. Confirm MISO approval process for using EPIC.eagle corpus as training data 3. Confirm delivery timeline for IA workstream controlled vocabularies — AICT grounding depends on these 4. Confirm government email classification rules source and timeline with GIMO

Appendix D — Delivery Dependencies and Governance Register

The following items are named dependencies that must be resolved before or during development. They are not open architecture questions — they are external inputs that the development team must design to accommodate.

Dependency	Required for	Owner / Source	Timing
Information Architecture workstream — controlled vocabularies and extended metadata model	Final output field contract; vocabulary grounding	IA workstream (EAO)	Must precede Work Package 6 (DFL); must be available before AICT grounding can be finalized
BC Government ORCS manual and retention schedules	ORCS and retention suggestion	BC Government / GIMO	Must be in hand before ORCS classification development
Government email classification rules	Email / MSG file classification	BC Government / GIMO	Must be confirmed before email classification goes to production
MISO approval — EPIC.eagle corpus as AI training data	AICT model training	Ministry Information Security Officer (MISO)	Must be confirmed before training commences
EPIC.track — First Nations names list integration	First Nations name classification input	EPIC.track / EPIC.system team	Must be available before AICT goes to production
EPIC.map — geospatial project linkage	Project-level geospatial metadata signal (via ProjectID)	EPIC.map / EPIC.system team	Confirm integration point at walkthrough
Permissions Matrix (shared with DFL)	Confirming which roles can trigger AICT and confirm suggestions	Geoff McDonald + Alyd Llewellyn	Must precede public-facing cutover
Privacy and Security Advisor assignment	Privacy Impact Assessment and security review	EAO / Ministry	Must be assigned before design begins
Test and Acceptance Plan	Quantified acceptance criteria and confidence threshold calibration	Development team + DST	To be produced during delivery