Design Premises

This page lists the design premises that are fundamental to Aleph. They’re used as guidelines when conceptualising new features. These premises aren’t immutable, but changing any of them would have broad implications for the scope and supported use cases of the Aleph.

Hard design premises

Access control

Each entity is part of one collection, never multiple. Access control for the entity is delegated to the collection, that is users who can edit a collection can also edit the entities inside of it. There are no free-floating entities without access control.

Immutable source data

Users shouldn’t be able to change evidence stored within the system, such as data from public records databases, or leaked information. They might be able to annotate it, but it has to be sufficiently clear what’s part of the source, and what’s user-contributed.

Edge cases

Aleph wants to accommodate extreme entities, within boundaries. A normal document might have 20 pages, but Aleph also needs to have some support for documents with 10,000 pages. A normal company might be linked to 5 other entities, but some formation agent might link to 5,000. This needs to be shown correctly.

Users

Aleph doesn’t have a definition of who is a journalist and who isn’t. Users can be part of groups, but there is no binary “journalist/not journalist” outside of that.

Language support

Aleph should support as many languages and cultural contexts as possible. When selecting NLP technology, advantage should be given to solutions with broad linguistic support.

Geographic information

Aleph shouldn’t handle geographic information like locations and boundaries. Aleph is already madly ambitious and building a GIS platform into it would exceed what’s realistic.

Descriptive, not normative

Aleph is descriptive, not normative, about geopolitical matters. There is country support for Transnistria, Abkhazia, Somaliland etc.—because these countries are mentioned in relevant data sources.

Soft design premises

Entity linkages

Entities in one collection can’t link to entities in another. This is done as a security measure at the moment, but it’s possible that this can be ensured in other ways.

Collections for users, groups

Users and groups aren’t collections. It’s possible that Aleph might automatically create a collection to match each role at some point, but this means making them do weird things, for example these collections wouldn’t be sharable.