The Portfolio of Evidence system is a critical component for managing student recertification and compliance evidence. It functions as a critical extension to the LearnDash platform, filling a functional gap related to the generation and retention of official student records. The system’s primary function is to produce and securely store evidence reports, which are packaged as downloadable ZIP archives for use in administrative, legal, and student-facing workflows.
This document provides the definitive technical specification for the Portfolio of Evidence system’s data management architecture. It details the data storage structure, file system hierarchy, and the governing policies for data retention. This specification is the primary reference for system administrators and compliance officers responsible for the system’s operation and oversight. The following sections begin by defining the core data artifact generated by the system: the Portfolio of Evidence.
The Portfolio of Evidence: Definition and Core Functions #
To understand the system’s architecture, it is essential to first define its primary data artifact. The “Portfolio of Evidence” is the central output of the system, designed to serve distinct but related functions within the organization’s recertification and compliance processes. This section details its formal definition and its two primary functions.
Definition #
A Portfolio of Evidence is a downloadable ZIP Archive that contains one or more evidence reports. This archive constitutes the formal, packaged record of student or curriculum data generated at a specific point in time.
Core Functions #
The Portfolio of Evidence serves two distinct and critical business functions:
- Student Recertification: The system provides a fundamental step in the student recertification process. Because the core LearnDash platform does not natively support a recertification workflow, this system fills a critical gap by enabling the generation and retention of the evidence reports necessary for students and administrators to complete the recertification process.
- Compliance and Legal Record-Keeping: The system has a designated capability to generate reports specifically for compliance and legal purposes. This function ensures that auditable, time-stamped records can be produced and stored in a systematic manner to meet regulatory and legal requirements.
The system’s architectural mechanism for managing these reports, based on their intended function and originator, is known as Delivery Channels.
System Architecture: Delivery Channels #
Delivery Channels are the central architectural component for managing the storage of all generated reports. This mechanism organizes the flow and storage of data based on the report’s originator (e.g., an administrator or a student) and its ultimate purpose (e.g., recertification or legal evidence). This section deconstructs how these channels govern the system’s data handling.
Defining Delivery Channels #
The primary purpose of a Delivery Channel is to define where a Portfolio of Evidence downloadable ZIP Archive is stored on the server.
It is critical to distinguish Delivery Channels from “Report Types.” Delivery Channels determine the storage location based on who the report is generated for, while Report Types determine the content within the report itself.
Channel Specifications #
The system operates with three distinct Delivery Channels, each with a specific purpose, storage location, and delivery method.
| Channel | Purpose and Initiator | Storage Location | Delivery Method |
|---|---|---|---|
| Admin | Reports generated by administrators or group leaders, typically via the “Report Form”. | /admin/ | Internal access via file system |
| Evidence | Reports generated for compliance or legal record-keeping. | /evidence/ | Internal access via file system |
| Student | Transcripts generated directly by students (e.g., via the “Recertification Nag”). | /transcripts/student/ | Delivered to the student as a direct download link |
The physical server locations designated by these channels adhere to a precise and organized folder structure, which is detailed in the following section.
Data Storage Architecture: File System Structure #
A well-defined folder structure is strategically important for effective system administration, efficient data retrieval, and the enforcement of automated data governance policies. This section provides a definitive map of the server-side storage hierarchy for all Portfolio of Evidence archives generated by the system.
Root Directory #
The main root directory for all exported ZIP archives is: /uploads/elc/export/zip/
Primary Categories #
Within the root directory, all archives are organized into two primary categories based on the report’s subject matter:
- curriculum/: Contains archives of curriculum-related reports.
- transcript/: Contains archives of transcript-related reports.
Channel-Specific Subdirectories #
Both primary category folders branch into subfolders that directly correspond to the Delivery Channels. This creates a logical and predictable path for every file stored by the system. Note that the Student Delivery Channel is designated for transcript reports only and therefore does not exist within the curriculum/ directory.
.../curriculum/admin/- Stores curriculum reports initiated by administrators or group leaders via the Report Form.
.../curriculum/evidence/- Stores curriculum reports generated for compliance or legal record-keeping.
.../transcript/admin/- Stores transcript reports initiated by administrators or group leaders via the Report Form.
.../transcript/evidence/- Stores transcript reports generated for compliance or legal record-keeping.
.../transcript/student/- Stores transcript reports initiated directly by students via the Recertification Nag.
All files stored within this architecture are subject to a universal data governance policy that manages their lifecycle on the server.
Data Governance: Storage and Retention Policy #
Data retention is a critical policy for ensuring regulatory compliance, managing server resources, and maintaining system health. This section specifies the governing rules for the lifecycle of all report archives generated by the Portfolio of Evidence system.
Policy Mandate #
All Portfolio of Evidence ZIP archives, regardless of their Delivery Channel or storage location, are governed by the “Storage & Retention” policy.
Policy Function #
This policy mandates the retention period for each ZIP archive, enforcing its automatic deletion after a configured lifecycle. These system-enforced “cleanup rules” are essential for managing the accumulation of evidence over time and ensuring that data is not retained beyond its required lifecycle.
Configuration Reference #
The specific, configurable details of the retention policy (e.g., the duration for which files are kept) are maintained within the system’s administrative settings. For detailed configuration parameters, refer to the system settings documentation found under Settings — Storage & Retention.
This architecture of channels, storage hierarchies, and retention policies provides a robust framework for managing auditable records across all student recertification and compliance workflows.
Referenced Documentation #
This technical specification is part of a larger set of system documentation. For a complete understanding of the system’s configuration and capabilities, please consult the related documents listed below. These references provide additional context on report content, archive settings, and the specific implementation of data retention policies.
- Report Types: For a detailed understanding of what content is included within different evidence reports.
- Settings — ZIP Archive: For technical details on the configuration of the ZIP archive settings.
- Settings — Storage & Retention: For the specific configuration values and settings that govern the data cleanup rules.