| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | CRITERIA | EXAMPLE | EVIDENCE | FINDINGS/OBSERVATIONS/NOTES | ACTIONS TO TAKE | WHO / AREA OF EXPERTISE | |||||||||||||||||||||
2 | TRUSTWORTHY REPOSITORIES AUDIT AND CERTIFICATION (TRAC) CRITERIA LIST | NOTE: a gap analysis of CSU repositories, but not a plan to undergo official TRAC audit; cf. ISO 16363 (Extending the OAIS reference model, and based largely on the TRAC checklist) | |||||||||||||||||||||||||
3 | A. Organizational Infrastructure | NOTE: organizational documentation needed, especially mission, succession plans, disaster plans, staffing, org charts, etc; ADD documentation TO CONFLUENCE PAGES: https://calstate.atlassian.net/wiki/spaces/DR/overview | |||||||||||||||||||||||||
4 | CRITERIA | EXAMPLE | EVIDENCE | FINDINGS/OBSERVATIONS/NOTES | ACTIONS TO TAKE | WHO & AREA OF EXPERTISE | |||||||||||||||||||||
5 | A1 Governance and Organizational Viability | ||||||||||||||||||||||||||
6 | A1.1 Repository has a mission statement that reflects a commitment to the long-term retention of, management of, and access to digital information | Mission statement for the repository; mission statement for the organizational context in which the repository sits; legal or legislative mandate; regulatory requirements | CSU Digital Repositories | Content Scope Policy (Confluence) https://calstate.atlassian.net/wiki/spaces/SCHOL/pages/762708030/Content+Scope+Policy ;Systemwide Digital Library Services (SDLS): https://www.calstate.edu/csu-system/administration/sdls/Pages/default.aspx | From ScholarWorks "SWAT" team (2019); mostly a scope note; describes collection limits in terms of research/scholarship vs. digital collections and archives; SDLS provides basic information about ScholarWorks & repositories; | devise overarching, more robust mission statement that covers more specific metrics, including organization contexts, legal mandates (i.e. CA AB 2192); OA policy, etc. | DRC & campus liaisons, contacts, COLD, ScholComm group, etc. / Policy development: at large across CSU | |||||||||||||||||||||
7 | A1.2 Repository has an appropriate, formal succession plan, contingency plans, and/or escrow arrangements in place in case the repository ceases to operate or the governing or funding institution substantially changes its scope | Succession plans; escrow plans; explicit and specific statement documenting the intent to ensure continuity of the repository, and the steps taken and to be taken to ensure continuity; formal documents describing exit strategies and contingency plans; depositor agreements. | ScholarWorks depositor agreement is here: https://scholarworks.calstate.edu/agreement | nothing found on succession and escrow; continuity documentation is not found; exit strategies and contingency plans not developed; deposit agreement is visible and referred to during submission process; | develop succession plans and continuity documentation; develop exit strategies/contingency plans for long-term change and for short-term disruptions; | COLD & CO on some basic funding procedure, general contingency plans, etc.; | |||||||||||||||||||||
8 | A2 Organizational structure and staffing | ||||||||||||||||||||||||||
9 | A2.1 Repository has identified and established the duties that it needs to perform and has appointed staff with adequate skills and experience to fulfill these duties | A staffing plan; competency definitions; job description; development plans; plus evidence that the repository review and maintains these documents as requirements evolve | At CO: [here]; at CSU campuses [here]; steering commitees/work groups, etc | Need evidence for CO roles and responsibilities; each campus has a contact/liaison for campus repository work; DRC membership (steering committee) and subcommittee membership posted; | Find evidence of staffing plan; and committment to review of these documents; | CO and campus liaisons. | |||||||||||||||||||||
10 | A2.2 Repository has the appropriate number of staff to support all functions and services | Organizational charts; definitions of roles and responsibilities; comparison of staffing levels to commitments and estimates of required effort | At CO: [here]; CSU campuses: personnel registry here: https://docs.google.com/spreadsheets/d/1mZhicB3K-xiCOVfEYr0_lykyU8-nCww5wChvX6S9vmI/edit ; DRC: https://calstate.atlassian.net/wiki/spaces/DRC/overview ; DAWG / IRWG / Digital Publishing, etc. Also: campus project managers found here: https://calstate.atlassian.net/wiki/spaces/SCHOL/pages/736428106/Campus+project+managers | No chart for CO roles and responsibilities; each campus has a contact/liaison for campus repository work; DRC membership (steering committee) and subcommittee membership posted; Campus project managers identified; | Develop clear org chart for the various levels of stakeholders in the repository system, with brief ID of roles and responsibilities; need to develop way to keep the lists up to date as well; | CO and campus liaisons. | |||||||||||||||||||||
11 | A2.3 Repository has an active professional development program in place that provides staff with skills and expertise development opportunities | Professional development plans and reports; training requirements and training budgets, documentation of training expenditures (amount per staff); performance goals and documentation of staff assignments and achievements, copies of certificates awarded. | Professional Development reports: found on local campus pertaining directly to CSUN ScholarWorks Specialist position (LSSIII); Evidence of professional development: Repository annual meetings and symposia found here: https://calstate.atlassian.net/wiki/spaces/DR/pages/13729834/Conferences+symposia | No evidence of system-wide performance goals/staff assignments; etc. Local campus only Q: Could we count the annual meeting as a "training" opportunity? If so, we could link to the recordings of past meetings. A: In part, YES, absolutely; ALSO: review if there are training manuals, documented procedures written down for each campus? | Develop wider professional development plan for those working in IRs; Collect training manuals/documentation of procedures from various campuses; compile these to create system-wide training manual; collect data on professional development for repository staff across CSU system; | ||||||||||||||||||||||
12 | A3 Procedural accountability and policy framework | ||||||||||||||||||||||||||
13 | A3.1 Repository has defined its designated community and associated knowledge base and has publicly accessible definitions and policies in place to dictate how its preservation service requirements will be met. | Mission statement; written definitions of the designated community(ies); documented policies; service-level agreements. | designated community, knowledge base are publicly accessible here: https://calstate.atlassian.net/wiki/spaces/DR/overview ; basic overview here: https://www.calstate.edu/csu-system/administration/sdls | Basic idea of the community being served; not clear on service-level agreements; need clearer preservation policies documented; | Create more specific mission statement that designates our specific community and touches upon important repository policies, esp. preservation policies; | ||||||||||||||||||||||
14 | A3.2 Repository has procedures and policies in place, and mechanisms for their review, update and development as the repository grows and as technology and community practice evolve. | Written documentation in the form of policies, procedures, protocols, rules, manuals, handbooks, and workflows; specification of review cycle for documentation; documentation detailing review, update, and development mechanisms. If documentation is embedded in system logic, functionality should demonstrate the implementation of policies and procedures | ScholarWorks wiki landing page: https://calstate.atlassian.net/wiki/spaces/SCHOL/overview ; deposit agreement document: https://scholarworks.calstate.edu/agreement | Documentation provided on the ScholarWorks Wiki; some documentation, I.e. deposit agreement, linked in the submission form; how do we deal with evolving IR practices? | Need documentation to address issues related to review, update and development as the repository grows and as technology and community practice evolve | ||||||||||||||||||||||
15 | A3.3 Repository maintains written policies that specify the nature of any legal permissions required to preserve digital content over time, and repository can demonstrate that these permissions have been acquired when needed. | Deposit agreements; records schedule; digital preservation policies; records legislation and policies; service agreements. | Preservation of materials noted here in deposit agreement: https://scholarworks.calstate.edu/agreement; service agreement also here; | Overall, covers the legal basics of digital preservation; deposit agreement secures rights for preservation actions taken; missing a wider systematic description of the process; | Create more specific documentation for digital preservation, especially for describing procedures and legal framework for the library permission to make preservation copies; also be clearer about 'limited distribution licensing; describe the steps to be taken for digital preservation and how it fits within the rights granted to the library; | DRC, ScholComm Committee, and legal experts; | |||||||||||||||||||||
16 | A3.4 Repository is committed to formal, periodic review and assessment to ensure responsiveness to technological developments and evolving requirements. | A self-assessment schedule, timetables for review and certification; results of self-assessment; evidence of implementation of review outcomes. | No formal review or timetables for certification or self-assessment; DAWG's self-assessment report serves as a good model: here: https://calstate.atlassian.net/wiki/spaces/DR/pages/2565111809/DAMS+Self+Evaluation+Toolkit+Report | No schedule or timetable found; this document serves the self-eval purpose somewhat, but is not regularly scheduled; DAWG self-assessment works on the DAM side of IR development;ScholarWorks self-assessment schedule may be necessary to develop; | Begin making plans for annual/bi-annual/five-year self-assessment schedule for the IR; | ||||||||||||||||||||||
17 | A3.5 Repository has policies and procedures to ensure that feedback from producers and users is sought and addressed over time. | A policy that requires a feedback mechanism; a procedure that addresses how the repository seeks, captures, and documents responses to feedback; documentation of workflow for feedback (i.e., how feedback is used and managed); quality assurance records | Metadata change request form: https://docs.google.com/forms/d/1UxsAMJi5oAGKSnuruPQy1eFA3qyzOcvSzKwjxK9l1pA/viewform?ts=5dc32abc&edit_requested=true | metadata change request form provides feedback mechanism; room for more topics? | widen procedures and topics for feedback | ||||||||||||||||||||||
18 | A3.6 Repository has a documented history of the changes to its operations, procedures, software, and hardware that, where appropriate, is linked to relevant preservation strategies and describes potential effects on preserving digital content. | Policies, procedures, and results of changes that affect all levels of the repository: objects, aggregations of objects; object-level preservation metadata; repository’s records retention strategy document. | Metadata change log: https://calstate.atlassian.net/wiki/spaces/SCHOL/pages/1555365901/Metadata+change+log | change log provides the documentation for changes in the description of the repository objects; | Sufficient for now; needs periodic review | ||||||||||||||||||||||
19 | A3.7 Repository commits to transparency and accountability in all actions supporting the operation and management of the repository, especially those that affect the preservation of digital content over time. | Comprehensive documentation that is readily accessible to stakeholders; unhindered access to content and associated information within repository | Development projects: https://calstate.atlassian.net/wiki/spaces/SCHOL/pages/824442963/Development+projects | Unsure of how transparent IR is in all actions; preservation remains a central philosophy, though not always entirely documented; | Develop more comprehensive documentation about preservation activities and development projects; | ||||||||||||||||||||||
20 | A3.8 Repository commits to defining, collecting, tracking and providing, on demand, its information integrity measurements. | An implemented registry system; a definition of the repository’s integrity measurements; documentation of the procedures and mechanisms for integrity measurements; an audit system for collecting, tracking, and presenting integrity measurements; procedures for responding to results of integrity measurements that indicate digital content is at risk; policy and workflow documentation. | We run fixity checks on a regular basis. When logged in, the system managers can see when the fixity checks were run. | ||||||||||||||||||||||||
21 | A3.9 Repository commits to a regular schedule of self-assessment and certification, and, if certified, commits to notifying certifying bodies of operational changes that will change or nullify its certification status. | Completed, dated audit checklists from self-assessment or objective audit; certificates awarded for certification; presence in a certification register (when available); timetable or budget allocation for future certification. | Will linking to the Steering Committee minutes be sufficient? I don't think that we really do this, so perhaps we need to talk as a committee about how best to implement this kind of audit on an annual basis? | Discuss at DRC: plan for periodic review, decide on frequency, thoroughness, subject scope, etc. | DRC members; periodic review of Repository "Health" | ||||||||||||||||||||||
22 | A4 Financial Sustainability | ||||||||||||||||||||||||||
23 | A4.1 Repository has short- and long-term business planning processes in place to sustain the repository over time. | Operating plans; financial reports; budgets; financial audit reports; annual financial reports; financial forecasts; business plans; audit procedures and calendars; evidence of comparable institutions; exposure of business plan to scenarios; STABILITY ALSO for Hyrax/Samvera: https://samvera.atlassian.net/wiki/spaces/samvera/pages/405212466/Samvera+financial+governance | Digital Repositories Committee Charge: https://calstate.atlassian.net/wiki/spaces/DRC/pages/814186534/Charge | The Digital Repositories Committee performs business planning for the CSU's systemwide digital library services. According to its charge, the committee's work includes securing ongoing funding, identification of system requirements, development of policy, and adherence to standards and best practices. | None. The DRC provides sound leadership and governance. It could offer more effective administration if it allocated funds and managed its own budget. | DRC members and Chair | |||||||||||||||||||||
24 | A4.2 Repository has in place processes to review and adjust business plans at least annually. | Business plans, audit planning (e.g., scope, schedule, process, and requirements) and results; financial forecasts; recent audits and evidence of impact on repository operating procedures. | DRC meeting notes: https://calstate.atlassian.net/wiki/spaces/DRC/pages/823197834/Meeting+Notes DRC Open forums: https://calstate.atlassian.net/wiki/spaces/DR/pages/777814164/Open+forum DRC Annual reports: https://calstate.atlassian.net/wiki/spaces/DR/pages/12877843/Reports | There are several mechanisms by which the business plan for CSU digital library services may be updated. This can be done through the work of the committee which meets monthly. CSU members can request and discuss changes in monthly open forum meetings. The Council of Library Deans may make changes to the plan based on its interpretation of the committee's reports. | None. Governance structures are in place to update business plan. | DRC members and Chair | |||||||||||||||||||||
25 | A4.3 Repository's financial practices and procedures are transparent, compliant with relevant accounting standards and practices, and audited by third parties in accordance with territorial legal requirements. | Demonstrated dissemination requirements for business planning and practices; citations to and/or examples of accounting and audit requirements, standards, and practice; evidence of financial audits already taking place. | Matt - COLD Budget Proposals | While COLD does list their budget proposal template on Confluence, there are no links to budget proposals or requests. The budget elements are also listed in the COLD Operational Handbook as listed in the COLD Meeting Notes. There are no examples of accounting and audit requirements, standards, practices, etc. | COLD should make transparent budget and planning of repositories, as well as audits. These should be posted on Confluence or other site. | ||||||||||||||||||||||
26 | A4.4 Repository has ongoing commitment to analyze and report on risk, benefit, investment, and expenditure (including assets, licenses, and liabilities). | Risk management documents that identify perceived and potential threats and planned or implemented responses (a risk register); technology infrastructure investment planning documents; costbenefit analyses; financial investment documents and portfolios; requirements for and examples of licenses, contracts, and asset management; evidence of revision based on risk. | Matt | There appear to be no documents that discuss risk threats, cost-benefit analyses, or requirements for licenses, contracts, and asset management. | These elements should be part of a strategic plan. | ||||||||||||||||||||||
27 | A4.5 Repository commits to monitoring for and bridging gaps in funding. | Fiscal and fiduciary policies, procedures, protocols, requirements; budgets and financial analysis documents; fiscal calendars; business plan(s); any evidence of active monitoring and preparedness. | NICOLE / STEVE https://www.calstate.edu/csu-system/administration/sdlc; https://www.calstate.edu/csu-system/administration/sdls/Pages/default.aspx | I don't see documentation about this in the Wiki but maybe it exists elsewhere? -Nicole. Only general langauge no direct evidence of fiscal monitoring regarding support of digital library services at SDLS and COLD websites. -Steve | Create or aggregate fiscal policy documents to share on the Wiki or SDLS website. -Nicole/Steve | COLD? | |||||||||||||||||||||
28 | A5 Contracts, Licenses and Liabilities | ||||||||||||||||||||||||||
29 | A5.1 If repository manages, preserves, and/or provides access to digital materials on behalf of another organization, it has and maintains appropriate contracts or deposit agreements. | Deposit agreements; policies on third-party deposit arrangements; contracts; definitions of service levels; Web archiving policies; procedure for reviewing and maintaining agreements, contracts, and licenses. | n/a; maybe relevant if copyright agreements for open access publishing apply here, i.e. green archiving, etc. | n/a unless each campus is seen as a separate entity, a third party; | none; but do explore relevance of the green open access policies of publishers; | ||||||||||||||||||||||
30 | A5.2 Repository contracts or deposit agreements must specify and transfer all necessary preservation rights, and those rights transferred must be documented. | Contracts, deposit agreements; specification(s) of rights transferred for different types of digital content (if applicable); policy statement on requisite preservation rights. | NICOLE/STEVE Terms of Use: https://scholarworks.calstate.edu/terms | These terms appear as a link under the home page search bar and in the footer of Scholarworks (upload Your Work). The terms as written appear to serve both the purposes of repository users (researchers) and the depostiors. However, language intended for the depositors must be parsed out and seems incomplete and/or vague. As written, the terms imply a contract only and does not specifically cite the transfer of "preservation rights". It is possible a more formal contract exists elswhere, but not found by me. I used the "Share Your Work" link in the ScholarWorks home page, to familiarize myself with the submission process. This authentication link connects depositors directly with the dashboard for adding new works but doesn't address a contract/agreement at the point of submission, where one might expect to see one. -Steve | Maybe create and link directly to a contract/agree ment specific to depositors with a check box to constitute understanding/acceptance of the terms by the depositor, and a submission button that directs depositors to the dashboard to add the work. Admittedly, my knowledge about ScholarWorks is not very deep, so if this process already exists elsewhere, perhaps we link out to it from somewhere on the home page. I recall we used to use SWORD submission for DSpace, but I don't know if that worked any differently. -Steve | ||||||||||||||||||||||
31 | A5.3 Repository has specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties. | Submission agreements/deposit agreements/deeds of gift; written standard operating procedures | TIM - Deposit agreement here: https://scholarworks.calstate.edu/agreement | Was difficult to find by browsing the site. I had to begin a submission or search 'Scholarworks deposit agreement' from web search engine to locate it. Our scholarworks folks at Chico have indicated they believe this document should be more easy to locatable. Came up in working group discussions recently as well: https://calstate.atlassian.net/wiki/spaces/DRC/pages/2843803649/2023-11-02+Meeting+notes+IRWG | It would be helpful to see this before beginning a deposit. Perhaps add a link to the main page and link prominently on the terms of use page. | ||||||||||||||||||||||
32 | A5.4 Repository tracks and manages intellectual property rights and restrictions on use of repository content as required by deposit agreement, contract or license. | A policy statement that defines and specifies the repository’s requirements and process for managing intellectual property rights; depositor agreements; samples of agreements and other documents that specify and address intellectual property rights; demonstrable way to monitor intellectual property; results from monitoring. | TIM - Covered laregely by TOU: https://scholarworks.calstate.edu/terms Also in deposit agreement: https://scholarworks.calstate.edu/agreement System manages property rights and access via visibility settings and ACLs | I don't understand what a demonstrable way to monitor copyright would look like, or how to display the results of the monitoring. | Perhaps develop IP rights workflow & tracking of take down requests/rights challenges? | ||||||||||||||||||||||
33 | A5.5 If repository ingests digital content with unclear ownership/rights, policies are in place to address liability and challenges to those rights. | A definition of rights; citations for relevant laws and requirements; policy on responding to challenges; documented track record for responding to challenges in ways that do not inhibit preservation; examples of legal advice sought and received. | policy on rights/permissions found in Terms of Use doc: https://scholarworks.calstate.edu/terms ; | Basics of rights / policy / challenges are covered here; though a stronger takedown notice may be necessary? | Sufficient for now; needs periodic review | ||||||||||||||||||||||
34 | B. Digital Object Management | https://guides.lib.vt.edu/digipres/resources; https://powrr-wiki.lib.niu.edu/images/2/20/Tech_Fundamentals_Session.pdf NOTE: from article https://www.carl-abrc.ca/wp-content/uploads/2019/12/orwg_report2_preservation_repos_en.pdf "all Samvera repositories leverage Fedora’s digital preservation features, including integrated checksums, item-level version control with rollback, and a complete audit history." ; plus Hyku documentation: https://samvera.atlassian.net/wiki/spaces/hyku/pages/718083410/Hyku+Features | NOTE: For this section on Digital Object Management, overall need of a CSU Repositories operations manual becomes evident; aligned to OAIS standard, if possible; http://www.oais.info/ , Samvera specs, Fedora, Hyku, and other 'gem' parts in samvera specs, etc. | ||||||||||||||||||||||||
35 | CRITERIA | EXAMPLE | EVIDENCE | FINDINGS/OBSERVATIONS | ACTIONS TO TAKE | WHO / AREA OF EXPERTISE | |||||||||||||||||||||
36 | B1. Ingest: Acquisition of content | NOTE: documentation needed, especially scope policies, develop CSU repositories operations manual, develop robust digital preservation policy; ADD documentation TO CONFLUENCE PAGES: https://calstate.atlassian.net/wiki/spaces/DR/overview | |||||||||||||||||||||||||
37 | B1.1 Repository identifies properties it will preserve for digital objects. | Mission statement; submission agreements/deposit agreements/deeds of gift; workflow and policy documents, including written definition of properties as agreed in the deposit agreement/deed of gift; written processing procedures; documentation of properties to be preserved. | CSU Digital Repositories | Content Scope Policy (Confluence) https://calstate.atlassian.net/wiki/spaces/SCHOL/pages/762708030/Content+Scope+Policy | From ScholarWorks "SWAT" team (2019); mostly a scope note; describes collection limits in terms of research/scholarship vs. digital collections and archives; | Update scope policy to reflect current state of repository collections; provide clearer definition of properties for deposit agreements; devise overarching, more robust mission statement that covers more specific metrics; | ||||||||||||||||||||||
38 | B1.2 Repository clearly specifies the information that needs to be associated with digital material at the time of its deposit. (i.e. SIP) | Transfer requirements; producer-archive agreements. | https://samvera.github.io/introduction.html | Some info on basics of repository structure here; not clear on this issue, though; | clarify description of information required for digital object submission; | ||||||||||||||||||||||
39 | B1.3 Repository has mechanisms to authenticate the source of all materials | Submission agreements/deposit agreements/deeds of gift; workflow documents; evidence of appropriate technological measures; logs from procedures and authentications. | MM-N/A since any of the materials in the example would be held by an individual campus? | Submission agreement during submission may cover this area; Samvera logs on submission, authenticated users provide this provenance as well; | maybe just need more clarification of processes occuring during ingest and emphasize role / purpose of the submission agreement; | ||||||||||||||||||||||
40 | B1.4 Repository's ingest process verifies each submitted object (i.e. SIP) for completeness and correctness as specified in B.1.2. | Appropriate policy documents and system log files from system performing ingest procedure; formal or informal “acquisitions register” of files received during the transfer and ingest process; workflow, documentation of standard operating procedures, detailed procedures; definition of completeness and correctness, probably incorporated in policy documents. | https://samvera.github.io/what-happens-deposit-2.0.html https://samvera.github.io/what-happens-deposit-1.0.html | Two pages on Samvera git hub describe an ingest process; though somewhat vague for this purpose; | clarify description of ingest to make clearer for users; | Digital Archives Working Group (DAWG) | |||||||||||||||||||||
41 | B1.5 Repository obtains sufficient physical control over the digital objects to preserve them (ingest: content acquisition). | Submission agreements/deposit agreements/deeds of gift; workflow documents; system log files from the system performing ingest procedures; logs of files captured during Web harvesting. | Would the terms of use (https://scholarworks.calstate.edu/terms) work for this? -Carmen | Two pages on Samvera git hub describe an ingest process; though somewhat vague for this purpose; | clarify description of ingest to make clearer for users; | Digital Archives Working Group (DAWG) | |||||||||||||||||||||
42 | B1.6 Repository provides producer/depositor with appropriate responses at predefined points during the ingest process. | Submission agreements/deposit agreements/deeds of gift; workflow documentation; standard operating procedures; evidence of “reporting back.” | MM-Do the workforms fulfill this requirement? | unsure of the reporting back; after submission this message appears: "Your files are being processed by ScholarWorks in the background. The metadata and access controls you specified are being applied. You may need to refresh this page to see these updates. " | clarify / confirm reporting back to users during submission process; upon submission there is a note, however; perhaps add more specific messaging via email contact; | ||||||||||||||||||||||
43 | B1.7 Repository can demonstrate when preservation responsibility is formally accepted for the contents of the submitted data objects (i.e., SIPs). | Submission agreements/deposit agreements/deeds of gift; confirmation receipt sent back to producer. | MM-Campus-level? | see above | add more specific messaging via email about the implications of the submission & responsibilities of the repository | ||||||||||||||||||||||
44 | B1.8 Repository has contemporaneous records of actions and administration processes that are relevant to preservation. | Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects | MM-Does the File Details page fulfill this requirement? | This may be underdeveloped in terms of documentation; system itself will log metadata to digital object, with some preservation elements included (anecdotal); | clarify this documentation | ||||||||||||||||||||||
45 | B2 Ingest: Creation of the archival package | ||||||||||||||||||||||||||
46 | B2.1 Repository has an identifiable, written definition for each AIP or class of information preserved by the repository. | Documentation identifying each class of AIP and describing how each is implemented within the repository. Implementations may, for example, involve some combination of files, databases, and/or documents. EXAMPLE: https://samvera.atlassian.net/wiki/spaces/AVALON/pages/1957954266/Archivematica+to+Avalon+Workflow | AW: nothing found for CSU documentation; | Example from Archivematica/Avalon workflow may provide useful documentation of the process; cf. https://samvera.atlassian.net/wiki/spaces/AVALON/pages/1957954275/05.+Ingest+into+Archivematica | develop documentation of archival processes for classes of digital objects archived in Samvera; creation of CSU repositories operations manual; | ||||||||||||||||||||||
47 | B2.2 Repository has a definition of each AIP (or class) that is adequate to fit long-term preservation needs. | Documentation that relates the AIP component’s contents to the related preservation needs of the repository, with enough detail for the repository's providers and consumers to be confident that the significant properties of AIPs will be preserved EXAMPLE: https://samvera.atlassian.net/wiki/spaces/AVALON/pages/1957954266/Archivematica+to+Avalon+Workflow | AW: nothing found for CSU documentation; | Example from Archivematica/Avalon workflow may provide useful documentation of the process; see ingest process doc [link above] | develop documentation of archival processes for classes of digital objects archived in Samvera; CSU repositories operations manual; | ||||||||||||||||||||||
48 | B2.3 Repository has a description of how AIPs are constructed from SIPs. | Process description documents; documentation of SIP relationship to AIP; clear documentation of how AIPs are derived from SIPs; documentation of standard/process against which normalization occurs; documentation of normalization outcome and how outcome is different from SIP. EXAMPLE: https://samvera.atlassian.net/wiki/spaces/AVALON/pages/1957954266/Archivematica+to+Avalon+Workflow | AW: nothing found for CSU documentation; | Example from Archivematica/Avalon workflow may provide useful documentation of the process; see ingest process doc [link above] | develop documentation of archival processes for classes of digital objects archived in Samvera; CSU repositories operations manual; | ||||||||||||||||||||||
49 | B2.4 Repository can demonstrate that all submitted objects (i.e. SIPs) are either accepted as whole or part of an eventual archival object (i.e. AIP), or otherwise disposed of in a recorded fashion. | System processing files; disposal records; donor or depositor agreements/deeds of gift; provenance tracking system; system log files. | We have log files for ingest as well as from migration from previous systems. We also get log files for any items that are exported. If there is an issue or problem, we will see it in the log file. | ||||||||||||||||||||||||
50 | B2.5 Repository has and uses a naming convention that generates visible, persistent, unique identifiers for all archived objects (i.e. AIPs). | Documentation describing naming convention and physical evidence of its application (e.g., logs). | We use a Handle service for persistent identifiers. See the Report on Handles, DOIs, and Other Persistent Identifiers. (CM) | ||||||||||||||||||||||||
51 | B2.6 If unique identifiers are associated with SIPs before ingest, the repository preserves the identifiers in a way that maintains a persistent association with the resultant archived object (eg. AIP). | Workflow documents and evidence of traceability (e.g., SIP identifier embedded in AIP, mapping table of SIP IDs to AIPs). | CM - We don't do this. The handles get assigned upon ingest. | ||||||||||||||||||||||||
52 | B2.7 Repository demonstrates that it has access to necessary tools and resources to establish authoritative semantic or technical context of the digital objects it contains (ie access to appropriate international Representation Information and format registries). | Subscription or access to such registries; association of unique identifiers to registries of Representation Information (including format registries); Viewable records in local registries (with persistent links to digital objects); database records that include Representation Information and a persistent link to relevant digital objects | EB: No relationship made between file format and registry | ||||||||||||||||||||||||
53 | B2.8 Repository records/registers Representation Information (including formats) ingested. | Viewable records in local format registry (with persistent links to digital objects); local metadata registry(ies); database records that include Representation Information and a persistent link to relevant digital objects. | EB: Technical metadata about file formats captured in FITS data. | File format information captured but is not related to a format registry. | none | ||||||||||||||||||||||
54 | B2.9 Repository acquires preservation metadata (ie. PDI) for its associated Content Information. | Viewable documentation on how the repository acquires and manages Preservation Description Information (PDI) | EB: Ingest process generates technical metadata using the File Information Tool Set (FITS) standards. https://projects.iq.harvard.edu/fits/home | FITS technical metadata extracted and technical metadata taken on preservation copy in Amazon glacier. | Identify what preservation metadata should be captured to enable ongoing digital preservation. | Campus repository managers. Dave Walker | |||||||||||||||||||||
55 | B2.10 Repository has a documented process for testing understandability of the information content and bringing the information content up to the agreed level of understandability. | Retention of individuals with the discipline expertise; periodic assembly of designated or outside community members to evaluate and identify additional required metadata. | MM - Working groups and previous Metadata Working Group. Pages on Confluence. | Working groups seem to have at least some of this covered ("Retention of individuals" with expertise, will be an obvious barrier). | COLD could make a commitment to retaining certain positions. Working Groups could continue after repository works are "complete." | ||||||||||||||||||||||
56 | B2.11 Repository verifies each AIP for completeness and correctness at the point it is generated. | Description of the procedure that verifies completeness and correctness; logs of the procedure. | MM-Exports through BagIt bags, which are archived. https://hyrax.samvera.org/about/managers/ | Logs of processes are available. Exports are created through BagIt. | Probably not since preservation is performed by AWS. | ||||||||||||||||||||||
57 | B2.12 Repository provides an independent mechanism for audit of the integrity of the repository collection/content. | Documentation provided for B2.1 through B2.6; documented agreements negotiated between the producer and the repository (see B 1.1-B1.9); logs of material received and associated action (receipt, action, etc.) dates; logs of periodic checks. | MM-Exports through BagIt bags, which are archived. https://hyrax.samvera.org/about/managers/ | Logs of processes are available. Exports are created through BagIt. | Probably not since preservation is performed by AWS. | ||||||||||||||||||||||
58 | B2.13 Repository has contemporaneous records of actions and administrative processes that are relevant to preservation (AIP creation). | Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects. | NS -none | I assume Samvera can create AIPs but I haven't found any information about this on Confluence | |||||||||||||||||||||||
59 | B3 Presevation Planning | ||||||||||||||||||||||||||
60 | B3.1 Repository has documented preservation strategies. | Documentation identifying each preservation issue and the strategy for dealing with that issue. | NS - none | I don't see anything on confluence, but there is a brief statement on the Scholarworks landing page that says "Long-term preservation - ScholarWorks is maintained by experts in the CSU Libraries who are committed to consistent access as systems and standards change over time." | ID & develop documentation for various preservation issues; develop strategies for each; | ||||||||||||||||||||||
61 | B3.2 Repository has mechanisms in place for monitoring and notification when Representative Information (including formats) approaches obsolescence or is no longer viable. | Subscription to a format registry service; subscription to a technology watch service; percentage of at least one staff member dedicated to monitoring technological obsolescence issues. | NS - none | I'm assuming this is something we can enable Samvera to do, but I don't see any information about this in Confluence. | review CDL's tech used for format registry; cf. their partnership with Unified Digital Formats Registry (UDFR); develop CSU plan/proposal for this; | ||||||||||||||||||||||
62 | B3.3 Repository has mechanisms to change its preservation plans as a result of its monitoring activities. | Preservation planning policies tied to formal or information technology watch(es); preservation planning or processes that are timed to shorter intervals (e.g., not more than five years); proof of frequent preservation planning/policy updates. | SK - Incomplete. See ScholarWorks page (https://scholarworks.calstate.edu/) and Agreements (https://scholarworks.calstate.edu/agreement) regarding intent of repository to provide long-term preservation. | ScholarWorks Home Page states, "Long-term preservation - ScholarWorks is maintained by experts in the CSU Libraries who are committed to consistent access as systems and standards change over time." deposit agreements list multiple policies stating the intent of the repository to provide "long-term preservation". Specific montioring activities should be defined. | Publish preservation policy to include a digital preservation strategy and terms and periods that trigger a review of the existing strategy. Include a basis for making decisions to updating the strategy. Also see B3.3, B4.1 | DAWG | |||||||||||||||||||||
63 | B3.4 Repository can provide evidence of effectiveness of its preservation planning. | Collection of appropriate preservation metadata; proof of usability of randomly selected digital objects held within the system; demonstrable track record for retaining usable digital objects over time. | SK - none found | Repository does not list preservation success metrics nor performance testing. | Publish a digital preservation policy page to include a digital preservation strategy that lists its monitoring activies. List or link to deployed preservation standards and best practices. For example, how is the OAIS model replicated in the repository? What preservation metadata are required? Which practices/tests, (such as random sampling) ensure preservation success? And at what intervals? Where might statistics on such tests be made available to the public? See B3.3, B4.1. | DAWG | |||||||||||||||||||||
64 | B4 Archival Storage and preservation / management of AIPs | ||||||||||||||||||||||||||
65 | B4.1 Repository employs documented preservation strategies. | Documentation of strategies and their appropriateness to repository objects; evidence of application (e.g., in preservation metadata); see B3.3. | SK - none found | Repository does not keep a published preservation strategy. | Publish a digital preservation policy page to include a digital preservation strategy that lists its preservation activities and those responsible for those activities. See also B3.3, 3.4. Here is a robust example: https://www.archives.gov/preservation/digital-preservation/strategy | DAWG | |||||||||||||||||||||
66 | B4.2 Repository implements/responds to strategies for archival object (ie AIP) storage and migration. | Institutional technology and standards watch; demonstration of objects on which a preservation strategy has been performed; demonstration of appropriate preservation metadata for digital objects. | TF - Nothing found for a user with my permissions level | I have limited experience with the samvera stack and don't know if it is capable of generating AIPs without an integration with something like archivematica. | Maybe create a model for an AIP if we don't have one yet for the system. | ||||||||||||||||||||||
67 | B4.3 Repository preserves the Content Information of archival objects (ie. AIPs). | Policy documents specifying treatment of AIPs and whether they may ever be deleted; ability to demonstrate the chain of AIPs for any particular digital object or group of objects ingested; workflow procedure documentation. | TF - Nothing found for a user with my permissions level | Would first need a preservation strategy, Archival Information Package generation | Create policy document/page | ||||||||||||||||||||||
68 | B4.4 Repository actively monitors integrity of archival objects (ie AIPs). | Logs of fixity checks (e.g., checksums); documentation of how AIPs and Fixity information are kept separate. | TF - Can see item level fixity checks at /partent/uid/file_sets/ | Hyrax supports "digital preservation functionalities" including fixity checking, version control and characterization of uploaded files. | |||||||||||||||||||||||
69 | B4.5 Repository has contemporaneous records of actions and administrative processes that are relevant to preservation (Archival storage). | Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects. | AWS/Samvera communicating changes made in system; | done through AWS/Samvera; not documented, but part of the system functions | Document this process; add to future CSU Repositories operations manual; adding explicit documentation important... | ||||||||||||||||||||||
70 | B5 Information Management | ||||||||||||||||||||||||||
71 | B5.1 Repository articulates minimum metadata requirements to enable the designated community to discover and identify material of interest. | Descriptive metadata. | Metadata (Confluence) https://calstate.atlassian.net/wiki/spaces/SCHOL/pages/794886289/Metadata ; metadata dictionary (summary) https://calstate.atlassian.net/wiki/spaces/SCHOL/pages/890109957/Metadata+Dictionary ; metadata dictionary (full) https://docs.google.com/document/d/10eIvlm6kglYsb4P8731qHlgK71-m9YAIYng74JfTduQ/edit | Detailed metadata schema for repository provided with notes defining use and application; includes applicability for types of digital submissions (Student research, Publications, Data, OERs); | Ongoing development through IRWG; | ||||||||||||||||||||||
72 | B5.2 Repository captures or creates minimum descriptive metadata and ensures that it is associated with the archived object (ie AIP). | "Descriptive metadata; persistent identifier/locator associated with AIP; system documentation and technical architecture; depositor agreements; metadata policy documentation, incorporating details of metadata requirements and a statement describing where responsibility for its procurement falls; process workflow documentation." | Persistent IDs created by system; metadata captured through form submissions, etc., that require elements for minimal description; core metadata described here: https://samvera.github.io/metadata_application_profile.html | found in github documentation for Samvera; | Document this process; add to future CSU Repositories operations manual; | ||||||||||||||||||||||
73 | B5.3 Repository can demonstrate that referential integrity is created between all archived objects (ie AIPs) and associated information. | "Descriptive metadata; persistent identifier/locator associated with AIP; documented relationship between AIP and metadata; system documentation and technical architecture; process workflow documentation." | not found for CSU documentation; however, fundamental to repository software; Fedora, etc. | find in Fedora / OAIS / samvera other repository architecture models & documentation; | Document this process; add to future CSU Repositories operations manual; | ||||||||||||||||||||||
74 | B5.4 Repository can demonstrate that referential integrity is maintained between all archived objects (ie AIPs) and associated descriptive information. | Log detailing ongoing monitoring/checking of referential integrity, especially following repair/modification of AIP; legacy descriptive metadata; persistence of identifier/locator; documented relationship between AIP and metadata; system documentation and technical architecture; process workflow documentation. | not found for CSU documentation; however, fundamental to repository software; Fedora, etc. | find in Fedora / OAIS / samvera other repository architecture models & documentation; | Document this process; add to future CSU Repositories operations manual; | ||||||||||||||||||||||
75 | B6 Access Management | ||||||||||||||||||||||||||
76 | B6.1 Repository documents and communicates to its designated community what access and delivery options are available. | Public versions of access policies; delivery policies; fee policies. | Terms of Use (CSU SCholarWorks) https://scholarworks.calstate.edu/terms | cf. "5. ScholarWorks Access Levels" cf. 4. Special Permissions; 6. Use of ScholarWorks Site and Content: 7. Fair Use and Other Lawful Uses: | Sufficient for now; needs periodic review | ||||||||||||||||||||||
77 | B6.2 Repository has implemented a policy for recording all access actions (includes requests, orders, etc.) that meet the requirements of the repository and information producers/depositors. | Access policies; use statements. | Terms of Use (CSU SCholarWorks) https://scholarworks.calstate.edu/terms | cf. 4. Special Permissions; 6. Use of ScholarWorks Site and Content: 7. Fair Use and Other Lawful Uses: | Sufficient for now; needs periodic review | ||||||||||||||||||||||
78 | B6.3 Repository ensures that agreements applicable to access conditions are adhered to. | Access policies; logs of user access and user denials; access system mechanisms that prevent unauthorized actions (such as save, print, etc.); user compliance agreements. | Terms of Use (CSU SCholarWorks) https://scholarworks.calstate.edu/terms | cf. 4. Special Permissions; 6. Use of ScholarWorks Site and Content: 7. Fair Use and Other Lawful Uses: | Sufficient for now; needs periodic review | ||||||||||||||||||||||
79 | B6.4 Repository has documented and implemented access policies (auth rules, auth requirements) consistent with deposit agreements for stored objects. | Access validation mechanisms within system; documentation of authentication and validation procedures. | We use the CSU single sign on to authenticate users. This process ensures that users are who they say they are. The system maintains "groups" that define access. We also have administrative sets that define which groups can do for each campus. The roles give us the authorization. And the SSO give us the authentication. | ||||||||||||||||||||||||
80 | B6.5 Repository access management system fully implements access policy. | Logs and audit trails of access requests; information about user capabilities (authentication matrices); explicit tests of some types of access. | We track every request that comes in through log files. | ||||||||||||||||||||||||
81 | B6.6 Repository logs all access management failures, and staff review inappropriate "access denial" incidents. | Access logs; capability of system to use automated analysis/monitoring tools and generate problem/error messages; notes of reviews undertaken or action taken as result of reviews. | EB: Access denial or failed delivery is captured in server log files. | ||||||||||||||||||||||||
82 | B6.7 Repository can demonstrate that the process that generates the requested digital object(s) (ie DIP) is completed in relation to the request. | System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production; test accesses to verify delivery of appropriate digital objects. | EB: No report made for delivery failure. | ||||||||||||||||||||||||
83 | B6.8 Repository can demonstrate that the process that generates the requested digital objects (DIP) is correct in relation to the request. | System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production. | MM: Logs of user access for statistics. Schematics of system: https://github.com/samvera/samvera.github.io/blob/main/pages/samvera/1_new_start_here/our_technology_stack.md | Logs of submissions are available mostly for statistical purposes, but require searches. | None seem necessary unless hosting moves away from AWS | ||||||||||||||||||||||
84 | B6.9 Repository demonstrates that all access requests result in a response of acceptance or rejection. | System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production. | MM: Logs of user access for statistics. Schematics of system: https://github.com/samvera/samvera.github.io/blob/main/pages/samvera/1_new_start_here/our_technology_stack.md | Logs of submissions are available mostly for statistical purposes, but require searches. | None seem necessary unless hosting moves away from AWS | ||||||||||||||||||||||
85 | B6.10 Repository enables the dissemination of authentic copies of the original or objects traceable to originals. | System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; production of a sample authenticated copy; documentation of community requirements for authentication. | NS - Yes? I'm guessing this info can be found in Samvera documentation. | ||||||||||||||||||||||||
86 | C. Technologies, Technical Infrastructure and Security | ||||||||||||||||||||||||||
87 | CRITERIA | EXAMPLE | EVIDENCE | FINDINGS/OBSERVATIONS | ACTIONS TO TAKE | WHO / AREA OF EXPERTISE | |||||||||||||||||||||
88 | C1 System Infrastructure | NOTE: organizational documentation needed, especially risk assessment, community profiles, software/hardware justifications, disaster & recovery plans, etc; ADD documentation TO CONFLUENCE PAGES: https://calstate.atlassian.net/wiki/spaces/DR/overview | |||||||||||||||||||||||||
89 | C1.1 Repository functions on well-supported operating systems and other core infrastructional software. | Software inventory; system documentation; support contracts; use of strongly community-supported software (i.e., Apache). | NS - Samvera/Hyrax is widely used in libraries so I'm assuming it is a well-supported operating system. This is probably better answered by Dave. | None | |||||||||||||||||||||||
90 | C1.2 Repository ensures that it has adequate hardware and software support for backup functionality sufficient for the repository's services and for the data held, eg metadata associated with access controls, repository main content. | Documentation of what is being backed up and how often; audit log/inventory of backups; validation of completed backups; disaster recovery plan—policy and documentation; “firedrills”—testing of backups; support contracts for hardware and software for backup mechanisms. | TF | ||||||||||||||||||||||||
91 | C1.3 Repository manages the number and location of copies of all digital objects. | random retrieval tests; system test; location register/log of digital objects compared to the expected number and location of copies of particular objects. | TF - None found | When testing random retrieval, what source are we to compare? Front end vs. repository data? Preservation data? | Much of this can be scripted with results written to log files or a DB. would weed to define test parameters. | ||||||||||||||||||||||
92 | C1.4 Repository has mechanisms in place to ensure any/multiple copies of digital objects are synchronized. | Workflows; system analysis of how long it takes for copies to synchronize; procedures/documentation of operating procedures related to updates and copy synchronization; procedures/documentation related to whether changes lead to the creation of new copies and how those copies are propagated and/or linked to previous versions. | AWS: sync being done thru AWS in terms of long term preservation; fixity not necessary; but if an issue, we can sync with AWS to fix a broken issue; | ||||||||||||||||||||||||
93 | C1.5 Repository has effective mechanisms to detect bit corruption or loss. | Documents that specify bit error detection and correction mechanisms used; risk analysis; error reports; threat analyses. | Yes, bitsum checks and fixity checks are run on the regular. Hyrax runs fixity checks and reports corrupted files. Previous version of file can be recovered from glacier storage. | ||||||||||||||||||||||||
94 | C1.6 Repository reports to its administration all incidents of data corruption or loss, and steps taken to repair/replace corrupt or lost data. | Preservation metadata (e.g., PDI) records; comparison of error logs to reports to administration; escalation procedures related to data loss. | Hyrax runs fixity checks and reports corrupted files. Previous version of file can be recovered from glacier storage. | Only one instance of a corrupted file. Run a process to recover glacier copy. Contact owner that file has been restored. | Possible codification into policy, though a precident for action does already exist. | Dave Walker | |||||||||||||||||||||
95 | C1.7 Repository has defined processes for storage media and/or hardware change (eg. Refreshing/migration). | Documentation of processes; policies related to hardware support, maintenance, and replacement; documentation of hardware manufacturers’ expected support life cycles. | MM - Hosting through AWS, which controls all hardware concerns. Quarterly updates/Open Forums for any changes that could be made on the part of CO. | Storage/hardware modifications would be done by AWS. The CO would announce any relevant changes/impacts through normal reporting methods. | None | ||||||||||||||||||||||
96 | C1.8 Repository has a documented change management process that identifies changes to critical processes that potentially affect the repository's ability to comply with its mandatory responsibilities. | Documentation of change management process; comparison of logs of actual system changes to processes versus associated analyses of their impact and criticality. | NS - nothing published that I can find for our repository. | There is a maintenance policy for Hyrax here: https://github.com/samvera/hyrax/blob/main/documentation/MAINTENANCE.md | Develop a policy and documentation for this | ||||||||||||||||||||||
97 | C1.9 Repository has a process for testing the effect of critical changes to the system. | Documented testing procedures; documentation of results from prior tests and proof of changes made as a result of tests. | SK - Yes for Hyrax developent; No known published documentation for testing critical changes regarding local customizations. | Hyrax follows Semver for versioning - https://semver.org/. For local system customizations, this documentation addresses workflows performed or maintained by: CO personnel; by third party developers; or a combination of both. | Consult David Walker regarding system testing documentation. Create and post documentation if none exists. | Hyrax GitHub, David Walker; Developers (SoftServe) | |||||||||||||||||||||
98 | C1.10 Repository has a process to react to the availability of new software security updates based on a risk-benefit assessment. | Risk register (list of all patches available and risk documentation analysis); evidence of update processes (e.g., server update manager daemon); documentation related to the update installations. | TF - Nothing publishined on front end. | Typically, on the OS level, this is all found on the backend of the host machine. At the application level, this is recorded in a config file on the server or in the DB | Need to consult with CO developers. | ||||||||||||||||||||||
99 | C2 Appropriate Technologies | ||||||||||||||||||||||||||
100 | C2.1 Repository has hardware technologies appropriate to the services it provides to its designated communities and has procedures in place to receive and monitor notifications, and evaluate when hardware technology changes are needed. | Technology watch; documentation of procedures; designated community profiles; user needs evaluation; hardware inventory. | Appropriate hardware tech assumed; community profiles are not found; | Repository based on appropriate hardware for sustainable project; unclear where documentation for this is kept; community profiles are basic: CSU campus scholars/students, but this is not documented; not sure where inventory is; | Develop documentation for hardware technology; document community profiles (i.e. who we serve) and how hardware is appropriate for community uses; develop a process for evaluating hardware needs; | ||||||||||||||||||||||