# Timeline
Source: https://docs.avra.ai/changelog/index

Product updates and announcements

<Update label="July 2026">
  ### Batch v2 & Files API

  A new generation of the Batch API is available, improving flexibility while also improving security and throughput.
  Uploads move from one-file-at-a-time batch inputs to multi-file **upload sessions** with MD5 integrity checks.
  Batch executions follow that move, allowing multi-file inputs that now support Parquet extensions, deprecate JSONL and keep the support for CSV for low complexity schemas.

  * `POST /v2/api/files/upload` — request upload URLs for one or more files.
  * `GET /v2/api/files` — list uploaded files and their metadata.
  * `POST /v2/api/batches` — start a batch prediction for one or more files.
  * `GET /v2/api/batches/{id}/result` — retrieve a download URL or a URI path to access your results.

  The v1 batch and batch-inputs endpoints are now **deprecated**, they remain available for backward compatibility and will be sunset soon.

  **Migration guide**: [Migrating to Batch v2](/changelog/batch-v2). See also [Batch Inference](/data-operations/batch-inference).
</Update>

<Update label="March 2026">
  ### Webhooks

  Real-time HTTPS callbacks are now available across the platform. Configure endpoints from **Platform → Alerts → Webhooks** with per-endpoint event subscriptions, HMAC signing, and a built-in delivery history with replay.

  Event catalog spans batches (`batch-request`, `batch-lifecycle`, `batch-result-download`, …), model versions (`model-version-promotion`, `model-version-activation`, …), workspace, and API keys. See [Webhooks](/data-operations/webhook-notifications).

  ### Workspace Notifications

  The same event catalog now powers human-facing notifications. Subscribe to any event for delivery via email and in-app channels from **Settings → Workspace → Notifications**. See [Notifications](/dashboard/notifications).

  ### Audit Logs

  Expanded audit coverage for organization access control and user lifecycle events. The dashboard now tracks the full lifecycle of invitations, membership changes, authentication activity, and organization-level updates.

  **Invitations**

  * Invite created, accepted, and revoked events
  * Full traceability from invite sent to user onboarded

  **Membership**

  * Member added, role updated, and member removed
  * Organization membership creation, updates, and deletion

  **Organization & Sessions**

  * Organization configuration changes
  * User creation, updates, and deletion
  * Login and session creation events

  All events are visible in the dashboard under **Observability → Audit**, giving your compliance and security teams a complete view of who did what and when.
</Update>

<Update label="February 2026">
  ### Data Contract Enforcement

  Data contracts are now enforced in production, structured in two layers: ingestion and transformation.

  The ingestion layer validates every file against the agreed schema. Any deviation triggers an automatic notification. When discrepancies occur, they are classified either as a new contract version or as a data error — ensuring clear ownership and faster resolution between your team and ours.

  ### Prediction Audit Events

  Audit visibility is now available in the dashboard for prediction consumption:

  * Prediction consumption via API
  * Prediction consumption via Dashboard
  * Batch prediction start (API and Dashboard)
  * Batch prediction completion (API and Dashboard)

  These events allow you to monitor usage and execution lifecycle directly from the UI. Navigate to **Observability → Audit** to review activity. Additional audit events will be progressively added in future releases.

  ### Graph Foundation Model v2.6

  The Graph Foundation Model has been updated to version 2.6.

  The underlying graph now incorporates additional data sources and new types of relationships, resulting in a more connected graph. No new data fields were introduced, but the model now more effectively leverages information that was already available — improving overall consistency and unlocking new relational signals across entities.
</Update>

<Update label="November 2025">
  ### Dashboard

  New Avra dashboard available for all organizations.

  * Unified navigation for models and batches
  * Role-based visibility for billing, audit logs, and API credentials
  * Multiple workspaces support
  * Streamlined invite flow with enforced SSO where configured

  Rollout is complete; existing users will see the new experience on next sign-in.
</Update>

<Update label="October 2025">
  ### API

  Improved `GET /v1/api/models/{model_id}/versions/{version_id}` to return the model's full input/output schema with metadata about each field. This enables dynamic form generation, automated validation, and programmatic discovery of model capabilities in your integration code.
</Update>

<Update label="September 2025">
  ### Platform Migration

  We have evolved our platform to a new generation, designed for greater reliability, lower latency, and a more scalable and extensible architecture. This transition unlocks a broader range of data integration possibilities and enables us to deliver tailor-made AI models that adapt to each customer's unique context.

  The following legacy endpoints have been sunset:

  * `POST /v1/api/risk_score`
  * `POST /v1/api/entities/context/contact`
  * `POST /v1/api/entities/context/transaction`
  * `POST /v1/api/entities/context/invoices`

  <Warning>
    These endpoints now return `410 Gone`. All new integrations should use the model registry prediction endpoints.
  </Warning>

  **Migration guides**: [Prediction Platform](/changelog/prediction-platform) | [Data Integration](/changelog/data-integration)

  ### Documentation

  Documentation serving platform migrated to Mintlify for improved user experience.

  * Restructured guides with business-first approach while preserving technical depth
  * Enhanced integration documentation with clearer customer journey paths
</Update>


# Audit Logs
Source: https://docs.avra.ai/dashboard/audit-logs

Tamper-evident record of sensitive actions across the dashboard and API.

Avra maintains audit logs of workspace activity to support security monitoring, incident response, and compliance.

## What is recorded

The platform captures events across the same catalog used by [Webhooks](/data-operations/webhook-notifications) and [Notifications](/dashboard/notifications):

### Identity and access

* User logins, SSO authentication, session creation
* Invitation creation, acceptance, and revocation
* Member additions, role updates, and removals
* Organization configuration changes

### Workspace and access control

* Workspace creation, update, archival, unarchival
* API key creation, rotation, renaming, and deletion

### Data and model operations

* Batch input uploads and deletions
* Batch requests, lifecycle transitions, interruptions, result downloads and deletions
* Model version activation, deactivation, promotion, and demotion
* Real-time prediction consumption via API and dashboard

Each event captures the actor, the target resource, the workspace, and an immutable timestamp.

## Accessing the audit trail

Navigate to **Observability → Audit** in the dashboard. Users with the **Creator** or **Auditor** role can review events.

For programmatic export or custom retention requirements, contact your account representative.

## Use this for

* **Security monitoring** — detect unusual access patterns, failed authentications, or unexpected model promotions
* **Incident response** — reconstruct what happened, by whom, and when
* **Regulatory compliance** — produce evidence for SOC 2, ISO 27001, LGPD, GDPR, and internal audit
* **Change management** — review who promoted which model version, who rotated which API key


# Authentication & Sessions
Source: https://docs.avra.ai/dashboard/authentication

Learn how Avra secures access and how to enable SSO for your organization.

Avra provides enterprise-grade authentication and session management for secure access to your workspace.

## Default authentication flow

1. Users sign in with their corporate email or configured SSO provider.
2. Secure session tokens are issued for dashboard and API key management access.
3. Sessions automatically expire; reauthentication is required after inactivity or explicit logout.

## Single Sign-On (SSO)

* **Supported protocols**: SAML 2.0 and OIDC.
* **How to enable**: Contact your Avra Sales Representative or Forward Deployed Engineer (FDE) with your IdP metadata. We'll provision an SSO connection and coordinate testing before enabling for production.
* **Requirements**: At least one break-glass admin using email/password + MFA in case the IdP is unavailable.

## API access

API keys are scoped to workspaces and can be rotated without impacting dashboard sessions. Each key is mapped to the user who created it for auditability.

## Session security

* We allow users to setup multi-factor authentication (MFA) for enhanced security.
* Risk-based controls automatically sign out sessions from unrecognized devices.
* You can revoke active sessions in the dashboard under **Access & Security → Active Sessions**.


# Notifications
Source: https://docs.avra.ai/dashboard/notifications

Email and in-app alerts for the events that matter to your team — driven by the same event catalog as webhooks.

Notifications keep your team informed about operational events without forcing them to live in the dashboard.

## How it works

Notifications use the **same event catalog as [Webhooks](/data-operations/webhook-notifications)** — every batch, model-version, workspace, and API-key event in the catalog can be delivered as a notification. Where webhooks target your systems, notifications target your people.

## Delivery channels

Each event can be delivered through:

* **Email** — sent to the addresses of subscribed users
* **In-app** — surfaced in the notification panel inside the dashboard

Channels are independent — you can enable email-only, in-app-only, or both per event subscription.

## Configuring notifications

Notification preferences are configured per workspace from **Settings → Workspace → Notifications**. Each user can additionally manage their own subscription preferences and channel choices.

