System overview

What this system is

The aLife Sample Database is a website for collecting and exploring audio samples for the aLife project. People can listen to samples, read descriptions, search and compare the collection, and—if they have an account with the right role—contribute recordings or describe sounds.

This guide is written for project decision-makers and operators. It explains the service in everyday terms; it is not a technical deployment manual or a legal opinion.

What the system does

• Makes the collection available: Visitors can browse, search, listen to, and download original audio. Samples can include a title, written description or transcript, creator credit, license information, and technical details.
• Collects community descriptions: Only signed-in Authors can submit or revise ratings using 15 sound descriptors. Guests and signed-in Users can see descriptors; Users can reveal them sample by sample but cannot rate. Administrators cannot upload or rate. Each descriptor uses strict majority; a tie falls back to the original Author-uploader's choice when available.
• Accepts samples from Authors: Authors upload audio with a title, written text alternative, creator credit, a selected license, and affirmative agreement to that license. Authors may also submit initial descriptors. Uploads are limited to 100 MB. The service measures available technical metadata and prepares compressed playback. The initial catalog includes six Creative Commons licenses and CC0 1.0; administrators can add further options after project review.
• Helps people find samples: Visitors can search by text, filter by upload date, license and technical characteristics, and find samples with selected descriptors. Similarity comparisons use descriptors, technical details, and a signal-based profile.
• Provides administrator tools: Administrators can create User and Author accounts (with first name, last name, email, username, and password), add license choices, review the collection, remove samples, and download database or CSV exports. Removing a sample is the Administrator's only operation on samples.

The sound profile used for similarity is a mathematical summary of audio signal characteristics. It is not a transcript, an understanding of what a sound means, or speaker identification.

What the system does not do

• It does not provide managed hosting or a project team to operate the service. Someone must maintain the host, deployment, accounts, and response procedures.
• It does not automatically schedule, encrypt, move, retain, or monitor production backups. The downloadable database archive is not a complete backup: audio files and deployment secrets are separate.
• It does not automatically transcribe speech, confirm that a description is meaningful, verify copyright ownership or consent, or determine whether an upload is appropriate.
• It does not verify account email addresses or provide self-service password recovery or account profile changes. Administrators must provision accounts and communicate credentials securely.
• It does not automatically moderate every upload, review rights complaints, or guarantee that a sample is lawful, safe, accurate, or suitable for a particular use.
• It does not grant a license to older samples that have no license recorded. The displayed license status must be checked for each sample.
• It does not guarantee uninterrupted availability, recovery within a particular time, or successful restoration just because an archive file was created.
• It does not guarantee legal or accessibility compliance. The operator and project must arrange institutional review and accessibility testing.

Production responsibilities

Before real users or research data are placed in production, project leadership should assign named owners for service operation, data protection, content and rights complaints, backups, and incident response. The repository provides deployment configuration and instructions, but the institution must supply and operate the actual service.

Backups and recovery

The database and uploaded audio must be backed up together. Database records refer to audio files; having only one can leave an incomplete collection. The admin database dump is useful for data export, but contains sensitive information such as password hashes and sessions, and does not include uploaded audio, deployment secrets, or database roles.

As a starting recommendation, arrange automated, monitored daily backups and an additional backup before releases or database changes. Keep an encrypted, access-restricted copy off the production host in a separate failure domain. Agree on retention and deletion rules, monitor failures and storage space, and protect recovery credentials separately. Test a complete restore into an isolated environment at least quarterly and after important changes. Set an acceptable data-loss window and recovery time with project leadership; if daily backups are insufficient, commission and test a more frequent recovery method.

The technical README in the project repository contains a manual backup example and configuration and scheduling stubs. These are examples, not an installed backup service. An operator must implement and test the job, off-host destination, alerts, retention, and full restore process.

Other production checks

• Use the production Compose configuration, HTTPS reverse proxy, protected secrets, and dedicated database roles. Do not deploy development accounts or defaults.
• Maintain the operating system, application dependencies, PostgreSQL, and backups. Test releases and database changes before deployment; preserve release and migration records.
• Make sure people are assigned to manage accounts, respond to user requests and content notices, and investigate failures.
• Have the institution review privacy notices, licensing and rights processes, data retention, hosting obligations, and accessibility requirements before public launch. Confirm actual hosting, backup, and log retention.
• Rehearse release rollback and data recovery. Restoring a database without its matching audio archive can leave records and files inconsistent.

Important data and rights notes

New uploads require the Author to confirm that they have the rights and permissions needed to publish the recording, provide a creator credit, choose a catalog license, and agree to that license. The sample and creator credit are public. The selected license name and link are displayed with the sample. CC0 is a public-domain dedication tool, not a Creative Commons license; review all initial and administrator-added options with the institution before use. Do not upload confidential or sensitive recordings. Removing a sample from this service cannot necessarily remove copies already obtained under a valid license.

Some older samples may have no license recorded. Do not treat them as covered by a license unless the rights holder has given valid authorization. Check the sample's displayed status and the project's terms before reusing material.

Administrators collect account first and last names and email addresses when creating new accounts. These details are used for account administration and are not displayed in public sample listings. The application does not verify email ownership; the institution should confirm appropriate collection, access, retention, and deletion rules.

The admin database dump contains sensitive account and session data and must be protected. CSV exports omit contributor identifiers, account credentials, sessions, file paths, and audio signal profiles, but include public sample information and may contain user-provided text. Treat them as project data and apply institutional access and retention rules.