Every vendor that touches organizational data makes a claim about what it accesses. Most claims are vague by design — broad enough to cover the actual data handling model while sounding narrow enough to pass a cursory review. "We only access what we need." "We respect your privacy." "Your data is safe with us."
These are not useful statements for a security evaluation. They describe intent, not architecture. And when the tool in question reads signals from your organization's collaboration, project management, and development systems — the tools where your team communicates, coordinates, and delivers — the evaluation requires precision, not reassurance.
This post explains, in plain language, what it means for a tool to read behavioral metadata rather than content. It is written for the IT lead, CISO, or procurement reviewer who needs to understand the data handling model in concrete terms — what is accessed, how it is processed, what is stored, and what is never retained. It is also written for the internal champion who needs to forward exactly this explanation to the person conducting the review.
The two categories of organizational data
Every tool that integrates with your communication and collaboration systems interacts with data that falls into one of two categories.
**Content** is the substance of communication and work: the body of a message, the text of an email, the description in a ticket, the notes in a calendar event, the content of a document. Content carries meaning that is specific to the individuals involved and the context of the interaction. It is inherently sensitive because it is inherently personal — it reflects what people think, say, write, and decide.
**Behavioral metadata** is the structural pattern of activity: who communicated with whom, when the communication occurred, how frequently, and in what pattern. When a task changed state. Which teams are coordinating and at what cadence. Where delivery activity is concentrated and where it has gone quiet. Behavioral metadata describes the shape of work — not the substance of it. It answers questions like "are these two teams still coordinating daily?" without answering "what are they discussing?"
The distinction is not a matter of sensitivity level — both categories can contain information an organization wants to protect. The distinction is architectural: what data a system is designed to ingest, process, store, and surface determines its risk profile, its privacy characteristics, and its suitability for organizational use.
What "reads signals" means in practice
When Rhenari integrates with an organization's tools — a project management system, a communication platform, a development environment, a calendar — it reads behavioral metadata. The specific signals vary by integration, but the pattern is consistent:
From communication systems, it reads structural metadata: message timestamps, participant identifiers, channel or conversation identifiers, message frequency patterns. It does not read message bodies. From project management systems, it reads activity metadata: task state transitions, assignment changes, sprint boundary events, delivery timestamps. It does not read the full text of ticket descriptions or comments. From calendar systems, it reads scheduling metadata: meeting occurrence, participant overlap, meeting cadence changes. It does not read calendar notes, agenda text, or meeting content. From development systems, it reads delivery signals: commit frequency, pull request lifecycle events, deployment cadence. It does not read code content or commit messages for analytical purposes.
The consistent principle: the system reads the pattern — the who, when, how often, and in what structure — not the substance of what was communicated, written, or discussed.
The ephemeral processing model
There is a specific architectural nuance that matters for security evaluation: the distinction between reading content for storage and reading content for classification.
Rhenari's AI may, in certain processing paths, read source content ephemerally — accessing a message or ticket in memory to classify the type of activity it represents (a decision event, a coordination interaction, a delivery milestone). This classification is necessary to distinguish between different kinds of organizational activity and to produce accurate execution intelligence.
The critical architectural constraint: this content is processed in memory and immediately discarded. It is not written to any persistent storage. It is not logged. It is not retained in any form. The structured analytical output of the classification — the metadata label, the activity category, the pattern signal — is persisted. The source content that was read to produce the classification is not.
This is the difference between a system that reads a letter to note that a letter was sent, and a system that reads a letter and files a copy. The first produces metadata. The second stores content. Rhenari's architecture produces the first and architecturally prevents the second.
For the security reviewer: the question to verify is whether this constraint is enforced at the architecture level (the processing pipeline is designed so that content cannot be written to persistent storage) or at the policy level (the system could store content but a policy says it won't). Rhenari's model is architecture-level. The processing path that handles ephemeral content access does not have a write path to persistent content storage. The constraint is structural, not procedural.
What is stored
Precision matters here. The following is what Rhenari persists in its data platform:
**Tenant configuration:** role assignments, department structure, seat allocations, integration settings, alert preferences, workflow configuration. This is operational data required to run the product.
**Integration credential references:** stored in a dedicated Key Vault, namespaced by tenant. The credentials themselves are encrypted and isolated. They are never exposed through the product UI or API. They are resolved at runtime by the analytics pipeline and are not accessible to end users or to other tenants.
**Behavioral metadata and analytics datasets:** communication frequency patterns, task transition timelines, coordination graphs, delivery cadence baselines, aggregated cross-team interaction patterns. This is the analytical core — the metadata that has been normalized, aggregated, and scored. Individual identifiers are pseudonymized before entry into persistent analytics datasets wherever the analytics design does not require live identifiers.
**Scored outputs:** Momentum scores, Confidence scores, alert states, insight records, trend baselines. These are the interpreted outputs delivered to the product interface — the intelligence layer.
**Workflow records:** decision records, communication workflow entries, and other structured outputs generated through the product's active workflow tools.
**What is not stored:** message bodies, email bodies, calendar notes, ticket descriptions, document content, meeting transcripts, or any long-form text from any source system. This is not a retention policy applied to stored content. The content is never written to storage in the first place.
What is surfaced
The data that reaches the product's user interface determines the practical impact on the organization. Rhenari surfaces team-level and department-level patterns. It does not surface individual-level behavioral data.
A Tenant Admin or Department Admin sees: Momentum and Confidence scores for their scope, trend data, alerts, and insights. They see patterns like "cross-functional coordination on Initiative X has declined over the past two weeks" or "delivery rhythm on Department Y's primary workstream has shifted from the baseline." They do not see: "Person A sent twelve messages on Tuesday" or "Person B's activity decreased by 30%."
Minimum group sizes are enforced. Aggregations that would collapse to a group smaller than the configured threshold — default of three — are suppressed. This prevents any team-level output from functioning as a proxy for individual behavior.
For the security reviewer: ask whether the surfacing restriction is enforced at the application layer only or at the analytics layer as well. In Rhenari's model, the minimum group size is enforced in the analytics pipeline itself — the scored output that reaches the serving database has already been aggregated past the individual level. The UI cannot display what the pipeline did not produce.
How integration credentials are handled
Integration credentials — the tokens, API keys, or authorization grants that allow Rhenari to pull data from source systems — represent a specific category of sensitive data that warrants its own evaluation.
Rhenari stores integration credentials in a managed Key Vault, namespaced by tenant and integration. Credentials are not stored alongside analytics data. They are not accessible through the product UI or API. They are not embedded in pipeline trigger payloads. They are resolved at runtime by the analytics pipeline through controlled secret references — the pipeline requests the credential it needs for a specific tenant's specific integration, uses it for the data pull, and does not retain or log the credential value.
For the security reviewer: the questions to ask are — where are credentials stored? Are they in the same data store as analytics data or in a separate, dedicated secret management system? Who can access them? Are they exposed through any product surface? How are they resolved at runtime? What happens to them during offboarding?
Encryption and transport
Data is encrypted at rest using AES-256, enforced at the infrastructure level across all persistent storage: the operational database, the analytics data stores, the Key Vault, and the serving outputs. Data in transit is protected by TLS 1.2 or higher across all application, integration, and bot traffic. There are no exceptions for internal service-to-service communication — all transport within the platform boundary is encrypted.
What happens when the contract ends
Offboarding is the final test of a vendor's data handling claims. A vendor that stores content has a more complex deletion problem than one that stores metadata — because content carries more identifiable and sensitive information per record.
Rhenari's offboarding process: the client may request an export of scored output history, insights and alert history, workflow records, and configuration snapshots. Following the export window, Rhenari disables access and deletes tenant data in accordance with the offboarding policy and contractual terms. Deletion confirmation is available where contractually required.
No infrastructure teardown is required on the client side. Rhenari does not deploy anything into the client's cloud environment. Revoking the application's access to source systems completes the client-side offboarding.
The summary for the security review
For the reviewer who needs the data handling model in a single reference:
**Accessed:** behavioral metadata — communication patterns, task transitions, coordination structures, delivery cadence. Content is read ephemerally for classification in specific processing paths and immediately discarded.
**Stored:** tenant configuration, credential references (in dedicated Key Vault), pseudonymized behavioral metadata, aggregated analytics datasets, scored outputs, workflow records. Message bodies, email content, calendar notes, and long-form text are never persisted.
**Surfaced:** team-level and department-level patterns only. No individual-level behavioral data. Minimum group sizes enforced at the analytics layer.
**Encrypted:** AES-256 at rest, TLS 1.2+ in transit, across all storage and transport surfaces.
**Isolated:** tenant-scoped at every layer — identity, API, secret storage, analytics pipeline, serving database.
**At offboarding:** export available, data deleted per contract, no client-side teardown required, deletion confirmation available.
This is what "we read signals, not content" means in architectural terms. Not a positioning statement. A data handling model — verifiable, testable, and designed to make the security review straightforward rather than adversarial.