The events you can subscribe to mirror the [webhook event catalog](/data-operations/webhook-notifications#event-catalog) — batches, model versions, workspace, and API keys.

## Webhooks vs notifications

The two are complementary surfaces over the same underlying event stream:

|                   | Notifications                      | Webhooks                          |
| ----------------- | ---------------------------------- | --------------------------------- |
| **Audience**      | Humans on your team                | Your systems                      |
| **Channels**      | Email, in-app                      | HTTPS callback                    |
| **Configuration** | Workspace + per-user preferences   | Per endpoint, with signing secret |
| **Use for**       | Awareness, alerting on-call humans | Automation, pipeline triggers     |

Use notifications to keep your team informed. Use webhooks to drive automated pipelines. Both off the same canonical event catalog.


# Dashboard Overview
Source: https://docs.avra.ai/dashboard/overview

Navigate the Avra dashboard to manage access, monitor usage, and orchestrate data operations.

The dashboard is your control center for everything outside direct API integrations.

## Organizations and Workspaces

An **organization** is your top-level account — it owns billing, team members, and security settings (SSO, audit logs). Within an organization, you can have one or more **workspaces**. Each workspace is an isolated environment with its own API keys, Relational Foundation Model, downstream models, and data pipelines. This lets you separate production from staging, or run independent models for different business units, all under one organization.

## Key areas

<CardGroup>
  <Card title="Developers">
    Create and rotate API keys, configure IP allowlists, and review webhook
    endpoints.
  </Card>

  <Card title="Data Operations">
    Monitor ingestion health, inspect batch jobs, and download result files.
  </Card>

  <Card title="Access & Security">
    Invite teammates, manage roles, and request SSO activation.
  </Card>

  <Card title="Billing">
    View active MAU counts, download invoices, and manage payment contacts.
  </Card>
</CardGroup>


# Roles & Permissions
Source: https://docs.avra.ai/dashboard/roles-permissions

Understand workspace-level access control and role-based permissions.

Avra uses role-based access control (RBAC) scoped to your organization. Each user is assigned a role that determines their permissions across the dashboard and API.

## Available Roles

| Role                | Description                                                                                 |
| ------------------- | ------------------------------------------------------------------------------------------- |
| **Creator**         | Full administrative access including workspace management, billing, and team administration |
| **Developer**       | Technical access for API integration, model invocation, and batch operations                |
| **Analyst**         | Read-only access to models and batch results for reporting and analysis                     |
| **Billing Manager** | Access to usage metrics and invoices                                                        |
| **Auditor**         | Read-only access to audit logs and usage activity                                           |
| **Member**          | Basic read access to workspace resources                                                    |

## Permission Matrix

| Capability              | Creator | Developer | Analyst | Billing | Auditor | Member |
| ----------------------- | :-----: | :-------: | :-----: | :-----: | :-----: | :----: |
| **Workspace**           |         |           |         |         |         |        |
| Create/Update workspace |    ✓    |           |         |         |         |        |
| Archive workspace       |    ✓    |           |         |         |         |        |
| **Models**              |         |           |         |         |         |        |
| View models             |    ✓    |     ✓     |    ✓    |         |    ✓    |    ✓   |
| View model versions     |    ✓    |     ✓     |    ✓    |         |    ✓    |    ✓   |
| Manage aliases          |    ✓    |     ✓     |         |         |         |        |
| Invoke predictions      |    ✓    |     ✓     |         |         |         |        |
| **Batches**             |         |           |         |         |         |        |
| View batches            |    ✓    |     ✓     |    ✓    |         |         |    ✓   |
| Create batches          |    ✓    |     ✓     |         |         |         |        |
| Cancel batches          |    ✓    |     ✓     |         |         |         |        |
| Download results        |    ✓    |           |         |         |         |        |
| Delete results          |    ✓    |           |         |         |         |        |
| **Files**               |         |           |         |         |         |        |
| View files              |    ✓    |           |         |         |         |    ✓   |
| Upload files            |    ✓    |           |         |         |         |        |
| Download files          |    ✓    |           |         |         |         |        |
| Delete files            |    ✓    |           |         |         |         |        |
| **API & Webhooks**      |         |           |         |         |         |        |
| Manage API keys         |    ✓    |     ✓     |         |         |         |        |
| Manage webhooks         |    ✓    |     ✓     |         |         |         |        |
| **Billing & Usage**     |         |           |         |         |         |        |
| View usage              |    ✓    |     ✓     |         |    ✓    |         |        |
| View invoices           |    ✓    |           |         |    ✓    |         |        |
| **Audit**               |         |           |         |         |         |        |
| View usage logs         |    ✓    |           |         |         |    ✓    |        |
| View activity logs      |    ✓    |           |         |         |    ✓    |        |
| **Team**                |         |           |         |         |         |        |
| Manage members          |    ✓    |           |         |         |         |        |
| View members            |    ✓    |     ✓     |    ✓    |    ✓    |    ✓    |    ✓   |

## Key Behaviors

* **Access inheritance**: Removing a user immediately revokes their dashboard sessions and API keys
* **Least privilege**: Assign the minimum role needed for each team member's responsibilities
* **Single Sign-On**: Enterprise workspaces can enforce SSO with at least one break-glass admin using email/password + MFA

## Role Assignment

To change a user's role:

1. Navigate to **Access & Security → Members**
2. Click the member's current role
3. Select the new role from the dropdown
4. Changes take effect immediately

<Note>
  Every workspace requires at least one Creator. The last Creator cannot be downgraded or removed.
</Note>


# Team Management
Source: https://docs.avra.ai/dashboard/team-management

Invite teammates, manage seats, and keep your workspace secure.

## Inviting teammates

1. Go to **Access & Security → Members**.
2. Click **Invite teammate** and enter their corporate email.
3. Assign a role — Creator, Developer, Analyst, Billing Manager, Auditor, or Member (see [Roles & Permissions](/dashboard/roles-permissions)) — and send the invite.

Invitations expire after 7 days. Resend from the same panel if needed.

## Managing membership

* Use the member list to revoke access or downgrade roles.
* Removing a member automatically revokes their dashboard sessions and API keys.
* For audit purposes, download the membership history as CSV.

## Recommended practices

* Adopt least privilege: keep only the required number of Creators.
* Require MFA before granting access to production workspaces.


# Batch Inference
Source: https://docs.avra.ai/data-operations/batch-inference

Process portfolios, refresh segments, or generate large embedding sets asynchronously.

Batch inference complements the low-latency API when you need to score or enrich large portfolios.

## When to choose batch

| Use case                    | Recommended path                   |
| --------------------------- | ---------------------------------- |
| Nightly portfolio rescoring | Batch                              |
| Real-time onboarding        | REST API                           |
| Marketing list enrichment   | Batch                              |
| High-touch underwriting     | REST API with on-demand enrichment |

## Workflow

<Steps>
  <Step title="Upload data">
    Request signed upload URLs with `POST /v2/api/files/upload`, declaring each file's path, content type, and base64-encoded MD5 digest.
    Upload each file with a `PUT` to its `upload_url`, sending matching `Content-Type` and `Content-MD5` headers.
  </Step>

  <Step title="Submit job">
    Request a batch prediction with `POST /v2/api/batches`, referencing the uploaded files, an available model, and an optional `reference_date`.
    Avra responds with a batch `id` so you can track the job.
  </Step>

  <Step title="Processing">
    Jobs run in prioritized queues with resource usage quotas. Expect minutes for thousands of records and hours for millions.
  </Step>

  <Step title="Waiting">
    Poll `GET /v2/api/batches/{id}` checking job status or subscribe to the `batch-lifecycle` webhook to be notified on status transitions.
  </Step>

  <Step title="Download results">
    Request a download link at `GET /v2/api/batches/{id}/result` to obtain a signed short-lived `download_url`.
  </Step>
</Steps>

<Callout type="info" title="API details">
  Refer to the [API Reference](/api-reference/overview) for endpoint schemas,
  payload examples, and error handling best practices when submitting batches.

  Migrating from the v1 batch-inputs flow? See [Migrating to Batch v2](/changelog/batch-v2).

  Workflow steps may vary when using [SFTP Batch Inference](/data-operations/sftp-batch-inference). Please refer to the documentation for more details.
</Callout>

<Warning>
  The v1 batch endpoints (`/v1/api/batch-inputs/*`, `/v1/api/batches/*`) are **deprecated** and maintained only for backward compatibility. They will be sunset soon. Build new integrations on the v2 endpoints above.
</Warning>

## Limits and Best Practices

* **No hard limits.** The Files API does not impose size or row-count limits, but following good practices keeps job queues no longer than needed and jobs reliable.
* **Split large inputs across many files.** A batch accepts many files at once, prefer uploading and referencing several medium files over one huge one.
* **Prefer Parquet over CSV.** Parquet datasets have strong typing and compression, providing faster uploads and batch jobs while preserving data quality and precision.
* **Size Parquet datasets sensibly.** A Parquet dataset can be split into `row_groups` (the minimal decompressed block in a read operation) and `partitions` (the segmentation of the dataset across multiple files). Aim for at most 100k rows per `row_group` and 5 GB per `partition`.
* **Very large jobs.** These may require fine-tuning to avoid failures, reach out so we can size the run properly.

## Integrations

* Use [SFTP Batch Inference](/data-operations/sftp-batch-inference) for scheduled large files.
* Configure webhooks triggered by many batch-related events. See [Webhooks](/data-operations/webhook-notifications).

## Monitoring

Track batch throughput and failures in the dashboard under **Batches**.


# Customer Context Data Contracts
Source: https://docs.avra.ai/data-operations/ingesting-context

Structure relational datasets and temporal features so Avra can train your Relational Foundation Model and downstream models safely.

Your proprietary business data is what trains your Relational Foundation Model. Because Avra is a relational AI platform built on top of a Large Knowledge Graph, we natively ingest multi-table datasets — customer masters, invoices, payments, collections, support tickets, and beyond — and align them to the graph through shared keys.

We accept both relational and tabular structures in the same handoff. Send the tables you already manage, link them with consistent identifiers (legal documents or your own surrogate keys), and we will reconcile them into a consolidated relational view before training.

## Data Types We Support

### Relational Data

Complex, interconnected datasets that capture business relationships:

* **Customer Networks**: Account hierarchies, subsidiary relationships, partnership structures
* **Transaction Chains**: Multi-party transactions, payment flows, supplier relationships
* **Event Sequences**: Customer journey data, interaction timelines, lifecycle events

### Tabular Data

Structured datasets from your operational systems:

* **Customer Records**: Demographics, firmographics, account details
* **Transaction History**: Payments, purchases, service usage, billing events
* **Outcome Data**: Defaults, renewals, upgrades, churn events

## Critical Success Factors

### Data Quality Requirements

The quality of your Relational Foundation Model and every downstream model trained from it depends directly on the quality of your historical data:

**Good Data Definitions**: Clear, consistent definitions of outcomes, customer states, and business events across your historical dataset.

**Event Time Columns**: Every table should expose event timestamps (for example, `created_at`, `updated_at`, `effective_at`, or `occurred_at`) so we can reconstruct the state of the world at any point in time. These fields are critical for leakage-safe training runs and for replaying historical decisions.

**Accurate As-Of Dates**: Complement event timestamps with clear "as-of" semantics indicating when the information became available for decision-making.

**Sufficient History**: Adequate volume of historical outcomes to enable robust model training and validation.

### Preventing Data Leakage

Data leakage occurs when future information accidentally influences past predictions. Our data ingestion process includes:

* **Temporal Validation**: Ensuring all features were available at the time of decision
* **As-Of Date Enforcement**: Strict temporal boundaries for training data
* **Outcome Window Definitions**: Clear separation between prediction time and outcome measurement

## Implementation Process

Implementation details are tailored to each customer's specific data architecture, regulatory requirements, and technical constraints.

**Next Steps**: Contact your account representative to begin the data discovery process and design a custom ingestion strategy that ensures high-quality data flows while maintaining compliance with your internal governance requirements.


# Model Versioning
Source: https://docs.avra.ai/data-operations/model-lifecycle

How Avra manages the Graph Foundation Model, your Relational Foundation Model, and the downstream models served from both — with versioning, aliases, and rollback you control.

Avra operates a three-layer model architecture. Each layer has its own versioning surface, and each layer's evolution is independent of the others.

## Model layers

### Graph Foundation Model (GFM)

The pre-trained base layer that understands the relational economy — entities, relationships, behaviors, and temporal dynamics. The GFM is operated and improved by Avra. New GFM versions are released periodically and become available to all customers; you choose when to consume them.

### Relational Foundation Model (RFM)

A customer-specific relational representation layer, pre-trained on your schema and temporal business data, then composed with the GFM for downstream models. The RFM is exclusive to your workspace, optionally deployed inside your environment, and evolves as new data lands and as you train downstream models on top of it.

### Downstream Models

Task-specific models — credit, fraud, growth, custom — trained on top of the GFM and your RFM. Each downstream model has its own version history and lifecycle, independent of the foundations beneath it.

## Versioning

### Multiple live versions

Avra supports multiple live versions of each model simultaneously. This allows you to:

* Test new foundation versions without disrupting production
* Run challenger experiments alongside production traffic
* Serve specialized variants for different segments or workflows
* Roll back instantly when something regresses

### Version identification

Each model is identified by **`model_id`**. Each version has a unique, immutable **`version_id`**, and can carry a human-readable **alias** for easier reference.

Common aliases:

* **`production`** — the version currently serving production traffic
* **`challenger`** — a new version being evaluated for promotion
* **`baseline`** — the previous version, kept for comparison

An alias can point to only one version of a given model at a time. The same alias name (e.g. `production`) can be used independently across different models.

## You control upgrades and rollbacks

You decide which versions serve your production traffic — not us.

**Alias management.** Repoint an alias to a different version to upgrade or roll back. API calls referencing the alias pick up the change without any code edit on your side.

```
POST /v1/api/prediction/{model_id}/production
```

**Direct version reference.** Pin to an exact `version_id` when you want guaranteed determinism — useful for backtests, audit replays, or staged rollouts.

```
POST /v1/api/prediction/{model_id}/{version_id}
{
  "legal_document": "12345678000199"
}
```

**Rollback.** Reassign the alias back to the previous stable version. Changes take effect within minutes across all production traffic. No deployment, no incident bridge.

## Promotion process

New downstream model versions are validated before they are made available for promotion:

* **Offline evaluation** against holdout datasets and your historical outcomes
* **Shadow traffic** comparison against the current production version
* **Distributional checks** to surface population-level drift before it reaches customers
* **Statistical consistency** guarantees so score distributions remain interpretable across versions

You receive notification when a new version is available. You choose when — and whether — to upgrade.


# SFTP Batch Inference
Source: https://docs.avra.ai/data-operations/sftp-batch-inference

Run large-scale inference by dropping PARQUET / CSV files in a secure SFTP bucket.

<Warning>This feature is currently limited. Contact us to enable.</Warning>

Use SFTP as a managed transport layer for the same Batch Inference jobs covered in this section. Drop files into the inbound folder, Avra submits them to the Batch API on your behalf, and results land back in the outbound folder with full observability via webhooks and dashboard events.

## Prerequisites

* Batch prediction target configured in production (`{model_id}/production`, `{model_id}/challenger`, or `{model_id}/{version_id}`)
* At least one SFTP user provisioned by Avra Ops
* IP allowlist entries (if required by your network policies)
* Optional: <a href="/data-operations/webhook-notifications">webhook</a> subscription for `batch-lifecycle`

## Directory Layout

```text theme={null}
batch/
  in/
    batch_2025-05-01.parquet
    batch_2025-06-01.csv
  out/
    batch_2025-05-01.parquet
    batch_2025-06-01.parquet
logs/
samples/
```

## File Format

Parquet or CSV up to 10 GB and 1,000,000 rows per file. Required columns:

* `endpoint`: the model prediction target, using the same `model_id` + alias or version convention as the Prediction API (e.g. `{model_id}/production`, `{model_id}/challenger`, `{model_id}/{version_id}`)
* All inputs declared in the model's schema (e.g. `legal_document`, `avra__internal__customer_embedding`)
* Optional metadata columns (`correlation_id`, `reference_id`) are echoed back in the output.

## Processing Flow

```mermaid theme={null}
sequenceDiagram
  participant You
  participant SFTP
  participant Avra
  You->>SFTP: Upload your-file.csv to /in
  SFTP-->>Avra: Object-Created event
  Avra->>Avra: Validate & submit to Batch API
  Avra-->>SFTP: Write your-file.out.csv to /out
  Avra-->>You: (Optional) POST batch-lifecycle webhook
```

See <a href="/data-operations/batch-inference">Batch Inference</a> for service-level expectations, retries, and status polling flow. Pair with <a href="/data-operations/webhook-notifications">webhook notifications</a> to receive completion callbacks without polling SFTP.


# Webhooks
Source: https://docs.avra.ai/data-operations/webhook-notifications

Real-time HTTPS callbacks for batch, model, workspace, and API-key events — configured per workspace.

Webhooks deliver real-time event notifications to your endpoints over HTTPS, eliminating the need to poll the API for job status or operational changes.

## Configure endpoints

Webhook endpoints are managed in the dashboard under **Platform → Alerts → Webhooks**.

For each endpoint you can:

* Set the **destination URL** that will receive deliveries
* **Subscribe** to specific events (you do not need to handle every event)
* Use the **signing secret** to verify deliveries with HMAC SHA-256
* View the **delivery history** to inspect payloads, response codes, and retry status

You can register multiple endpoints per workspace — useful for routing operational events to one consumer and audit events to another.

## Event catalog

All events are grouped by resource. The catalog is also available programmatically — events are added over time without breaking existing subscriptions.

### Batches

| Event                        | Description                                                                                |
| ---------------------------- | ------------------------------------------------------------------------------------------ |
| `batch-input-upload-request` | A batch input file upload was requested                                                    |
| `batch-input-deletion`       | A batch input was deleted                                                                  |
| `batch-request`              | A batch inference run was requested                                                        |
| `batch-interrupt-request`    | A batch inference interruption was requested                                               |
| `batch-lifecycle`            | A lifecycle transition occurred for a batch inference (queued, running, succeeded, failed) |
| `batch-result-download`      | A batch result was downloaded                                                              |
| `batch-result-deletion`      | A batch result was deleted                                                                 |

To act on batch completion, subscribe to `batch-lifecycle` and read the status field from the payload.

### Model versions

| Event                        | Description                                                         |
| ---------------------------- | ------------------------------------------------------------------- |
| `model-version-activation`   | A model version was activated                                       |
| `model-version-deactivation` | A model version was deactivated                                     |
| `model-version-promotion`    | A model version was promoted (e.g. assigned the `production` alias) |
| `model-version-demotion`     | A model version was demoted                                         |

### Workspace

| Event                  | Description                         |
| ---------------------- | ----------------------------------- |
| `workspace-creation`   | A workspace was created             |
| `workspace-update`     | A workspace's settings were updated |
| `workspace-archival`   | A workspace was archived            |
| `workspace-unarchival` | A workspace was unarchived          |

### API keys

| Event               | Description            |
| ------------------- | ---------------------- |
| `api-key-creation`  | An API key was created |
| `api-key-deletion`  | An API key was deleted |
| `api-key-recycling` | An API key was rotated |
| `api-key-renaming`  | An API key was renamed |

## Verifying deliveries

Every delivery is signed with HMAC SHA-256 using the endpoint's signing secret. The dashboard surfaces the secret on the endpoint detail view and lets you rotate it at any time.

To verify a delivery on your side:

1. Read the signature headers from the incoming request.
2. Recompute the HMAC SHA-256 of the payload using your endpoint's signing secret.
3. Compare against the value in the signature header using **constant-time** comparison.
4. Reject deliveries whose timestamp is outside your tolerance window (5 minutes is a sensible default).

The exact header names are documented on the endpoint detail view in the dashboard, along with a copy-pasteable verification snippet.

## Retry and delivery semantics

Avra delivers webhooks with **at-least-once** semantics. Your endpoint should treat deliveries as idempotent and dedupe on the delivery ID surfaced in the request headers.

Failed deliveries (non-2xx response or timeout) are automatically retried with exponential backoff. If all retries are exhausted, the delivery is marked failed in the dashboard and can be inspected or manually replayed from the delivery history.

## Observability

The dashboard exposes a delivery log per endpoint with response codes, payloads, and failure reasons. Useful for debugging integration issues without instrumenting your own consumer. Individual deliveries can be replayed manually.

## Best practices

* **Respond within 5 seconds.** Acknowledge the delivery immediately and process the payload asynchronously on your side.
* **Dedupe on the delivery ID.** Avra may retry deliveries; idempotent consumers prevent double-processing.
* **Use separate endpoints per environment.** Different secrets, different delivery logs, no cross-contamination.
* **Subscribe narrowly.** Register endpoints only for the events you actually consume.


# Welcome to Avra
Source: https://docs.avra.ai/getting-started/overview

Pre-trained foundation models for relational intelligence — composed into every decision your business makes.

## The Decision Intelligence Platform

Every enterprise decision — approve this loan, flag this transaction, prioritize this lead — is a question about an entity in a network. The economy is not tabular. Companies are not rows in a table; they are nodes in a graph, and that graph is the signal.

Avra is a frontier AI lab. We pre-train foundation models on relational data — the economy as a whole, and your business specifically — and compose them into the decisions your existing systems already make.

## The three layers

<CardGroup>
  <Card title="Graph Foundation Model" icon="globe">
    Pre-trained on 1B+ entities and the relationships between them. Today specialized for Brazil, expanding to other regions. The world your business operates in.
  </Card>

  <Card title="Relational Foundation Model" icon="circle-nodes">
    A customer-specific relational representation layer, pre-trained on your schema and temporal business data, then composed with the GFM for downstream models.
  </Card>

  <Card title="Downstream Models" icon="diagram-project">
    Task-specific models — credit, fraud, growth, custom — built on both foundations. Every model you train improves the RFM that produced it.
  </Card>
</CardGroup>

<Info>
  **The flywheel**: every downstream model you train generates signal that flows back into your RFM. The next model starts from a stronger base. The longer you run on Avra, the larger the gap between what you can predict and what anyone else can.
</Info>

## Across the customer lifecycle

The same foundations power intelligence at every stage:

<AccordionGroup>
  <Accordion title="Acquire" icon="user-plus">
    * **Lead Scoring** — identify high-value prospects before they convert
    * **Paid Media Optimization** — enrich pixel data with entity-level signal
    * **Field Sales Ranking** — order opportunities for maximum efficiency
  </Accordion>

  <Accordion title="Onboard" icon="clipboard-check">
    * **Fraud Prevention** — network-based detection before losses occur
    * **Risk Assessment** — understand who you are doing business with
    * **Entity Verification** — resolve and verify entities at scale
  </Accordion>

  <Accordion title="Manage" icon="chart-line">
    * **Credit Decisions** — dynamic risk assessment with trajectory analysis
    * **Portfolio Monitoring** — early-warning signals across your book
    * **Relationship Intelligence** — understand the networks your customers operate in
  </Accordion>

  <Accordion title="Retain" icon="arrows-spin">
    * **Churn Prediction** — identify at-risk relationships early
    * **Lifetime Value** — understand long-term potential
    * **Custom Tasks** — any prediction target you can label on entities in the graph
  </Accordion>
</AccordionGroup>

## How it works

<Steps>
  <Step title="Pre-trained foundations">
    The GFM is already trained on the relational economy. The RFM is pre-trained on your relational schema and temporal business data — either by us or inside your environment.
  </Step>

  <Step title="Downstream training">
    Task-specific models — credit, fraud, growth, custom — are trained on top of both foundations. Signal from each training run feeds back into your RFM.
  </Step>

  <Step title="Decisions, in production">
    Query real-time APIs or run batch jobs. Predictions, scores, and embeddings — versioned, governed, and integrated into your existing decision systems.
  </Step>
</Steps>

## Why this is different

| Traditional approach       | Avra                                                      |
| -------------------------- | --------------------------------------------------------- |
| More data = better results | Better representations = better results                   |
| Manual feature engineering | Foundations learn representations automatically           |
| Isolated entity analysis   | Network-aware intelligence                                |
| Static snapshots           | Temporal trajectories                                     |
| One model per use case     | Two pre-trained foundations, many downstream models       |
| Frozen at delivery         | Flywheel — every downstream model improves the foundation |

## Explore

<CardGroup>
  <Card title="Why Avra" href="/why-avra/the-challenge" icon="lightbulb">
    The problem we solve and why our approach works
  </Card>

  <Card title="Platform Architecture" href="/platform/architecture" icon="diagram-project">
    The three layers, the flywheel, and how they compose
  </Card>

  <Card title="API Reference" href="/api-reference/overview" icon="code">
    Endpoints, authentication, and integration patterns
  </Card>

  <Card title="Use Cases" href="/solutions/overview" icon="rocket">
    Credit, fraud, growth, and any task you can label
  </Card>
</CardGroup>


# Quickstart
Source: https://docs.avra.ai/getting-started/quickstart

From first conversation to predictions in production.

## Onboarding journey

<Steps>
  <Step title="Scope the engagement">
    Contact your Avra representative at **[sales@avra.ai](mailto:sales@avra.ai)**. We start by understanding the decisions you want to improve, the data you have, and the integration shape — API, batch, or embeddings — that fits your operation.
  </Step>

  <Step title="Provision your workspace">
    Avra provisions a tenant-isolated workspace. You receive credentials for [app.avra.ai](https://app.avra.ai) and access to your **Data Contract** — the agreed schema for the relational data you will send.
  </Step>

  <Step title="Send your data">
    Stream or upload your relational data through API, connectors, or SFTP. Every event is validated against your data contract; deviations trigger a notification, not a silent failure.
  </Step>

  <Step title="Train your Relational Foundation Model">
    Avra pre-trains your RFM on your relational schema and temporal business data. For managed deployments, this runs in your tenant-isolated environment. For on-premise deployments, this runs inside your perimeter.
  </Step>

  <Step title="Train downstream models">
    Task-specific models — credit, fraud, growth, custom — are trained on top of your RFM and the Graph Foundation Model. Each training run feeds signal back into your RFM, making the next iteration sharper.
  </Step>

  <Step title="Promote to production">
    Validate offline against your holdouts. Mirror against production traffic. Promote when you meet your performance bar. Roll back with one alias reassignment if anything regresses.
  </Step>
</Steps>

## Once you are live

<CardGroup>
  <Card title="Dashboard" href="/dashboard/overview" icon="gauge">
    Monitor usage, manage models and versions, and govern access
  </Card>

  <Card title="API Reference" href="/api-reference/overview" icon="code">
    Real-time predictions, model discovery, and version control
  </Card>

  <Card title="Batch Inference" href="/data-operations/batch-inference" icon="layer-group">
    Score entire portfolios on a schedule
  </Card>

  <Card title="Embeddings" href="/solutions/embeddings/overview" icon="cube">
    Use Avra representations as features in your own ML models
  </Card>
</CardGroup>

## Where to go from here

<AccordionGroup>
  <Accordion title="I want to understand the platform first">
    Read [Why Avra](/why-avra/the-challenge), then the [Platform Architecture](/platform/architecture) — the three layers, the flywheel, and how they compose.
  </Accordion>

  <Accordion title="I want to see specific use cases">
    [Credit Intelligence](/solutions/credit-score/overview-and-methodology), [Fraud Detection](/solutions/fraud/overview), [Growth & Sales](/solutions/growth/lead-scoring), or [build your own model](/solutions/embeddings/overview) with embeddings.
  </Accordion>

  <Accordion title="I'm ready to integrate">
    Start with the [API Reference](/api-reference/overview) for authentication, endpoints, and integration patterns.
  </Accordion>
</AccordionGroup>


# Platform Architecture
Source: https://docs.avra.ai/platform/architecture

A three-layer foundation for relational intelligence — pre-trained on the economy, adapted to your relational data, deployed inside your decisions.

Avra is built on a simple thesis: the economy is not tabular. Companies are not rows in a table — they are nodes in a network, and that network is the signal.

We operationalize that thesis with three composable foundation layers. Each one is pre-trained. Each one carries forward to the next.

<Steps>
  <Step title="Graph Foundation Model (GFM)">
    A foundation model pre-trained on the relational economy. It learns how entities behave, connect, and evolve before it ever sees your data. Today it is specialized for Brazil; the same architecture extends to other regions as we expand.
  </Step>

  <Step title="Relational Foundation Model (RFM)">
    A customer-specific relational representation layer, pre-trained on your schema and temporal business data, then composed with the GFM for downstream models. Available as a managed service or deployed inside your environment.
  </Step>

  <Step title="Downstream Models">
    Task-specific models — credit, fraud, growth, custom prediction targets — trained on top of the GFM and RFM. They inherit network intelligence from both. Every downstream model trained also improves the RFM that produced it.
  </Step>
</Steps>

## The shape of it

```mermaid theme={null}
flowchart LR
    subgraph Avra["Avra · pre-trained on the economy"]
        LKG[("Large Knowledge Graph")]
        GFM["Graph Foundation Model"]
        LKG --> GFM
    end

    subgraph You["Your workspace · adapted to your business"]
        DATA[("Your relational data")]
        RFM["Relational Foundation Model"]
        DM["Downstream Models<br/>credit · fraud · growth · custom"]
        DATA --> RFM
        GFM -.-> RFM
        GFM -.-> DM
        RFM --> DM
        DM -. signal feeds back .-> RFM
    end

    DM ==> API[["Decisions<br/>API · Batch · Embeddings"]]

    classDef avra fill:#0A01FE,stroke:#0A01FE,color:#fff;
    classDef you fill:#F2EDE6,stroke:#0A01FE,color:#000;
    classDef out fill:#ffffff,stroke:#0A01FE,color:#0A01FE;
    class GFM avra
    class RFM,DM you
    class API out
```

## The flywheel

The three layers are not stacked once and frozen. They compound.

Each downstream model you train surfaces new signal — what predicted churn, what predicted default, what predicted conversion. That signal is fed back into the RFM, refining its representation of your business. The next downstream model starts from a stronger base. The next one after that, stronger still.

The RFM learns from outcomes the GFM never saw. The GFM keeps the RFM grounded in the broader economy. Downstream models inherit both — and contribute back.

<Info>
  **One foundation, trained once. A second foundation, trained on you. Every model after that, stronger than the last.**
</Info>

## Why three layers, not two

A single foundation model — yours or ours — is a compromise.

A general foundation alone misses your business. Your customer hierarchies, your transaction patterns, your definitions of success are invisible to a model trained on public data. You either ship a generic score or backfill that gap with brittle feature engineering on top.

A customer-specific foundation alone misses the world. A model trained only on your data has no view of counterparties, supply chains, judicial events, or sector dynamics that determine outcomes. It can describe your portfolio but not the context around it.

Avra trains both. The GFM brings the economy. The RFM brings your business. Downstream models compose them into decisions.

## Deployment

Different layers live in different places, by design.

<CardGroup>
  <Card title="Managed cloud" icon="cloud">
    The full stack hosted by Avra: GFM, RFM, downstream models, inference APIs, dashboards. The default path — fastest time to production, no infrastructure to operate.
  </Card>

  <Card title="On-premise RFM" icon="building-shield">
    Run your Relational Foundation Model inside your own environment. Sensitive data never crosses your perimeter. The GFM continues to provide the broader economic context as a managed service.
  </Card>
</CardGroup>

## Composability

Each layer is useful on its own.

* **GFM embeddings** plug into your existing ML pipelines as features — no fine-tuning required.
* **RFM** can power your internal models even without our downstream tasks.
* **Downstream models** can be queried as APIs, run as batches, or accessed through dashboards.

The three layers are designed so you can adopt one, two, or all of them — and so the value compounds when you adopt more.

## What you operate

You retain control over the parts that affect your decisions:

* **Model versions and aliases** — promote, roll back, run challenger experiments
* **Data contracts** — declare what you send and how it maps to entities
* **Access and isolation** — workspace-scoped API keys, role-based access, audit
* **Outcomes** — your labels, your definition of success, your retraining cadence

Avra operates the foundation. You operate the decisions.


# Graph Foundation Model
Source: https://docs.avra.ai/platform/foundational-model

A pre-trained model that understands entities and relationships before it ever sees your data.

The breakthrough that transformed language applies to economic intelligence.

Language models demonstrated that pre-training on massive corpora produces representations that transfer to almost any downstream task with minimal supervision. A model that has read the world understands language well enough to be adapted into anything that uses it.

The **Graph Foundation Model (GFM)** applies the same paradigm to relationships. Pre-trained on a graph of companies, individuals, assets, and the events that connect them, the GFM develops a deep representation of how entities behave, connect, and evolve — before it sees a single label from your business.

<Info>
  A language model doesn't relearn English for every task. The GFM doesn't relearn what a healthy company looks like for every customer. It already knows. You define what matters for *your* business; the foundation does the rest.
</Info>

## Current specialization, expanding scope

Today the GFM is specialized for Brazil. It encodes Brazilian entity taxonomies, corporate structures, judicial and regulatory dynamics, and the specific shape of how relationships form in the local economy. That depth is the moat — generic graph models cannot match it on Brazilian decisions.

The same architecture extends. New regions become new GFM specializations, each pre-trained on the relational substrate of its own economy.

## What pre-training delivers

### Cold-start, solved

Traditional models fail on new and thin-file entities because they have no history. Pre-training changes the default.

| Scenario                  | Traditional model | Pre-trained GFM                                                |
| ------------------------- | ----------------- | -------------------------------------------------------------- |
| New entity, no financials | Reject or guess   | Infer from network position, similar entities, sector patterns |
| Individual with no record | Reject or guess   | Infer from relationships, geography, behavioral similarity     |
| Niche sector              | Poor coverage     | Cross-sector pattern transfer                                  |

### Time-to-value in days

Without pre-training, every new task starts from zero — months of data collection, feature engineering, and training before anything ships. With pre-training:

* Days, not months, to deploy a working model
* Smaller labeled datasets required to fine-tune downstream
* Better performance from the first iteration, because the foundation starts with real understanding

### One foundation, many tasks

Credit, fraud, growth, churn, custom classification — the same pre-trained representations underlie all of them. Each task adds only a lightweight downstream head on top of a foundation that already understands entities.

Solve one problem with Avra and the next one is already half-solved.

## Pair it with the RFM

The GFM understands the world. Your **[Relational Foundation Model](/platform/relational-foundation-model)** understands your business. Downstream models inherit from both.

The combination — public economy plus your private graph — is what makes Avra predictions structurally different from bureaus, internal models, or generic ML platforms.

## Versus other approaches

| Approach         | Pre-training                             | Personalization               | Graph-native |
| ---------------- | ---------------------------------------- | ----------------------------- | ------------ |
| **Bureaus**      | Historical payment data                  | None                          | No           |
| **In-house ML**  | Your data only                           | Full control                  | Rarely       |
| **Generic LLMs** | Text corpora                             | Prompting                     | No           |
| **Avra**         | Relational economy + your business graph | Tenant-isolated, per-customer | Yes          |


# Knowledge Graph
Source: https://docs.avra.ai/platform/large-knowledge-graph

The temporal graph that underlies the Graph Foundation Model — 1B+ entities, the relationships between them, and how both evolve over time.

The Large Knowledge Graph (LKG) is the substrate the Graph Foundation Model is pre-trained on. It captures companies, individuals, assets, and the events that connect them — as a temporal graph, not a snapshot.

Most data products treat relationships as enrichment: a column appended to a row. The LKG treats relationships as structure. Ownership chains, supply paths, judicial and regulatory events, and geographic context are modeled as edges in a graph, not flattened into features.

## What goes into the graph

<CardGroup>
  <Card title="Corporate and legal records" icon="building">
    Public registries, corporate filings, ownership structures, and judicial records form the authoritative skeleton of how entities are formally connected.
  </Card>

  <Card title="Behavioral and alternative data" icon="chart-line">
    Licensed datasets capturing economic activity, transaction patterns, and operational signals — the parts of how entities behave that official records do not see.
  </Card>

  <Card title="Geographic and macroeconomic context" icon="map">
    Regional dynamics, infrastructure, and sector conditions situate every entity in the economy it actually operates in.
  </Card>

  <Card title="Your business context" icon="circle-nodes">
    Customer-provided signals enter through your Relational Foundation Model — separate from the LKG, composed at inference time.
  </Card>
</CardGroup>

## Relationships as first-class structure

The graph encodes the relationships that actually drive outcomes:

* **Ownership and control** — direct and indirect participation, holding structures, beneficial ownership
* **Counterparty and supply** — observed business relationships, transaction proximity, dependency chains
* **Judicial and regulatory** — proceedings, sanctions, and compliance events that cascade through networks
* **Geographic and infrastructure** — regional clustering, shared facilities, supply-route proximity
* **Domain-specific** — franchise networks, branch hierarchies, group structures, industry associations

Each relationship type carries its own semantics in the graph. The GFM learns from all of them simultaneously.

## Temporal by design

A graph that only describes today cannot predict tomorrow.

* Every node and edge is versioned. We track when a relationship appears, changes, and disappears.
* Historical states are preserved. The GFM reasons about velocity and momentum, not just current state.
* Decision dates are explicit. Predictions for a past date see only the graph as it existed then — no future leakage, by construction.

## Why it matters

The LKG is not a deliverable on its own. It is the structured substrate that lets the GFM, your RFM, and every downstream model reason about relationships at scale.

* **Cold-start coverage** — new entities are positioned relative to their neighbors, not blanked out
* **Multi-hop reasoning** — risk and opportunity propagate through the graph, not just through direct connections
* **Stable temporal grounding** — backtests, replays, and shadow evaluations operate on the graph as it existed at decision time


# Adaptive Embeddings
Source: https://docs.avra.ai/platform/matryoshka-embeddings

How our embeddings automatically adapt to your model's complexity without losing predictive power.

Avra delivers embeddings as 1024-dimensional vectors from the Graph Foundation Model. Each vector is **adaptive**: you can slice it client-side to smaller dimensions (512, 256, 128, 64, 32, 16) while preserving semantic meaning and predictive power. One API call, one storage footprint, every dimension you need — no retraining, no separate endpoints.

## Why adaptive embeddings

* **One training pass, many footprints** — derive lighter embeddings for simpler models without retraining.
* **Consistent semantics** — lower-dimensional slices preserve the ordering and relative distances of the full vector.
* **Compose with your RFM** — workspace-specific representations update every slice simultaneously.

## Selecting a dimensionality

<Columns>
  <Column>
    <Card title="1024 dimensions">
      Maximum fidelity for deep learning, semantic search, or graph analytics where
      latency and storage are secondary.
    </Card>
  </Column>

  <Column>
    <Card title="512 dimensions">
      Balanced trade-off between richness and compute for most production
      workloads.
    </Card>
  </Column>

  <Column>
    <Card title="256 dimensions">
      Optimized for real-time scoring and streaming analytics on CPU-bound services.
    </Card>
  </Column>
</Columns>

<Columns>
  <Column>
    <Card title="128 dimensions">
      Ideal for dashboards, feature stores, and propensity models where storage is a
      concern but accuracy must remain high.
    </Card>
  </Column>

  <Column>
    <Card title="64 / 32 / 16 dimensions">
      Reserve for edge deployments or extreme latency constraints. Treat the size as
      a hyperparameter—step down gradually while monitoring KPIs.
    </Card>
  </Column>
</Columns>

<Callout type="info">
  All Avra API calls return the full 1024-dimensional embedding. Refer to the [API Reference](/api-reference/overview) for examples of slicing these vectors client-side to your desired dimensionality.
</Callout>

## Best practices

* Treat dimensionality as a hyperparameter: start at 256-d for tree-based models (XGBoost, LightGBM), evaluate performance, then adjust up or down based on validation metrics.
* Normalize vectors before computing cosine similarity or feeding them into distance-based models.
* Cache embeddings alongside the model snapshot ID so experiments remain reproducible.
* Avoid applying additional dimensionality reduction for production workloads—it degrades the learned semantics. Reserve techniques like PCA or t-SNE for visualization only.

## <a />Trajectory signals (temporal dynamics)

Embeddings aren’t static. As new signals arrive, an entity’s position moves—its “trajectory.” Reading this movement adds foresight to your models without changing your integration.

* Direction of change: is the entity moving toward patterns historically linked to risk or growth?
* Magnitude vs. noise: we compare movement to typical volatility to avoid false alarms.
* Aggregation: roll up movements at portfolio, sector, or region level to spot drift early.

How to use

* Credit: trigger reviews when customers move toward risky clusters before KPIs deteriorate.
* Growth: prioritize accounts whose movement matches your best customers’ pre‑expansion patterns.
* Ops: watch suppliers whose trajectories resemble prior disruption events.

Access

* Returned as movement indicators with relevant products (e.g., Credit Score) and accessible via embeddings over time for custom analytics.


# Relational Foundation Model
Source: https://docs.avra.ai/platform/relational-foundation-model

A customer-specific relational representation layer pre-trained with self-supervised objectives on your schema, temporal history, and entity relationships.

The Graph Foundation Model is pre-trained on the economy. The **Relational Foundation Model (RFM)** is your customer-specific relational representation layer.

Your business is its own graph. Customers, accounts, products, transactions, support tickets, sessions — these are connected entities with their own structure. A model trained on public economic data cannot see that structure. A model trained on your data alone cannot see the world around it.

The RFM closes both gaps. It is pre-trained with self-supervised objectives on your schema, temporal history, and entity relationships, then composed with the GFM for downstream prediction tasks. Every downstream model inherits both: the broader economy from the GFM and your business context from the RFM.

## What it is

The RFM is a customer-specific relational representation layer: pre-trained with self-supervised objectives on your schema, temporal history, and entity relationships, then composed with the GFM for downstream prediction tasks. It is not a generic score or a one-off downstream head; it is the private foundation layer from which your task-specific models are trained.

* **Pre-trained on your relational schema** — the entities you care about, the edges between them, and how both evolve over time
* **Self-supervised** — learns from the structure itself, before you supply labels
* **Composable with the GFM** — when an entity in your data resolves to an entity in our graph, both representations are available downstream
* **Yours alone** — weights are workspace-isolated and never shared across customers

## Deployment options

The RFM is the layer most likely to touch sensitive data. We designed it accordingly.

<CardGroup>
  <Card title="Managed by Avra" icon="cloud">
    The fastest path. Your data flows into a tenant-isolated environment, the RFM is trained and served by Avra, and downstream models are available through the API the same day.
  </Card>

  <Card title="Deployed in your environment" icon="building-shield">
    For data residency, regulatory, or sovereignty requirements: the RFM trains and runs inside your perimeter. Avra provides the training stack and the operator tooling; the data never leaves.
  </Card>
</CardGroup>

## The flywheel

The RFM gets stronger with every downstream model you train.

Each downstream task — a credit model, a churn model, a custom classifier — generates signal about which patterns in your data predict the outcomes you care about. That signal flows back into the RFM, refining its representation. The next downstream task starts from a stronger base.

This is what compounds. A frozen foundation is a one-time gift. A foundation that learns from every downstream task you train is an asset that appreciates.

## Lifecycle

<Steps>
  <Step title="Schema declaration">
    You declare the entities, edges, and identifiers in your relational data. Avra reconciles them against the entities the GFM already understands.
  </Step>

  <Step title="Ingestion">
    Stream or upload data through API, connectors, or SFTP. Each event is validated against the declared schema; deviations trigger a notification, not a silent failure.
  </Step>

  <Step title="Pre-training">
    The RFM is pre-trained on your relational schema and temporal business data, with strict temporal validation so the model never learns from the future.
  </Step>

  <Step title="Downstream training">
    Task-specific models are trained on top of the RFM and GFM together. Signal from each task is fed back into the RFM.
  </Step>

  <Step title="Promotion">
    New RFM and downstream snapshots are validated offline, mirrored against production traffic, and promoted only after meeting your performance bar.
  </Step>
</Steps>

## Data ownership

* Your raw data remains your exclusive property and is stored in dedicated tenant-isolated buckets.
* RFM weights are exclusive to your workspace and are never shared with or used to serve other customers.
* Audit exports let you inspect what data influenced any given snapshot.
* On-premise deployments give you full physical custody — no data crosses the boundary.

See [Data Privacy and Compliance](/security/data-privacy-and-compliance) for the full policy.


# Data Privacy & Compliance
Source: https://docs.avra.ai/security/data-privacy-and-compliance

How Avra handles your data, ensures privacy, and complies with LGPD, GDPR, and related regulations.

Data privacy is foundational. The architecture of the platform — three foundation layers, tenant isolation, on-premise deployment — exists in part to give you clean lines of custody over what is yours.

## Data ownership

Clear boundaries govern what belongs to whom.

* **Your raw data.** Any data you provide — CRM records, transactions, outcomes — remains your exclusive property. Avra acts as a data processor on your behalf.
* **Your Relational Foundation Model.** The RFM trained on your data is exclusive to your workspace. Its weights are never shared with or used to serve other customers.
* **The Graph Foundation Model.** The GFM is pre-trained on public and licensed data sources, not on customer data. Avra continuously improves the GFM's architecture and training methodology through research — those improvements benefit all customers, the same way a language model improves across versions without incorporating any user's data.

This is outlined in the Master Service Agreement.

## Data isolation

Raw data and Relational Foundation Models are never shared across customers.

<Card title="The Relational Foundation Model is yours alone" icon="building-shield">
  The Graph Foundation Model provides general understanding of the relational economy. Your **Relational Foundation Model** is pre-trained on your relational schema and temporal business data, and is exclusive to your organization.

  We maintain strict logical separation — your data, your RFM weights, and your downstream predictions are never accessible to other customers.
</Card>

We achieve this through:

* **Tenant isolation** — each customer's data and models are logically siloed within Avra's infrastructure
* **Access controls** — strict Role-Based Access Control (RBAC) and automated controls prevent any cross-customer access
* **Audit trail** — every access to customer data is logged and reviewable

## On-premise deployment

For customers with regulatory, sovereignty, or sensitivity constraints, the Relational Foundation Model can be deployed inside your own environment. In that configuration:

* Raw data never leaves your perimeter
* RFM training and serving run on your infrastructure
* The Graph Foundation Model continues to provide the broader economic context as a managed service

Contact your Avra representative to scope on-premise deployment.

## Regulatory compliance

Avra maintains compliance with data protection regulations including LGPD, GDPR, and other applicable frameworks. Our compliance program includes:

* **Data Processing Agreements (DPAs)** — contracts include DPAs outlining our roles and responsibilities as a data processor
* **Data subject rights** — processes to support your obligations for access, correction, and deletion requests
* **Data Protection Officer (DPO)** — a designated DPO oversees Avra's data protection strategy and practices
* **Data mapping and inventory** — a comprehensive record of what data we process, its purpose, and its retention

## Data retention and deletion

We retain your data only as long as necessary to provide our services or as required by law. When a partnership ends, we follow a secure data deletion process to permanently remove your proprietary data from our systems, as outlined in the service agreement.

For questions about our privacy practices, contact `legal@avra.ai`.


# Security Overview
Source: https://docs.avra.ai/security/overview

Learn how Avra ensures the confidentiality, integrity, and availability of your data.

At Avra, security is foundational to our platform and culture. Our information security management system (ISMS) is built on leading global standards, including **ISO 27001:2022** — for which certification is currently in progress — and the **NIST Cybersecurity Framework (CSF) 2.0**. Our approach is built on the core principles of Confidentiality, Integrity, and Availability (the CIA triad).

<Card title="Avra's Trust Center" icon="shield-halved" href="https://trust.avra.ai">
  Access our trust center to learn more about Avra's security practices.
</Card>

## Key Pillars of Our Security Program

### Confidentiality

We ensure that your data is accessed only by authorized users.

* **Encryption**: Data is encrypted both **in transit** using TLS 1.2+ and **at rest** using industry-standard AES-256 encryption. Our cloud storage (e.g., AWS S3) uses server-side encryption with keys managed by AWS Key Management Service (KMS).
* **Principle of Least Privilege**: Access to data and systems is granted on a strict need-to-know basis.
* **Role-Based Access Control (RBAC)**: A robust RBAC model with automated, group-based permissions ties access to each user's role and revokes it on departure.
* **Data Isolation**: Customer data is logically isolated and never exposed to or used by other customers. The Relational Foundation Model can additionally be deployed inside your environment for full physical custody. See [Data Privacy & Compliance](/security/data-privacy-and-compliance) for details.

### Integrity

We maintain the accuracy and consistency of your data throughout its lifecycle.

* **Immutable Audit Logs**: All API calls and sensitive actions are logged to a tamper-evident audit trail. Customer-visible events are available in the dashboard under Observability → Audit.
* **Input Validation**: Data is validated against predefined schemas upon ingestion to prevent corruption.
* **Version Control**: Our models and infrastructure are managed as code (`IaC`) and follow git-based workflows with mandatory peer review to ensure changes are deliberate and tracked.

### Availability

We design our systems for resilience to ensure you have reliable access to our services.

* **Multi-Cloud Architecture**: We operate across multiple top-tier cloud providers to build a resilient and scalable infrastructure with no single point of failure.
* **High Availability**: Our services are deployed across multiple availability zones (AZs) with auto-scaling and health checks to handle failures gracefully.
* **Disaster Recovery**: We have comprehensive backup and disaster recovery plans that are regularly tested to ensure business continuity.

## Secure Development & Operations

* **Employee Security**: All employees undergo background checks and receive regular security awareness training. Multi-Factor Authentication (MFA) is mandatory for access to all critical systems.
* **Vulnerability Management**: We continuously scan our code and infrastructure for vulnerabilities and have a clear policy for responsible disclosure. See our [Vulnerability Disclosure Policy](/security/vulnerability-disclosure-policy).
* **Third-Party Audits**: We engage independent third-party auditors to perform penetration tests and security assessments to validate our controls.

For further questions about Avra's security posture, please contact us at `security@avra.ai` or visit our [Trust Center](https://trust.avra.ai).


# Vulnerability Disclosure Policy
Source: https://docs.avra.ai/security/vulnerability-disclosure-policy

Our guidelines and commitment for working with the security community to report and resolve vulnerabilities.

At Avra, we consider the security of our systems a top priority. We value the essential role the security community plays in helping us protect our platform and our customers. We are committed to working with skilled, good-faith researchers to identify and resolve vulnerabilities in a responsible and timely manner.

If you have discovered a security vulnerability, we encourage you to report it to us privately. We will work with you to understand and resolve the issue promptly.

## Reporting a Vulnerability

Please report any potential vulnerabilities to our security team via email: `security@avra.ai`

To help us investigate efficiently, please include the following in your report:

* **A clear description** of the vulnerability, including its potential impact.
* **Detailed steps to reproduce the issue**, including any URLs, request/response captures, or proof-of-concept code.
* **Your contact information** and, if you wish, a link to a public profile for recognition.

## What to Expect (Our Commitment)

When you report a vulnerability in accordance with this policy, we promise to:

<Steps>
  <Step title="Triage">
    Acknowledge receipt of your report within **3 business days** and assign it
    a tracking identifier.
  </Step>

  <Step title="Investigation">
    Validate and investigate your report. We may contact you for additional
    information if needed.
  </Step>

  <Step title="Communication">
    Provide status updates as we work on a fix, keeping you informed of our
    progress.
  </Step>

  <Step title="Resolution">
    Notify you when the vulnerability has been resolved.
  </Step>

  <Step title="Recognition">
    Publicly thank you for your contribution on our "Acknowledgements" page,
    with your permission. We value your work and believe in giving credit where
    it is due.
  </Step>
</Steps>

## Rules of Engagement

To ensure the process is safe and productive for everyone, we ask that you adhere to the following guidelines:

#### Please do:

* Report any vulnerability you've discovered promptly and privately.
* Avoid privacy violations, destruction of data, and interruption or degradation of our service during your testing.
* Make a good-faith effort to avoid accessing or modifying data that does not belong to you. If you encounter any non-public user or company data, stop your test and report it immediately.

#### Please do not:

* Perform any actions that could negatively affect Avra's users, such as Denial of Service (DoS), spamming, or social engineering (phishing).
* Access or attempt to access data that does not belong to you beyond what is necessary to demonstrate the vulnerability.
* Disclose any vulnerabilities to the public or third parties without our express written consent.
* Attempt physical attacks against Avra employees, offices, or data centers.

## Safe Harbor

Avra is committed to protecting security researchers. If you comply with this policy during your security research, we will consider your research to be authorized. **We will not initiate legal action or a law enforcement investigation against you in response to your report.**

We will work with you to understand and resolve the issue quickly, and we will not engage in legal action for accidental, good-faith violations of this policy.

## Scope

This policy applies to all systems and services owned and operated by Avra.

#### In-Scope Assets:

* `*.avra.ai` (including subdomains)
* `app.avra.ai`
* `api.avra.ai`

#### Out-of-Scope Vulnerabilities:

While we encourage any reports that could have a security impact, the following issues are generally considered out of scope for our disclosure program (unless they can be shown to lead to a higher-impact vulnerability):

* Missing security headers (e.g., `Content-Security-Policy`, `Strict-Transport-Security`) without a demonstrated, practical exploit.
* Descriptive error messages (e.g., stack traces) without the exposure of sensitive information.
* Reports from automated scanners without manual validation.
* Self-XSS (Cross-Site Scripting) that cannot be used to attack other users.
* Issues related to software or protocols not under Avra's direct control (e.g., vulnerabilities in a third-party service we use).
* Rate limiting or brute-force attack issues on non-authentication endpoints.

Thank you for helping keep Avra and our users safe.


# Risk Bands
Source: https://docs.avra.ai/solutions/credit-score/homogeneous-groups

Optimal score binning and homogeneous risk groups for operationalizing credit decisions.

## From Scores to Policy

A credit score tells you *how risky* an entity is. **Risk bands** tell you *what to do about it*.

Risk bands (also known as homogeneous risk groups) are score bins where entities within each group behave similarly, while groups are clearly distinct from each other. Unlike arbitrary deciles or fixed ranges, optimal risk bands are **statistically optimized** using both the model score and observed outcomes.

## Why Risk Bands Matter

| Use Case                 | How Risk Bands Help                                                   |
| ------------------------ | --------------------------------------------------------------------- |
| **Policy Cutoffs**       | Set clear approve/review/deny thresholds aligned to observed outcomes |
| **Pricing Tiers**        | Map bins directly to interest rate or limit brackets                  |
| **Portfolio Monitoring** | Track bin migration over time as an early warning system              |
| **Model Validation**     | Verify bins remain separated as new data arrives                      |

## Creating Optimal Bins

We recommend using optimal binning algorithms that maximize separation between groups. The `optbinning` library provides a robust implementation:

```python theme={null}
from optbinning import OptimalBinning

# Create optimal bins from score and outcome
optb = OptimalBinning(name="avra_score", dtype="numerical")
optb.fit(scores, defaults)

# Get bin boundaries and statistics
binning_table = optb.binning_table.build()
print(binning_table)
```

### Alternative Approaches

| Method                        | Description                                            |
| ----------------------------- | ------------------------------------------------------ |
| **Chi-squared binning**       | Merge adjacent bins until chi-squared threshold is met |
| **Weight of Evidence (WoE)**  | Optimize bins for maximum information value            |
| **Equal-frequency quantiles** | Starting point before optimization                     |
| **Business-driven**           | Manual boundaries based on policy requirements         |

## Evaluating HRG Quality

### What You Want to See

Track default rates per bin over time. A well-constructed HRG shows:

* **Clear separation** — Default rates are distinct between adjacent bins
* **Stable PD over time** — Each bin's default rate stays consistent month-over-month
* **Balanced distribution** — Reasonable volume in each bin to support policy decisions

### Warning Signs

* **Line crossings** — When two bins' default rates cross over time, risk distinction is breaking down. This indicates the model may need recalibration.

* **Concentration** — If 80% of entities fall in 2-3 bins, setting policy cutoffs becomes difficult. Consider adjusting bin boundaries or reviewing score distribution.

* **Drift** — Systematic movement of default rates within bins signals model degradation. Monitor for gradual shifts that compound over time.

## Monitoring Over Time

We recommend visualizing default rates per bin across cohorts:

```python theme={null}
import matplotlib.pyplot as plt

# Each line represents a score bin
# X-axis: time (cohort month)
# Y-axis: realized default rate

for bin_name, data in bin_cohort_data.items():
    plt.plot(data['months'], data['default_rate'], label=bin_name)

plt.xlabel('Cohort Month')
plt.ylabel('Default Rate')
plt.legend()
plt.title('HRG Stability Over Time')
```

**Healthy pattern**: Parallel lines that maintain separation over time.

**Concerning pattern**: Lines that converge, cross, or show systematic drift.

<Info>
  We work with clients to define and monitor risk bands as part of model deployment. This includes tracking bin stability over time and alerting when recalibration may be needed.
</Info>


# Credit Intelligence
Source: https://docs.avra.ai/solutions/credit-score/overview-and-methodology

Dynamic credit risk assessment powered by two pre-trained foundation models and your business outcomes.

## Beyond static scores

Traditional credit scoring looks at an entity in isolation — payment history, registered debts, basic attributes. It misses the context that actually predicts outcomes.

**Credit risk is relational.** An entity's risk profile depends on its counterparties, its position in supply chains, the health of its network. A company with a perfect payment history becomes high-risk when its main customer is failing.

<Info>
  Avra's foundations capture relationship patterns that traditional systems miss — multi-hop network effects, behavioral trajectories, and latent risk signals.
</Info>

## How Avra assesses credit

We compose two pre-trained foundations with your business reality:

<Steps>
  <Step title="Graph Foundation Model">
    The GFM already understands the relational economy — entities, their counterparties, supply paths, judicial events, sector dynamics. Network position and behavioral trajectories are learned before we ever see your portfolio.
  </Step>

  <Step title="Your Relational Foundation Model">
    Your RFM brings your portfolio's reality — customers, payment behavior, the connections that matter for your specific lending or trade-credit operation.
  </Step>

  <Step title="Downstream credit model">
    A task-specific model is trained on top of both foundations using your delinquency definitions and outcomes. Signal from training feeds back into your RFM, making the next iteration sharper.
  </Step>
</Steps>

## What you receive

### Credit score and probability of default

Every prediction returns both:

* A **0–1000 credit score** for easy integration with existing decision engines and policy rules.
* A **calibrated probability of default (PD)** for risk-based pricing, capital allocation, and portfolio analytics.

The score is derived from the PD — monotonic, stable across versions, and aligned with your delinquency definition.

### Multi-horizon PD

PD is delivered across multiple time horizons so each decision uses the window that matches its policy:

| Horizon      | Typical use case                           |
| ------------ | ------------------------------------------ |
| **30 days**  | Short-term liquidity, payment-timing risk  |
| **60 days**  | Trade credit, early delinquency signals    |
| **90 days**  | Standard lending decisions                 |
| **180 days** | Medium-term facilities, portfolio planning |
| **365 days** | Annual loss forecasting, IFRS 9 staging    |

Each horizon is independently calibrated — the 30-day PD is not a scaled version of the 365-day PD. Different signals matter at different time scales.

### Fine-tuned PD

Beyond the standard horizons, downstream credit models are calibrated to **your delinquency definition**. Common shapes:

| Definition      | Description                                      |
| --------------- | ------------------------------------------------ |
| **FPD**         | First Payment Default — never made first payment |
| **Over30MOB6**  | 30+ days past due by month 6 on book             |
| **Over60MOB12** | 60+ days past due by month 12 on book            |
| **Charge-off**  | Written off as a loss                            |

You define what "bad" means; the downstream model learns it. The reported PD is the probability of *your* event, not a generic default.

### Risk drivers

API responses include the key factors influencing each score — the network signals, behavioral patterns, and entity attributes that drove the prediction. Useful for review queues, customer communication, and regulatory transparency.

### Dynamic risk monitoring

Beyond point-in-time scoring, Avra provides **trajectory analysis** — how entities move through the representation space over time:

* **Early warning** — spot entities moving toward delinquent patterns before traditional metrics show problems.
* **Portfolio monitoring** — track aggregate risk movements across your book.
* **Intervention timing** — identify the moment to act, not the moment to react.

## How we measure performance

We evaluate models using metrics that together give a complete picture:

* **ROC-AUC** — primary discrimination across all decision thresholds.
* **PR-AUC** — critical when defaults are rare and false alarms expensive.
* **KS statistic** — maximum separation between good and bad distributions, widely used by financial institutions for model validation.

## Why this works

<CardGroup>
  <Card title="Cold-start solved" icon="rocket">
    Traditional models struggle with new or data-scarce entities. The graph approach infers risk from network connections, even with limited direct history.
  </Card>

  <Card title="Context-aware" icon="eye">
    Trained on your RFM, scores reflect your business relationships. A pattern normal for one segment might be high-risk in another.
  </Card>

  <Card title="Explainable" icon="list-check">
    API responses include the key factors influencing each score — transparency for decisions and for compliance.
  </Card>

  <Card title="Temporal" icon="clock">
    Not just who an entity is today, but how they are evolving. Trajectory matters more than snapshots.
  </Card>
</CardGroup>

## From scores to policy

Scores and probabilities are decision *inputs*. To operationalize them you typically bucket entities into homogeneous risk groups so policy thresholds map cleanly onto approve / review / deny decisions and pricing tiers. See [Risk Bands](/solutions/credit-score/homogeneous-groups) for the canonical approach to optimal binning, monitoring bin stability over time, and detecting drift.

## Integration

Credit intelligence is available through:

* **Real-time API** — sub-second scores for underwriting decisions
* **Batch processing** — score entire portfolios on a schedule
* **Embeddings** — use Avra representations as features in your own credit models


# Score Range and Interpretation
Source: https://docs.avra.ai/solutions/credit-score/score-range-and-interpretation

How Avra delivers credit scores, probability of default, and embeddings — and how to use them.

## What you receive

Every credit prediction includes three artifacts:

<AccordionGroup>
  <Accordion title="Credit Score (0–1000)" icon="gauge-high">
    A transformed, calibrated score for easy integration with your existing decision engines and policy rules.

    * **1000** = lowest risk (probability of default approaches 0%)
    * **0** = highest risk (probability of default approaches 100%)
  </Accordion>

  <Accordion title="Probability of Default (PD)" icon="chart-line">
    The raw probability behind the score — calibrated to your delinquency definition.

    * **Direct interpretation** — "this entity has a 15% chance of defaulting under your definition"
    * **Pricing and reserves** — calibrated probabilities for risk-based pricing, IFRS 9 staging, and capital allocation
    * **Multi-horizon** — PD is returned across 30, 60, 90, 180, and 365-day windows so each decision uses the horizon that matches its policy
  </Accordion>

  <Accordion title="Avra Embeddings" icon="cube">
    1024-dimensional representations of each entity.

    * **Similarity analysis** — find entities with similar risk profiles
    * **Feature engineering** — enhance your own models with relationship-aware features
    * **Custom analytics** — segmentation, monitoring, and anomaly detection
  </Accordion>
</AccordionGroup>

## How the score is constructed

The 0–1000 score is derived from the underlying probability of default through a calibrated transformation. The relationship is monotonic — a higher score is always lower risk — and stable across model versions, so policy thresholds you set today continue to hold meaning as the underlying foundations improve.

```json theme={null}
{
  "score": 842,
  "pd_30d": 0.004,
  "pd_60d": 0.006,
  "pd_90d": 0.011,
  "pd_180d": 0.024,
  "pd_365d": 0.051,
  "risk_band": "low",
  "key_factors": [
    "Stable counterparty network",
    "Positive trajectory over last 6 months",
    "Sector health above baseline"
  ]
}
```

### Multi-horizon PD fields

| Field     | Horizon  | Use case                                |
| --------- | -------- | --------------------------------------- |
| `pd_30d`  | 30 days  | Short-term liquidity, payment timing    |
| `pd_60d`  | 60 days  | Trade credit, early delinquency         |
| `pd_90d`  | 90 days  | Standard credit bureau equivalent       |
| `pd_180d` | 180 days | Medium-term portfolio planning          |
| `pd_365d` | 365 days | Annual loss forecasting, IFRS 9 staging |

Each horizon is independently calibrated. The 30-day PD is not a scaled 365-day PD — different signals matter at different time scales, and the model exposes them separately so each policy can pick its own window.

## Defining delinquency

The definition of a "bad" outcome is **defined by you**. During onboarding we work with you to label your historical accounts as good or bad based on your operational definition. Common examples:

* **MOB 6 > 30** — account is more than 30 days past due in the 6th month on book
* **FPD 90** — first payment default after 90 days
* **Charge-off** — debt written off as a loss

The downstream credit model is trained on top of your RFM using your labels. The 0–1000 scale is calibrated to reflect the probability of *your* specific outcome, not a generic default definition.

## Score bands

To simplify decision-making, scores group into operational risk bands. The table below is a general guide; exact PD per band shifts with your delinquency definition, but the monotonic relationship (higher score = lower risk) always holds.

| Score Range    | Risk Band      | Interpretation & Recommended Action                                           |
| :------------- | :------------- | :---------------------------------------------------------------------------- |
| **900 – 1000** | Exceptional    | Prime profile; minimal risk. Suitable for automated approval, highest limits. |
| **800 – 899**  | Low Risk       | Very strong profile. Confidently approve with favorable terms.                |
| **700 – 799**  | Moderate Risk  | Good profile. Generally safe to approve, may consider standard terms.         |
| **600 – 699**  | Medium Risk    | Warrants caution. May require additional review, lower limits, or collateral. |
| **400 – 599**  | High Risk      | Significant risk of default. Requires strict terms, guarantees, or denial.    |
| **0 – 399**    | Very High Risk | Extreme risk. Not recommended for credit extension.                           |

## Why probability matters more than the score alone

The 0–1000 score is convenient for decision rules. The underlying probability is what gives you the business intelligence to:

* **Price accurately** — set rates based on actual expected loss
* **Manage portfolios** — calculate reserves and capital requirements
* **Monitor trends** — track how risk evolves over time
* **Compare segments** — understand variations across customer types


# Applications
Source: https://docs.avra.ai/solutions/embeddings/embedding-applications

Learn how Avra's embeddings are applied across various use cases to deliver actionable insights for businesses.

Avra's embeddings are versatile, powerful features for a wide range of intelligent applications. As representations from the Graph Foundation Model and your Relational Foundation Model, they are the building blocks for solving complex business problems.

## Key Applications

### Enhanced Credit Risk Prediction

Embeddings power Avra's own <a href="/solutions/credit-score/overview-and-methodology">Credit Score solution</a> — and you can use them directly as features in your internal models.

* **How it Works**: By using our embeddings as features, your models can capture complex, non-linear signals about an entity's network, behavior, and latent risks that are impossible to derive from traditional data sources.
* **Benefit**: Achieve a significant uplift in model performance (ROC-AUC, Gini) and make more accurate predictions, especially for thin-file entities.

### Intelligent Audience Segmentation & Lookalike Modeling

Go beyond simple firmographics to find your true ideal customers.

* **How it Works**: Calculate the similarity (e.g., using cosine distance) between the embedding of a known "good" customer and your prospect base. The prospects with the most similar embeddings are your highest-potential lookalikes.
* **Benefit**: Dramatically improve lead conversion rates by focusing sales and marketing efforts on prospects that behave just like your best customers.

### Lifetime Value (LTV) Prediction

Forecast the long-term value of a customer with greater accuracy.

* **How it Works**: Embeddings capture patterns in revenue, engagement, and growth trends that are highly predictive of future value. Use them as features in your LTV models to understand which customers are worth investing in.
* **Benefit**: Optimize marketing spend, tailor retention strategies, and focus your account management efforts on high-potential customers.

### Fraud Detection and Anomaly Detection

Embeddings excel at identifying subtle patterns that signal fraudulent or unusual activity.

* **How it Works**: In the embedding space, fraudulent entities often form distinct clusters or appear as outliers far from legitimate groups. By monitoring these patterns, you can flag suspicious activity in real-time.
* **Benefit**: Detect and prevent fraud faster by identifying anomalies, suspicious networks of connected entities, and deviations from normal behavior.

### Economic Insights and Benchmarking

Use embeddings to understand the competitive landscape and your position within it.

* **How it Works**: Visualize the embedding space (using UMAP or t-SNE) to see how your company, your customers, and your competitors cluster. Identify "white space" in the market or benchmark your customers against their peers.
* **Benefit**: Gain a data-driven, holistic view of the economic ecosystem to inform strategic decisions, M\&A activity, and market entry plans.


# Build with Embeddings
Source: https://docs.avra.ai/solutions/embeddings/overview

Use Avra's learned representations as features in your own models.

## What are embeddings?

**1024-dimensional vectors** that encode everything the Graph Foundation Model and your Relational Foundation Model understand about an entity: network position, relationships, behavioral patterns, risk profile, trajectory.

Compressed intelligence you can plug into any ML model.

<Info>
  The same embeddings power Avra's credit, fraud, and growth solutions. When you use embeddings directly, you get the same intelligence with full control over your model architecture.
</Info>

## Why Use Our Embeddings?

| Your Approach              | Time     | Coverage          | Signal Quality                                 |
| -------------------------- | -------- | ----------------- | ---------------------------------------------- |
| Manual feature engineering | Months   | Your data only    | Limited to what you can imagine                |
| Traditional data providers | Days     | Partial coverage  | Static, lagging indicators                     |
| **Avra Embeddings**        | **Days** | **Full coverage** | **Multi-hop relationships, temporal patterns** |

Our Graph Neural Network captures patterns you can't manually engineer: second-degree counterparty risk, regional clusters, ownership network anomalies, behavioral trajectory.

## See It In Action

<SimpleDiscovery />

<Columns>
  <Column>
    <Callout type="success" title="Thin-file ready">
      Pre-training means even new or sparse entities arrive with meaningful representations.
    </Callout>
  </Column>

  <Column>
    <Callout type="default" title="Cross-functional">
      Risk, growth, fraud, and analytics teams share a common signal without rebuilding pipelines.
    </Callout>
  </Column>

  <Column>
    <Callout type="tip" title="Private">
      Your data never leaves your workspace. Your RFM produces a customer-specific embedding space.
    </Callout>
  </Column>
</Columns>

## What You Receive

| Asset              | Details                                                                                              |
| ------------------ | ---------------------------------------------------------------------------------------------------- |
| **Embedding API**  | Deterministic endpoint returning 1024-d vectors; slice client-side to 512 / 256 / 128 / 64 / 32 / 16 |
| **Metadata**       | Model snapshot, version, and quality flags for provenance tracking                                   |
| **Explainability** | Optional attribution payloads highlighting top factors                                               |
| **Support**        | Dashboard insights, webhook notifications, solution engineering                                      |

## Delivery Patterns

<Tabs>
  <Tab title="Real-time API">
    Low-latency retrieval for onboarding, underwriting, and interactive analytics. See the [technical guide](/solutions/embeddings/technical-implementation) for request schema.
  </Tab>

  <Tab title="Batch Jobs">
    Submit large portfolios for asynchronous processing. See [Batch Inference](/data-operations/batch-inference) for setup.
  </Tab>

  <Tab title="Feature Stores">
    Persist embeddings in your warehouse or feature store to power ML pipelines and experimentation.
  </Tab>
</Tabs>

## When to Use Embeddings

* You need predictive signal for entities with little proprietary history
* You want to centralize intelligence for multiple initiatives without duplicating work
* You're building models that must remain explainable across teams

## Get Started

1. **Review integration options** in the [Technical Guide](/solutions/embeddings/technical-implementation)
2. **Explore use cases** in [Applications](/solutions/embeddings/embedding-applications)
3. **Configure monitoring** using [Model Lifecycle](/data-operations/model-lifecycle)


# Technical Guide
Source: https://docs.avra.ai/solutions/embeddings/technical-implementation

Embedding specifications, dimension selection, and integration patterns.

## Embedding Specifications

| Property               | Value                           |
| ---------------------- | ------------------------------- |
| **Base dimension**     | 1024                            |
| **Matryoshka slicing** | 1024, 512, 256, 128, 64, 32, 16 |
| **Distance metric**    | Cosine similarity               |
| **Normalization**      | L2 normalized                   |

Slice embeddings client-side by taking the first N elements:

```python theme={null}
embedding_1024 = response["vector"]  # Full 1024-d
embedding_256 = embedding_1024[:256]  # Slice to 256-d
```

<Warning>
  Slice only **prefix dimensions** we explicitly support (16/32/64/128/256/512/1024). Avoid arbitrary cuts or mixing non-prefix subsets across experiments — that discards the Matryoshka structure and reduces information entropy.
</Warning>

<Accordion title="Why not PCA, t-SNE, or UMAP?">
  Matryoshka embeddings are fundamentally different from post-hoc dimensionality reduction:

  | Approach       | How it works                                                                                                                     | Trade-offs                                                                  |
  | -------------- | -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
  | **Matryoshka** | Model is trained to encode the most important information in earlier dimensions. Prefix slices are semantically valid by design. | Zero compute at inference — just slice the array.                           |
  | **PCA**        | Linear projection fitted on existing embeddings.                                                                                 | Loses non-linear structure. Requires fitting and storing projection matrix. |
  | **t-SNE**      | Non-linear transform optimized for 2D/3D visualization.                                                                          | Expensive to compute. Not designed for downstream ML tasks.                 |
  | **UMAP**       | Non-linear, better than t-SNE for ML.                                                                                            | Still requires fitting. New samples need transform step.                    |

  With Matryoshka, dimensionality selection becomes a hyperparameter you can tune at zero marginal cost — no recomputation, no projection matrices, no information loss from post-hoc transforms.
</Accordion>

## Dimension Selection

| Dimension   | Use Case                           | Model Type                          |
| ----------- | ---------------------------------- | ----------------------------------- |
| **16-64**   | Resource-constrained, simple rules | Decision trees, logistic regression |
| **128**     | Latency-sensitive, linear models   | Online scoring, real-time APIs      |
| **256-512** | Balanced performance               | XGBoost, LightGBM, CatBoost         |
| **1024**    | Maximum signal                     | Deep learning, vector retrieval     |

<Info>
  Start with **256-d** for tree-based models. Only scale up if validation metrics improve.
</Info>

## Late Fusion Pattern

The recommended integration approach: combine embeddings with your features in a tree-based model.

```python theme={null}
import pandas as pd
from lightgbm import LGBMClassifier

# Your features
df = pd.DataFrame({
    "revenue": [...],
    "age_months": [...],
    "bureau_score": [...],
    "default": [...]  # target
})

# Add Avra embeddings (256-d for tree models)
embedding_cols = [f"emb_{i}" for i in range(256)]
for i, col in enumerate(embedding_cols):
    df[col] = [emb[i] for emb in embeddings_256d]

# Train
X = df.drop("default", axis=1)
y = df["default"]

model = LGBMClassifier()
model.fit(X, y)
```

### Hyperparameter search (embedding dimension)

Treat the embedding dimension as a tunable hyperparameter. Because the embeddings are Matryoshka-sliced, you can evaluate multiple dimensions without re-embedding.

```python theme={null}
import numpy as np
import optuna
import lightgbm as lgb
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score

# From the Late Fusion example above
embedding_1024 = np.array(embeddings_1024d)  # (n_samples, 1024)
base_features = df[["revenue", "age_months", "bureau_score"]].values
labels = df["default"].values

idx = np.arange(len(df))
train_idx, val_idx, y_train, y_val = train_test_split(
    idx, labels, test_size=0.2, random_state=42, stratify=labels
)

X_train_base = base_features[train_idx]
X_val_base = base_features[val_idx]

def objective(trial):
    dim = trial.suggest_categorical("embedding_dim", [16, 32, 64, 128, 256, 512, 1024])

    emb_train = embedding_1024[train_idx, :dim]
    emb_val = embedding_1024[val_idx, :dim]

    X_train = np.hstack([X_train_base, emb_train])
    X_val = np.hstack([X_val_base, emb_val])

    model = lgb.LGBMClassifier(
        n_estimators=trial.suggest_int("n_estimators", 200, 1200),
        learning_rate=trial.suggest_float("learning_rate", 0.01, 0.2, log=True),
        num_leaves=trial.suggest_int("num_leaves", 31, 255),
        max_depth=trial.suggest_int("max_depth", 3, 10),
        subsample=trial.suggest_float("subsample", 0.6, 1.0),
        colsample_bytree=trial.suggest_float("colsample_bytree", 0.6, 1.0),
        random_state=42,
        verbosity=-1
    )

    model.fit(
        X_train,
        y_train,
        eval_set=[(X_val, y_val)],
        callbacks=[lgb.early_stopping(50, verbose=False)]
    )

    preds = model.predict_proba(X_val)[:, 1]
    return roc_auc_score(y_val, preds)

study = optuna.create_study(direction="maximize")
study.optimize(objective, n_trials=50, show_progress_bar=True)

print(f"Best AUC: {study.best_value:.4f}")
print(f"Best dimension: {study.best_params['embedding_dim']}")
```

## Similarity Search

Find entities similar to a seed set:

```python theme={null}
import numpy as np
from sklearn.metrics.pairwise import cosine_similarity

def find_similar(seed_embedding, candidate_embeddings, top_k=100):
    similarities = cosine_similarity([seed_embedding], candidate_embeddings)[0]
    top_indices = np.argsort(similarities)[-top_k:][::-1]
    return top_indices, similarities[top_indices]

# Find companies similar to your best customers
best_customer_emb = get_embedding("12345678000199")
similar_idx, scores = find_similar(best_customer_emb, all_embeddings, top_k=1000)
```

## Caching Strategy

Persist embeddings with metadata for reproducibility:

```python theme={null}
embedding_response = {
    "model_snapshot": "...",
    "generated_at": "..."
}

cache_record = {
    "legal_document": "12345678000199",
    "vector": embedding,
    "model_snapshot": embedding_response["model_snapshot"],
    "generated_at": embedding_response["generated_at"],
    "dimension": 1024
}
```

**Refresh when**:

* A new GFM or RFM snapshot is promoted (webhook notification)
* A downstream model retrains and feeds signal back into your RFM

## Monitoring

Track embedding quality over time:

```python theme={null}
# Monitor distribution drift
from scipy.stats import ks_2samp

historical_norms = [np.linalg.norm(e) for e in historical_embeddings]
current_norms = [np.linalg.norm(e) for e in current_embeddings]

stat, pvalue = ks_2samp(historical_norms, current_norms)
if pvalue < 0.05:
    alert("Embedding distribution shift detected")
```


# Fraud Detection
Source: https://docs.avra.ai/solutions/fraud/overview

Network-based fraud intelligence that catches patterns invisible to rule engines and isolated entity analysis.

## Beyond Rules and Attributes

Traditional fraud detection relies on rules and isolated entity analysis. It catches known patterns but misses the sophisticated schemes that exploit network relationships.

**Fraud is a network problem.** A company might look clean in isolation, but its connections reveal the truth: shared addresses with known bad actors, ownership links to shell entities, suppliers with suspicious patterns.

<Info>
  Our Graph Foundation Model analyzes entities within their relationship context—capturing multi-hop patterns that traditional approaches can't see.
</Info>

## How Avra Detects Fraud

<Steps>
  <Step title="Entity Intelligence">
    Registration anomalies, address inconsistencies, ownership patterns, activity mismatches
  </Step>

  <Step title="Network Analysis">
    Multi-hop relationships: counterparties, suppliers, ownership chains, shared infrastructure
  </Step>

  <Step title="Behavioral Patterns">
    Transaction velocity, payment patterns, seasonal variations—compared against similar legitimate entities
  </Step>

  <Step title="Temporal Dynamics">
    How is this entity evolving? Rapid changes in network position often signal fraud or distress
  </Step>
</Steps>

## What We Catch

| Signal Type          | What Traditional Systems See      | What Avra Sees                                   |
| -------------------- | --------------------------------- | ------------------------------------------------ |
| **Shell entities**   | Clean registration, no red flags  | Multi-hop connections to known bad actors        |
| **Identity fraud**   | Valid documents, matching records | Ownership network anomalies, address clustering  |
| **Bust-out schemes** | Good payment history building     | Trajectory toward known fraud patterns           |
| **Collusion rings**  | Unrelated legitimate entities     | Hidden network connections, coordinated behavior |

## Use Cases

<CardGroup>
  <Card title="Onboarding Verification" icon="user-check">
    Screen new counterparties before establishing relationships
  </Card>

  <Card title="Transaction Monitoring" icon="credit-card">
    Real-time risk signals for payment authorization
  </Card>

  <Card title="Portfolio Screening" icon="folder-open">
    Periodic review of existing relationships for emerging risks
  </Card>

  <Card title="Investigation Support" icon="magnifying-glass">
    Deep network analysis when suspicious activity is detected
  </Card>
</CardGroup>

## Powered by two foundations

Fraud detection is where Avra's network intelligence is most direct. The **Graph Foundation Model** has learned what legitimate and suspicious network structures look like across the broader economy. Your **Relational Foundation Model** has learned the shape of your own transactions, customers, and accounts. The downstream fraud model is trained on top of both — and every training run feeds signal back into your RFM, making the next iteration sharper.

### Customer Data Needed

| Data                    | Purpose                                                                         |
| ----------------------- | ------------------------------------------------------------------------------- |
| **Fraud labels**        | Historical confirmed fraud and legitimate cases to define your fraud definition |
| **Transaction history** | Payment patterns, amounts, and counterparty details                             |
| **Application data**    | Onboarding information for registration-time scoring                            |

### Output Schema

| Field           | Description                                                                            |
| --------------- | -------------------------------------------------------------------------------------- |
| `fraud_score`   | Probability (0-1) that the entity or transaction is fraudulent                         |
| `risk_factors`  | Key signals contributing to the score (network anomalies, velocity, entity attributes) |
| `network_flags` | Specific multi-hop connections to known bad actors or suspicious clusters              |

### Evaluation Metrics

* **PR-AUC** — Primary metric, given the rarity of fraud events. Measures precision-recall trade-off across all thresholds.
* **ROC-AUC** — Overall discrimination between fraud and legitimate activity.
* **False Positive Rate at fixed recall** — Operational metric: how many legitimate entities are flagged at your desired catch rate.

## Multi-resolution embeddings for fraud

Avra's [adaptive embeddings](/platform/matryoshka-embeddings) enable multi-resolution fraud architectures:

* **Transaction-level (64–128d)** — lightweight embeddings for real-time transaction scoring where latency is critical. Fast enough to run on every payment.
* **Entity-level (512–1024d)** — full-resolution embeddings for deep entity analysis. Rich context about the entity including network position, ownership patterns, and behavioral history.

This allows your fraud model to combine quick transaction signals with deep entity intelligence—smaller embeddings provide speed, larger embeddings provide context.


# Field Sales
Source: https://docs.avra.ai/solutions/growth/field-sales

Optimize territory planning and visit prioritization with entity intelligence.

## The Territory Problem

Field sales is expensive. A rep can visit maybe 5-8 accounts per day. Choosing the wrong accounts wastes days of selling time.

Traditional territory planning uses static lists: "Visit all accounts over R\$1M revenue in the South region." But revenue doesn't predict who's ready to buy.

## Intelligence-Driven Territories

Instead of geography + firmographics, plan territories around:

| Factor                   | What Avra Provides                                                   |
| ------------------------ | -------------------------------------------------------------------- |
| **Propensity to buy**    | Which accounts are showing buying signals in their network behavior? |
| **Growth trajectory**    | Who's expanding and likely to need more?                             |
| **Competitive risk**     | Which accounts are connected to competitors' customers?              |
| **Relationship density** | Where do you have warm paths through existing customers?             |

## Daily Visit Optimization

**Territory**: South Region | **Rep**: Maria Santos | **Date**: Monday

| Rank | Account             | Score | Signal                                  |
| ---- | ------------------- | ----- | --------------------------------------- |
| 1    | TechFlow Ltda       | 94    | Growth spike + connected to 3 customers |
| 2    | Indústria Beta      | 89    | Expansion signals, no competitive risk  |
| 3    | Comércio Delta      | 82    | High fit, decision-maker changed        |
| 4    | Serviços Gama       | 71    | Stable, routine check-in                |
| 5    | Distribuidora Omega | 68    | Slight decline, monitor for churn       |

Rep works the list top-down. Highest-value opportunities get attention first.

## Route Optimization + Scoring

Combine visit prioritization with route efficiency:

1. Score all accounts in territory
2. Filter to top 20 by score
3. Optimize route through top 20 by geography
4. Result: Best accounts, efficient path

## Tracking Impact

Measure before/after:

* Meetings per closed deal
* Average deal size from field vs. inside
* Time from first visit to close
* Territory revenue per rep

The goal: Same headcount, more revenue from smarter targeting.

## Powered by two foundations

Field sales ranking composes both Avra foundations. The **Graph Foundation Model** identifies buying propensity through network-level patterns — expansion signals, competitive dynamics, and relationship density that firmographic filters miss. Your **Relational Foundation Model** learns what "ready to buy" looks like for your product and market, drawn from the patterns in your sales outcomes. The downstream model is trained on both, and feeds signal back into your RFM with every retrain.

### Customer Data Needed

| Data               | Purpose                                             |
| ------------------ | --------------------------------------------------- |
| **Sales outcomes** | Won/lost deals, deal size, time-to-close by account |
| **Account list**   | CNPJs of target accounts with territory assignments |
| **CRM activity**   | Visit history, engagement signals, pipeline stage   |

### Output Schema

| Field              | Description                                                                            |
| ------------------ | -------------------------------------------------------------------------------------- |
| `propensity_score` | Probability (0-1) of conversion within the scoring horizon                             |
| `growth_signal`    | Indicator of entity expansion or contraction trajectory                                |
| `network_density`  | Number of warm paths through existing customers                                        |
| `risk_factors`     | Key signals driving the ranking (sector health, competitive exposure, buying patterns) |

### Evaluation Metrics

* **Meetings-to-close ratio** — Primary metric: improvement in conversion rate from scored visits vs. unsorted visits.
* **Lift at top decile** — How much better the model's top-ranked accounts perform vs. random or firmographic ordering.
* **Revenue per rep** — Measures territory-level impact of score-based prioritization.


# Lead Scoring
Source: https://docs.avra.ai/solutions/growth/lead-scoring

Prioritize prospects by predicted value, not just firmographics.

## Beyond Firmographic Scoring

Traditional lead scoring: "Manufacturing company, 50-200 employees, São Paulo = 75 points"

The problem: Two companies matching that profile can have completely different outcomes. One becomes your best customer, the other churns in 3 months. Firmographics don't predict success.

## How It Works

You define the target outcome (conversion, high-LTV, retained after 12 months), we train a domain-specific model on top of our foundation. The result is a **probability score between 0 and 1** calibrated to your definition of success.

| You Provide                                       | Avra Delivers                               |
| ------------------------------------------------- | ------------------------------------------- |
| Historical outcomes (converted/not, high-LTV/not) | Trained model specific to your target       |
| Your definition of "good"                         | Probability score (0-1) for each entity     |
| Labeled seed data                                 | Calibrated predictions across your universe |

This same pattern applies across use cases—credit risk, churn, fraud. Define the target, we train the downstream model.

## Scoring Your Pipeline

| Your CRM Lead              | Avra Score Output              |
| -------------------------- | ------------------------------ |
| `company: Acme Corp`       | `conversion_probability: 0.87` |
| `cnpj: 12.345.678/0001-99` | `ltv_decile: 9`                |
| `source: webinar`          | `ltv_range: "R$ 80k-120k"`     |

## Operationalizing Scores

**Routing**

* Probability > 0.8: Route to senior AE, fast-track onboarding
* Probability 0.5-0.8: Standard sales process
* Probability \< 0.5: Nurture sequence, don't invest direct sales time

**Prioritization**

* Sort daily lead list by score
* SDRs work top-down, not first-in-first-out
* Result: Same team, more revenue

**Qualification**

* Replace subjective "gut feel" qualification
* Score provides objective baseline
* Sales adds context, doesn't start from zero

## Powered by two foundations

Lead scoring composes both Avra foundations. The **Graph Foundation Model** brings entity trajectories and network position from the broader economy — which entities are growing, which are showing stress, who counterparties cluster around. Your **Relational Foundation Model** brings the patterns specific to your business — what your converters look like, which signals predict your high-LTV customers. The downstream model is trained on both, and feeds signal back into your RFM with every retrain.

### Customer Data Needed

| Data                    | Purpose                                                                   |
| ----------------------- | ------------------------------------------------------------------------- |
| **Historical outcomes** | Converted/not, high-LTV/not, retained/churned — your definition of "good" |
| **CRM records**         | Lead source, engagement history, firmographic attributes                  |
| **Transaction history** | Revenue patterns, product adoption, usage signals                         |

### Output Schema

| Field                    | Description                                                                              |
| ------------------------ | ---------------------------------------------------------------------------------------- |
| `conversion_probability` | Probability (0-1) that the entity converts based on your definition                      |
| `ltv_decile`             | Predicted lifetime value bucket (1-10)                                                   |
| `risk_factors`           | Key signals driving the prediction (network growth, sector health, counterparty quality) |

### Evaluation Metrics

* **ROC-AUC** — Primary discrimination: how well the model separates converters from non-converters.
* **Lift at top deciles** — Operational metric: how much better the model's top-ranked leads perform vs. random selection.
* **Calibration** — Predicted probabilities should match observed conversion rates across score bands.

## Combining with Your Data

The best results come from combining Avra scores with your first-party signals:

| Input                | Source                 |
| -------------------- | ---------------------- |
| `avra_lead_score`    | Avra API               |
| `product_engagement` | Your product analytics |
| `recency`            | Your CRM               |
| `source_quality`     | Your marketing data    |

Use our embeddings as features in your model, or use our score directly. Either way, you're adding context your CRM can't see.


# Paid Media Optimization
Source: https://docs.avra.ai/solutions/growth/paid-media

Enrich your ad platform data with entity intelligence for smarter targeting and bidding.

## The Problem with Platform-Native Targeting

Ad platforms know clicks, impressions, and on-site behavior. They don't know:

* Is this CNPJ a growing company or about to go bankrupt?
* What's their actual lifetime value potential?
* Are they connected to your best customers' networks?

You're bidding blind on entity quality.

## Enrich Your Pixel Data

Match your pixel events to Avra's entity intelligence:

| Your Pixel Event     | Avra Enrichment               |
| -------------------- | ----------------------------- |
| `visitor_id: abc123` | `cnpj: 12.345.678/0001-99`    |
| `event: form_submit` | `lead_score: 847`             |
| `page: /pricing`     | `ltv_forecast: R$ 45,000`     |
|                      | `segment: "high-growth-tech"` |
|                      | `churn_risk: 0.12`            |

Now your conversion events carry entity-level context that platforms can't see.

## Use Cases

**Smarter Lookalikes**

* Seed with CNPJs of your highest-LTV customers (not just converters)
* Platform finds users similar to your *best* customers, not just any customers
* Result: Higher-quality traffic from day one

**Value-Based Bidding**

* Pass LTV forecasts as conversion values to Google/Meta
* Algorithms optimize for revenue, not just conversions
* Bid more for entities predicted to be worth 10x

**Suppression & Exclusion**

* Exclude high churn-risk entities from acquisition campaigns
* Suppress low-score leads from retargeting
* Stop wasting spend on entities unlikely to convert or retain

**Retargeting Prioritization**

* Rank your retargeting pool by lead score
* Show premium creative to high-value prospects
* Reduce frequency for low-score visitors

## Example: LTV-Optimized Meta Campaign

1. Export your customer list with Avra LTV forecasts
2. Upload as custom audience with value column
3. Create value-based lookalike (Meta optimizes for predicted LTV, not just match)
4. Set campaign to optimize for "Value" not "Conversions"

The result: Meta's algorithm learns what high-LTV entities look like and finds more of them.

## Powered by two foundations

Paid media optimization enriches ad-platform data with signals invisible to pixel tracking. The **Graph Foundation Model** brings entity growth trajectories, network health, and sector dynamics. Your **Relational Foundation Model** brings the definition of a high-value customer specific to your business. The downstream model trained on both calibrates predictions to your LTV definition — and every training run feeds signal back into your RFM.

### Customer Data Needed

| Data                       | Purpose                                                                       |
| -------------------------- | ----------------------------------------------------------------------------- |
| **Customer list with LTV** | Actual or estimated lifetime value per customer for value-based optimization  |
| **Conversion events**      | Which leads became customers, and when                                        |
| **Pixel/CRM match keys**   | CNPJ or identifiers that allow matching ad platform visitors to Avra entities |

### Output Schema

| Field          | Description                                         |
| -------------- | --------------------------------------------------- |
| `lead_score`   | Predicted conversion probability (0-1)              |
| `ltv_forecast` | Estimated lifetime value in BRL                     |
| `segment`      | Behavioral cluster label (e.g., "high-growth-tech") |
| `churn_risk`   | Predicted probability of early churn                |

### Evaluation Metrics

* **Incremental ROAS** — Primary metric: return on ad spend improvement vs. platform-native targeting alone.
* **Cost per qualified lead** — Measures targeting efficiency when using Avra scores for bid adjustments.
* **Lift in LTV** — Compares average LTV of customers acquired with vs. without Avra enrichment.


# Overview
Source: https://docs.avra.ai/solutions/overview

Two pre-trained foundations, composed into any relational prediction task your business can label.

## One platform, any relational prediction task

Avra is not a single-purpose product. The Graph Foundation Model and your Relational Foundation Model produce representations that transfer to any downstream task where entity context and network structure improve predictions.

Credit risk, fraud detection, and growth optimization are the most common starting points. The same platform powers churn prediction, supplier risk monitoring, portfolio segmentation, entity resolution, and any custom classification or regression target you can label on entities in the graph.

<Info>
  If you can define a target outcome on entities in our graph, we can train a downstream model for it — and that training run will improve your RFM.
</Info>

## How it works

Every use case follows the same pattern:

<Steps>
  <Step title="Define the target">
    What does "good" or "bad" mean for your business — converted vs. not, defaulted vs. not, churned vs. retained, fraud vs. legitimate.
  </Step>

  <Step title="Train the downstream model">
    Avra trains a task-specific model on top of the GFM and your RFM. Signal from this training run is fed back into your RFM, refining its representation of your business.
  </Step>

  <Step title="Deploy and govern">
    The downstream model serves predictions through real-time APIs or batch jobs. You control versions, aliases, and rollback.
  </Step>
</Steps>

The pre-trained foundations do the heavy lifting. Your labels shape the model. Your RFM compounds.

## Common starting points

<CardGroup>
  <Card title="Credit Intelligence" href="/solutions/credit-score/overview-and-methodology" icon="chart-line">
    Multi-horizon probability of default, credit scoring, and portfolio monitoring powered by network-aware risk signals.
  </Card>

  <Card title="Fraud Detection" href="/solutions/fraud/overview" icon="shield-halved">
    Network-based fraud intelligence that catches shell entities, collusion rings, and bust-out schemes invisible to rule engines.
  </Card>

  <Card title="Growth & Sales" href="/solutions/growth/lead-scoring" icon="rocket">
    Lead scoring, paid media optimization, and field sales ranking driven by entity trajectories and network position.
  </Card>

  <Card title="Build Your Own Models" href="/solutions/embeddings/overview" icon="cubes">
    Use Avra's adaptive embeddings as features in your own ML models for full control over architecture and objectives.
  </Card>
</CardGroup>

## Beyond these use cases

The use cases above are where most customers start — they do not define the boundaries of the platform. Avra's foundations apply to any task where entity context and network structure improve predictions:

* **Churn Prediction** — identify at-risk customers through network deterioration signals
* **Supplier Risk** — monitor supply chain health through multi-hop relationship analysis
* **Entity Resolution** — disambiguate and link entities across fragmented data sources
* **Portfolio Segmentation** — cluster entities by behavioral similarity, not just firmographics
* **Custom Classification** — any binary or multi-class outcome you can label on entities in the graph

Contact your Avra representative to scope a custom downstream model for your task.


# Our Approach
Source: https://docs.avra.ai/why-avra/foundation-models

Two relational intelligence layers — one pre-trained on the economy, one adapted to your business — composed into every decision.

## A foundation model reflects the universe it was trained on

GPT understands English because it was trained on English. It grasps cultural references, legal structures, and business norms because that is what it learned from.

**Avra understands relationships** because that is exactly what we built it for. Not text, not images — the network of entities, their connections, and how both evolve over time.

## What a foundation model is

A foundation model is pre-trained once on broad data to learn general representations that transfer to many downstream tasks. Instead of building a separate model for every problem, you train one foundation and adapt it.

We do this twice.

<CardGroup>
  <Card title="Graph Foundation Model" icon="globe">
    Pre-trained on the relational economy. Companies, individuals, assets, and the events that connect them — modeled as a temporal graph the model learns to navigate before it sees a single label.
  </Card>

  <Card title="Relational Foundation Model" icon="circle-nodes">
    A customer-specific relational representation layer, pre-trained on your schema and temporal business data. Yours alone, optionally deployed inside your environment, then composed with the GFM for downstream prediction tasks.
  </Card>
</CardGroup>

## Why graphs

Most AI models treat data as rows in a spreadsheet — each entity independent, defined by its own attributes. Entities do not exist in isolation.

**Entities exist in networks.** Companies have suppliers, customers, partners, competitors. Individuals have employers, co-directors, family connections. Assets flow between accounts. Events cascade through ownership chains.

An entity's risk profile changes dramatically based on its network position. A clean-looking company becomes high-risk when its main supplier has active litigation from a counterparty in multiple fraud cases. Traditional models cannot see this. Graph models can.

### Graph neural networks

Graph neural networks are architectures designed to learn from connected data. Instead of analyzing each entity in isolation, they propagate signal through relationships — from each entity to its neighbors, to its neighbors' neighbors, and so on. Every entity is understood not just by its own data, but by its position in the network.

This is how we built both the GFM and the RFM.

## Why two foundations, not one

A generic foundation alone misses your business. Your hierarchies, your patterns, your definitions of success are invisible to a model trained on public data.

A customer-specific foundation alone misses the world. A model trained only on your data has no view of counterparties, sector dynamics, or events that determine outcomes.

Avra trains both. The GFM brings the relational economy. The RFM brings your business. Downstream models inherit from both, and contribute back.

## Today's scope

The GFM is currently specialized for Brazil. It encodes local entity taxonomies, corporate structures, and judicial and regulatory dynamics with a depth no generic model can match.

The same architecture extends to new regions — each becoming its own pre-trained GFM specialization on the relational substrate of its own economy.

## Avra is a frontier lab

We are not building one product. We are building the foundation layer for relational intelligence — the model architecture, the training infrastructure, the temporal graph, and the deployment surface that make every downstream prediction stronger.

That research program is active. New foundation models, new representation techniques, new ways to compose them into decisions — shipped to production, not papers in a drawer.


# The Graph Advantage
Source: https://docs.avra.ai/why-avra/how-were-different

Why relationships are more predictive than records.

## From records to relationships

Traditional intelligence treats entities as rows in a database. Each company, each individual — isolated, defined only by its own history.

The economy is not a spreadsheet. Companies are nodes in a network, and the network is the signal. A company is defined by who it does business with, who owns it, who it employs, who sues it, and how all of that changes over time. A clean-looking company doing business with a fraud ring is not clean — it is a risk the spreadsheet cannot see.

The Graph Foundation Model sees those connections. It treats relationships as structure, not enrichment.

## Two foundations, not one

Generic foundation models give you general intelligence and no view of your business. Internal models give you a view of your business and no view of the world around it.

Avra pre-trains two foundations and composes them.

* The **Graph Foundation Model** brings the relational economy — counterparties, supply chains, judicial events, sector dynamics.
* Your **Relational Foundation Model** brings your business — your customers, accounts, transactions, and the connections between them.
* **Downstream models** inherit from both, and feed signal back into the RFM with every training run.

You do not pick between general and specific. You get both, composed.

## Seeing the invisible

Traditional systems require history to make predictions. No history, no score.

In a graph, no entity is truly isolated. Even a brand-new company has context — the track record of its founders, the health of its sector, the stability of its region, the patterns of similar entities. We infer from those connections.

This is how we score the unscorable.

## A flywheel, not a snapshot

A frozen foundation is a one-time gift. A foundation that learns from every downstream task is an asset that appreciates.

Every model you train on Avra generates signal about what predicted the outcomes you care about. That signal flows back into your RFM. The next model starts from a stronger base. The next one after that, stronger still.

The longer you run on Avra, the larger the gap between what you can predict and what anyone else can.

## One foundation, every decision

The same understanding that detects fraud also assesses credit risk and prioritizes leads.

<CardGroup>
  <Card title="Acquire" icon="user-plus">
    Lead Scoring, Paid Media Optimization, Field Sales Ranking
  </Card>

  <Card title="Onboard" icon="clipboard-check">
    Fraud Prevention, Risk Assessment, Entity Verification
  </Card>

  <Card title="Manage" icon="chart-line">
    Credit Decisions, Portfolio Monitoring, Relationship Intelligence
  </Card>

  <Card title="Retain" icon="arrows-spin">
    Churn Prediction, Lifetime Value, Custom Prediction Tasks
  </Card>
</CardGroup>

Different questions, same foundations. When you solve one problem with Avra, the next is already half-solved.


# The Problem
Source: https://docs.avra.ai/why-avra/the-challenge

Why most entities remain invisible to traditional risk systems — and why that matters for your decisions.

> What separates an entity that will thrive from one that will fail in six months?

It is not what is on the application form. **It is context.**

Two entities can look identical on paper — same industry, same size, same age. One thrives; the other fails. Traditional systems cannot tell them apart because they see rows of data, not the relationships that actually drive outcomes.

## The scale of the problem

<CardGroup>
  <Card title="1B+ entities" icon="globe">
    Companies, individuals, and assets — connected through ownership, transactions, and legal relationships into a single relational economy
  </Card>

  <Card title="80%+" icon="eye-slash">
    Have thin or no traditional data trails — invisible to legacy systems
  </Card>

  <Card title="Trillions" icon="money-bill">
    In decision value — fraud losses, missed credit, misallocated growth spend
  </Card>
</CardGroup>

These entities are not necessarily bad risks. The problem is that traditional systems cannot distinguish good from bad without extensive history — so they reject everyone without history, or accept blindly and absorb the losses.

## Why traditional approaches fail

### Bureaus

Bureau scores rely on payment history and registered debts. For most thin-file entities that data does not exist in meaningful depth. They see snapshots. They miss the trajectory.

### Internal data science teams

Your team has rich customer data — transactions, payments, behavior. They lack market context. Is this entity's pattern normal for its segment? Are its counterparties stable? Is its network showing stress? Internal models see your relationship. They miss the ecosystem.

### Generic AI platforms

Sophisticated technology built for general purposes. They do not encode the entity taxonomies, jurisdictional legal structures, or sector dynamics of the markets you actually operate in. Generic models see statistical patterns. They miss structural context.

## The real question

The challenge is not "how do we get more data?" — that has been tried for decades.

The real question is: **how do we understand entity relationships the way an experienced analyst does, but at scale?**

A seasoned risk officer does not just look at an entity's attributes. They consider its counterparties, the stability of those relationships, what is happening in its sector and region, and how similar entities in its network have performed. This is **relational intelligence**. Until now, it could not be automated.