Permissions
Control who can use each recording.
Set permissions for searching, playback, annotation, export, training and publication. Each is denied until granted, applies to a time range of a recording rather than the whole file, and is checked at every step of a search.
Try it
What one access decision changes.
Change a recording’s status or its sharing settings and watch what a search may scan, what it may list, and what a shared copy may carry. The decisions below are made by the Workspace’s own permission code, running in this page; the ranking is the reference engine’s real result for the passage “go by submarine”.
| Recording | Status | Search | Shared copy may include | Scanned by a search | Can appear as a result | Can be searched from | A shared copy carries |
|---|---|---|---|---|---|---|---|
| Gotten the messagebernatitus-03 | — | — | — | — | |||
| Their own minefieldbernatitus-02 | — | — | — | — | |||
| Home at almost one in the morningpepys-01 | — | — | — | — | |||
| Tea and chocolate cakebernatitus-05 | — | — | — | — |
Results for “go by submarine”
- 1Gotten the message0.538
- 2Their own minefield0.562
- 3Taking us so long to get out there0.620
- 4Home at almost one in the morning0.664
- 5The slapping of the water0.693
- 6Tea and chocolate cake0.693
- 7Not very late, to supper and to bed0.710
These rules govern one person’s Workspace on one device: what its searches may touch and what leaves it in a shared copy. They are not access control between people. That is the job of the community deployments below.
In the community deployments
Access-control testing
In the operating pilots, access is decided per person, per collection, by the community’s own administrators, and each of the 8 collections has a documented permission policy. The controls were tested by trying to break them: unauthorized requests, revoked access, stale indexes, cached results.
0
unauthorized disclosures
across 12,486 automated adversarial access-control cases.
100%
of revoked-access cases denied
in 27 revocation and withdrawal exercises, including stale indexes and cached results.
100%
of ingested recordings linked to an authorization
in the pilot audit: no recording without a documented decision behind it.
0
recordings used to train outside models
without separate, express authorization.
Results hold within the defined test environment, at the application level.
Permission simulator
Try a policy
Change the role, purpose or season below and watch which actions a policy allows. Listening, searching, annotating, exporting, training and publishing are six separate decisions.
Example: a seasonal teaching
Permissions for language work
View the example policy document
An example policy, for explanation; it changes no real permission. In a deployment, identities and permissions come from the local server, and cultural conditions are defined by the responsible community. This example is not a Local Contexts Label or an endorsed policy template.
Private-audio stewardship
Consent, withdrawal and cleanup for private recordings
Restricted and private collections have a second, independent authorization layer. A request must pass the existing interval policy and every linked consent must still be active, unexpired and explicitly allow that exact action.
Explicit consent scope
Search, play, annotate, export, train and publish are recorded separately. A missing action is rejected rather than inferred, and one participant's revocation closes that action for the recording.
Withdrawal survives old backups
Before local cleanup, Tierline writes a privacy-minimized HMAC tombstone to a recovery ledger kept outside the workspace. Restoring an older encrypted backup must replay later tombstones before the restored workspace is promoted, preventing stale data from silently reappearing.
Cleanup stays accountable
Managed private exports carry recording lineage. External ingest media is tracked as a physical artifact rather than silently assumed deleted. The software can mark cleanup due; a human steward must record what happened to material outside Tierline.
Software can enforce a decision, but only a community can make it. Tierline opens restricted or private collections only after an operator records the community’s approval, with accountable roles and a deployment that does not default to a public cloud; the approval itself is the community’s, made outside the software.
The engine
Six permissions, each denied until granted
Every policy is checked at ingest against the same required fields, types, ranges and closed action/principal sets published in configs/policies.schema.json. The six boolean actions default to false: a policy must explicitly grant an action for it to be permitted at all, for anyone.
- search
- find in an index
- play
- listen to audio
- annotate
- attach review labels
- export
- write EAF / TextGrid
- train
- use for model training
- publish
- release externally
A policy also names its principals (user IDs and roles) and conditions (allowed months, allowed purposes). permits(policy, identity, action) is the central policy predicate: action flag, then principal membership, then time-of-year and purpose. Current active-version and interval checks gate access before that predicate is trusted. A policy's canonical hash is computed from its normalized JSON, so two differently-formatted documents describing the same rule collapse to one identity.
Where policy attaches
Permissions attach to time ranges
Access attaches to policy_interval rows: explicit time ranges on a specific derivative, each pointing at exactly one policy. Intervals on the same derivative are asserted non-overlapping in code (policies.inheritance.assert_non_overlapping) — if two proposed intervals overlap, the system raises rather than silently picking one.
This is what lets one two-hour recording carry an openly citable teaching excerpt and a ceremonially restricted passage as two independently governed spans of the same file.
Enforcement
Permissions are checked throughout a search
SearchEngine.authorized_policy_hashes evaluates active policies against the requesting operator's identity and purpose before any index file is opened. search_authorized then reads only those shards and suppresses any indexed window that is no longer contained in a current active interval for that policy hash.
Material under a policy that does not grant search to that operator is never admitted to the candidate set. Stale vectors may remain in an old local shard until maintenance, but current interval checks prevent them from surfacing after reassignment or deactivation. Candidate merging and the configured before/after expansion are bucketed and clipped to the current policy interval, so an authorized hit cannot pull adjacent, differently-governed frames into DTW. Authorization is checked again immediately before reranking and again on the final matched span.
Using a stored recording as a query is checked the same way: the requested span must lie entirely inside one current active policy interval, and the operator must hold both search and play on that interval, or the request is refused before any frames are read. Review, export and UI playback re-check current authorization rather than trusting a historical result.
Derived artifacts
Derived files keep their recording’s permissions
A recording produces one derivative per source channel; derivatives receive policy intervals; intervals produce policy-bearing feature stores; feature stores are grouped into per-policy index shards; searches produce policy-bearing results; reviewed results can produce exports. An export's companion manifest records every contributing policy hash, while the export database row stores a single policy hash only when exactly one applies.
That is why an access decision made once at ingest continues to hold at query time and at export time without anyone re-applying it by hand.
Revocation
Revoking access
Adding a newer version of a policy deactivates the older active version; explicit deactivation is also supported. Until intervals are deliberately reassigned, access fails closed. Existing searches, reviews, exports and playback are re-authorized against the current interval map. Restricted and private recordings also have a governed withdrawal path: it revokes consent, replaces intervals with default deny, invalidates whole affected index generations, quarantines managed derived bytes, and can purge the local recording. Forensic secure deletion of SSD or cloud remnants, and deletion of operator-owned copies outside Tierline, remain deployment and physical-cleanup responsibilities.
Accountability
Hash-chained audit log
Commitments
What Tierline does not do without a partner’s authorization
- Upload restricted partner audio to third-party AI APIs.
- Use partner recordings to train unrelated general-purpose AI models.
- Combine one community's restricted material with another's dataset.
- Publish audio, transcripts, screenshots, examples, or cultural material merely to promote Tierline.
- Condition technical assistance on permission to publish research.
- Claim cultural authority over material supplied by a partner.
- Retain partner-derived artifacts after a valid deletion or exit request where the agreement requires deletion.
- Override community-defined access protocols because a technical system finds them inconvenient.
Any different use requires explicit partner authorization appropriate to that material and that context — expressed as a policy grant, recorded, and revocable.
Commitments
Principles
Rights and cultural authority
Tierline claims no ownership of partner recordings or cultural material. Pre-existing legal rights remain where they reside. The default contractual position is that the partner controls access to project copies and to Tierline-generated derivatives — indexes, alignments, annotations, embeddings, adaptation artifacts — subject to any pre-existing rights in the underlying material.
Legal ownership and cultural authority are not always the same thing. Tierline treats community-defined protocols as substantive design requirements even where copyright law does not express them.
Paying for community expertise
When consultation goes beyond ordinary project coordination, the goal is to include compensation or honoraria in the project budget rather than assume community expertise will be donated. Where the budget cannot cover it, that is said before anyone is asked for substantial time.
Using Tierline does not mean joining a study
A community should be able to use Tierline without becoming a research subject or publication case study. If a partner does agree to research or publication, the agreement specifies what may be reported, whether the partner is named, who reviews drafts, what can be withdrawn, and how contributors are credited.
Exit
A partner can end the work at any time, for any reason or none. On request Tierline provides a full export in open, documented formats and deletes its copies where the agreement requires deletion. Exit terms are written down before restricted material changes hands.
Frameworks and licensing
Where the design vocabulary comes from
Tierline uses the CARE Principles for Indigenous Data Governance — Collective Benefit, Authority to Control, Responsibility, Ethics — as a governance reference.[10] Mukurtu CMS's protocol model (seasonal, gender-based, sacred/ceremonial, administrative and membership-based restrictions layered over a simple public/private flag) is the closest existing analogue to the interval-scoped, six-action policy above.[11] Local Contexts Traditional Knowledge Labels remain something only a community can apply to its own material; Tierline does not apply them on a community's behalf.[12]
Tierline's original source is Apache-2.0. Third-party libraries, pretrained model weights and datasets retain their own terms — including the one GPL-3.0 dependency (Allosaurus, kept as a separable optional subprocess adapter for exactly this reason). Full list on Sources.