Legal and privacy.

Data processing

Signum processes incident conversation content on behalf of the customer. The customer’s ITSM platform remains the system of record; Signum holds derived state, partitioned by deployment.

One exception. Where a ticket reaches its platform’s attachment limit, Signum retains the transcript revisions that no longer fit, so that no part of the conversation is lost. This happens only on capacity exhaustion and only for the revisions the ticket cannot hold; the ticket is flagged when it occurs. Those records are held under the same retention policy, encryption and deployment partitioning as everything else, and are never pruned to reclaim space.

What Signum Memoria processes

Where Memoria is in use, it reads from the sources you put on its allow-list and never writes back to them. The memory it builds is held as Markdown pages in a Git repository you own and control, plus an index derived from those pages. The index is rebuildable from the files; the files are the record. Content reaches the corpus only after passing a content gate and a named human approval, and every read and write is written to an append-only audit log.

Sub-processors

The model provider is a sub-processor and is chosen by the customer at configuration time, including self-hosted endpoints where no third party is involved.

Where Memoria is in use, the embedding and reranking provider is also a sub-processor, because page content is sent to it to be indexed and scored. Voyage and Amazon Bedrock are the shipped options; an equivalent provider may be substituted, and either stage can be disabled entirely. Whichever is configured is named in your data-processing terms before any content is sent to it.

Contact

Data protection enquiries: hello@signum.uno.