{
  "product": "BeryX",
  "vendor": "BeryxTech",
  "locale": "en",
  "updated": "2026-10-12",
  "source": "https://beryx.lbostuff.tech/en/rfp",
  "capabilities": [
    {
      "id": "profiling",
      "analyst_criterion": "Profiling",
      "name": "Profiling",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "Automatic discovery and profiling of every table across 15+ source types — warehouses, operational databases, SaaS, files, documents and streaming (Kafka and Pub/Sub, not yet installed in the SaaS). Counts, nulls, distinct values, statistics, distributions and bounded samples, with incremental profiling on large tables.",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: profiling",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#profiling"
        },
        {
          "label": "Connector guide (source list)",
          "url": "https://beryx.lbostuff.tech/en/docs/conectores#resumo"
        },
        {
          "label": "Methods: deep profiling and sampling",
          "url": "https://beryx.lbostuff.tech/en/docs/metodos#profiling-profundo"
        }
      ]
    },
    {
      "id": "monitoring",
      "analyst_criterion": "Monitoring / observability",
      "name": "Monitoring",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "Automatic freshness, volume and schema monitors on every table in the connection (up to 500 per connection), from catalog metadata and with no setup; drift and anomalies; rules engine; per-dataset SLOs. Alerts via email, Slack, Teams and webhook, with on-call rotations and a scope per channel (domains, connections, datasets, issue types).",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: monitoring",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#monitorização"
        },
        {
          "label": "Methods: automatic monitors (metadata per source and per-scan cap)",
          "url": "https://beryx.lbostuff.tech/en/docs/metodos#monitores-automáticos"
        },
        {
          "label": "Streaming rules (Kafka, not yet installed in the SaaS)",
          "url": "https://beryx.lbostuff.tech/en/docs/conectores#apache-kafka-tópicos-como-datasets"
        },
        {
          "label": "Methods: anomalies, drift and monitors",
          "url": "https://beryx.lbostuff.tech/en/docs/metodos#anomalias"
        }
      ]
    },
    {
      "id": "parsing",
      "analyst_criterion": "Parsing / standardization",
      "name": "Parsing and standardization",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "Automatically detected semantic types (email, tax ID, IBAN, postcode, phone, dates, amounts, names, addresses) with suggested validation rules. Phone numbers, postcodes, tax IDs, IBANs and dates stored in mixed formats are brought to a canonical form. Composite fields are split by PT, ES and EN locale rules: addresses (street, number, floor, postcode, locality, country), names (title, given name, surnames), phone numbers with country codes, tax ID and name in the same column, free-text dates and amounts with a currency. Each column shows the success rate on the sample and the formats that fail. The standardization is proposed as read-only SQL in the source's dialect and as PySpark, and applied by your process, including through a pull request. We never write to the sources.",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: parsing and standardization",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#parsing-e-normalização"
        },
        {
          "label": "Capabilities: cleansing and remediation by pull request",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#limpeza-e-remediação"
        },
        {
          "label": "ODCS contracts in CI",
          "url": "https://beryx.lbostuff.tech/en/docs/ci#1-exportar-o-contrato"
        }
      ]
    },
    {
      "id": "matching",
      "analyst_criterion": "Matching / linking / merging",
      "name": "Matching and deduplication",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "Exact and fuzzy duplicates within each dataset, and matching between two datasets, including from different sources such as the CRM and the ERP. Matching rules are configured per field: comparator (exact, normalized, Jaro–Winkler, word-based, numeric with a tolerance or date with a window), weight and minimum similarity, with blocking and one threshold for a match and another for review. Clusters across the two datasets are reviewed in the interface (merge, ignore or reset), and the decision stays in BeryX, in the audit trail, and holds in later runs. Per-field survivorship rules (priority source, most recent, most complete or most frequent) give a proposed consolidated record, with the origin of each field, as read-only SQL and PySpark that can go through a pull request for the customer's process to approve. On a labelled synthetic benchmark, the suggested rules reach precision 1.0 and recall 0.85 on 10,000 rows. We never write to the sources.",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: matching and deduplication",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#matching-e-deduplicação"
        },
        {
          "label": "Methods: exact and fuzzy duplicates",
          "url": "https://beryx.lbostuff.tech/en/docs/metodos#duplicados"
        },
        {
          "label": "Methods: cross-dataset matching",
          "url": "https://beryx.lbostuff.tech/en/docs/metodos#correspondência-entre-datasets"
        },
        {
          "label": "Methods: configurable rules, clusters and benchmark",
          "url": "https://beryx.lbostuff.tech/en/docs/metodos#regras-configuráveis-e-clusters-cartão-387"
        }
      ]
    },
    {
      "id": "cleansing",
      "analyst_criterion": "Cleansing",
      "name": "Cleansing",
      "status": "coberto-humano",
      "status_label": "Covered (human in the loop)",
      "summary": "Cleansing with a human in the loop: we propose the fix — generated SQL and PySpark, with estimated savings and risk analysis —, open a pull request in the customer's repository, and a person approves the application, in a governed flow (proposed, accepted, applied, verified on the next scan). We never write to sources without that approval.",
      "missing": null,
      "positioning": "We propose SQL/PySpark and a PR in your repository; we never write to the source. Asking for write credentials would be your security team's first objection.",
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: cleansing and remediation",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#limpeza-e-remediação"
        },
        {
          "label": "Mechanical read-only access",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#acesso-read-only-mecânico"
        },
        {
          "label": "Comparison matrix: fixing",
          "url": "https://beryx.lbostuff.tech/en/comparar#matriz"
        }
      ]
    },
    {
      "id": "enrichment",
      "analyst_criterion": "Enrichment",
      "name": "Enrichment",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "We propose values from reference sources, each with the source, the lookup date and the confidence: the locality, municipality and district from the Portuguese postcode (GeoAPI.pt, with data from the Portuguese postal service and statistics office), the locality from the Spanish postcode (OpenStreetMap's Nominatim, which receives only the postcode), the coordinates from the address (in your own Nominatim instance, the only one that receives addresses), a company's registered name and address from the tax ID of a legal person (the European Commission's VIES), and the ISO country and currency codes (local lists). Each proposal gives the coverage on the sample and comes as SQL in the source's dialect and as PySpark: a read-only count and a proposed UPDATE, or a SELECT with the proposed values, which your process applies through a pull request or SQL after approving the suggestion. Each external provider receives only the field to enrich, after an administrator allows it in the workspace; your Nominatim instance is allowed with its URL and a personal data confirmation of its own. We never write to the sources.",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: enrichment",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#enriquecimento"
        },
        {
          "label": "Security: what leaves for each reference provider",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#enriquecimento-proposto-o-que-sai-para-cada-fornecedor"
        },
        {
          "label": "Capabilities: cleansing and remediation by pull request",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#limpeza-e-remediação"
        }
      ]
    },
    {
      "id": "metadata",
      "analyst_criterion": "Metadata management",
      "name": "Metadata management",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "Automatic catalog with domains; lineage from foreign keys, column-level view SQL, the dbt manifest and OpenLineage; per-column sensitivity and a human-approved README per dataset. Native business glossary: terms with a definition, synonyms, owner, domain and status (draft, approved or deprecated), linked to columns and datasets. Links suggested from the name, synonyms, semantic type and dbt descriptions always start as proposals, and only a person approves them. Each dataset can have an owner (inherited from the domain when empty) and a steward, and tags per dataset and per column, free or from a controlled workspace list. Changes to owners, stewards and tags, manually set sensitivity, term-to-column links and term edits are recorded in the history (what, who, when, before and after), with a diff between two dates. The history starts with the release that introduced it: earlier changes were not converted, and term creation, automatic suggestions and what datavault.yaml applies are not recorded yet. The data dictionary exports per dataset, domain or workspace as CSV, JSON and Markdown, with descriptions, types, sensitivity, terms, tags, owner, steward, rules and SLA. It also exports as files to load into OpenMetadata (one create-table request per dataset; owner, SLA and rules go in a separate section because the request does not accept them) and DataHub (MCPs for datahub ingest). It is a file for your process to load: we do not send it. Cross-cutting search finds datasets, columns, terms, tags and owners and respects restricted domains. Owners, tags, the history, the dictionary and search are used through the API: they do not have an app page yet. Quality verdicts are published to OpenMetadata, DataHub and Collibra (Import API v2, validated with a simulated transport; validation on a customer tenant pending).",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: metadata management",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#gestão-de-metadados"
        },
        {
          "label": "OpenLineage (emit and consume)",
          "url": "https://beryx.lbostuff.tech/en/docs/openlineage#consumir-o-lineage-do-cliente-no-grafo-do-beryx-cartão-130"
        },
        {
          "label": "External catalog: OpenMetadata and DataHub",
          "url": "https://beryx.lbostuff.tech/en/docs/catalogo-externo#o-que-aparece-no-openmetadata"
        },
        {
          "label": "External catalog: Collibra (Import API v2, validated with a simulated transport; validation on a customer tenant pending)",
          "url": "https://beryx.lbostuff.tech/en/docs/catalogo-externo#collibra-catsync-v3"
        }
      ]
    },
    {
      "id": "orchestration",
      "analyst_criterion": "Workflow / orchestration",
      "name": "Workflow and orchestration",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "dbt Cloud webhook and an Airflow package with a quality gate; rules gate and data-diff in CI; MCP server for agents; workspace configuration as code; issue workflow with owners, escalations and schedules. Read-only validation at the point of entry: the integrator or the pipeline sends up to 5,000 records per API request before writing them and gets each record's verdict from the rules BeryX already monitors on the dataset (required fields, patterns, ranges, NIF, NISS and IBAN with check digits, ISO and workspace reference lists), the reason code of each failure and the batch verdict. Nothing is stored or sent to an LLM and the source is not read: rejecting or quarantining stays on the customer's side. Rules that measure the whole dataset (uniqueness, freshness, volume) come back marked as not applicable.",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: orchestration",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#orquestração-e-fluxo-de-trabalho"
        },
        {
          "label": "dbt Cloud and Airflow",
          "url": "https://beryx.lbostuff.tech/en/docs/orquestradores#2-airflow--pacote-beryx-airflow"
        },
        {
          "label": "Rules gate in CI",
          "url": "https://beryx.lbostuff.tech/en/docs/ci#gate-de-regras-em-ci-cigate-radar-vaga-3"
        },
        {
          "label": "MCP server",
          "url": "https://beryx.lbostuff.tech/en/docs/mcp#tools-disponíveis"
        },
        {
          "label": "Developer portal (API, including POST /datasets/{id}/validate)",
          "url": "https://beryx.lbostuff.tech/en/developers"
        }
      ]
    },
    {
      "id": "business_ux",
      "analyst_criterion": "Business-user experience",
      "name": "Business-user experience",
      "status": "coberto",
      "status_label": "Covered",
      "summary": "Reports per persona (engineering, management, executive) with impact in euros, as PDF, schedulable and shareable; natural-language assistant; live first scan; interface in Portuguese, English and Spanish.",
      "missing": null,
      "positioning": null,
      "planned": null,
      "evidence": [
        {
          "label": "Capabilities: business users",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#experiência-para-utilizadores-de-negócio"
        },
        {
          "label": "Product page",
          "url": "https://beryx.lbostuff.tech/en"
        },
        {
          "label": "Weekly changelog",
          "url": "https://beryx.lbostuff.tech/en/changelog"
        }
      ]
    }
  ],
  "security": [
    {
      "id": "read_only",
      "question": "Does BeryX write to our data sources?",
      "answer": "No. The guarantee is in the code, not only in permissions: the connectors' HTTP client refuses any write verb before it reaches the network, no connector may expose a write method, and PostgreSQL sessions open in read-only mode.",
      "evidence": [
        {
          "label": "Mechanical read-only access",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#acesso-read-only-mecânico"
        }
      ]
    },
    {
      "id": "credentials",
      "question": "How are our source credentials stored?",
      "answer": "Encrypted with Fernet before being stored, never returned by the API nor written to logs. Keys rotate without downtime: several active keys, the first encrypts and all decrypt, and a script re-encrypts everything with the new key.",
      "evidence": [
        {
          "label": "Encrypted credentials and key rotation",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#credenciais-cifradas-e-rotação-de-chaves"
        }
      ]
    },
    {
      "id": "ssrf",
      "question": "Could a malicious connection URL be used to reach your internal network (SSRF)?",
      "answer": "No. We only accept https, refuse hosts that resolve to internal addresses and pin the validated IP for the connection (DNS pinning), repeating the check on every redirect — which also closes DNS rebinding.",
      "evidence": [
        {
          "label": "Anti-SSRF protection with DNS pinning",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#proteção-anti-ssrf-com-pinning-de-dns"
        }
      ]
    },
    {
      "id": "gdpr",
      "question": "Can we export and delete our data without asking support?",
      "answer": "Yes. Administrators export the workspace data and delete it in cascade, and each user deletes their own account — all in the application and the API.",
      "evidence": [
        {
          "label": "GDPR: export and erasure",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#rgpd-exportação-e-eliminação-self-service"
        },
        {
          "label": "Privacy policy",
          "url": "https://beryx.lbostuff.tech/en/privacidade"
        }
      ]
    },
    {
      "id": "ai_label",
      "question": "How do you identify AI-generated content?",
      "answer": "All content produced with a model carries a footer identifying it, with the model and provider that actually answered, under Art. 50 of Regulation (EU) 2024/1689. We also export the Art. 10 evidence dossier.",
      "evidence": [
        {
          "label": "AI content labelling",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#rotulagem-de-conteúdo-de-ia-art-50º-do-ai-act"
        }
      ]
    },
    {
      "id": "byok",
      "question": "Can we use our own key or Claude in our own cloud account?",
      "answer": "Yes. Your own Anthropic key per workspace, an AI policy (including «AI off») and, on the Enterprise plan, Claude in your AWS account (Bedrock, EU regions) or Google Cloud (Vertex AI, European regions), with BeryxTech storing no secrets for that route.",
      "evidence": [
        {
          "label": "Your models",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#os-teus-modelos-chave-própria-amazon-bedrock-e-vertex-ai"
        },
        {
          "label": "Amazon Bedrock onboarding",
          "url": "https://beryx.lbostuff.tech/en/docs/byok-bedrock#como-funciona"
        },
        {
          "label": "Vertex AI onboarding",
          "url": "https://beryx.lbostuff.tech/en/docs/byok-vertex#como-funciona"
        }
      ]
    },
    {
      "id": "anonymization",
      "question": "Which of our data reaches a language model?",
      "answer": "By default only Anthropic receives customer data, in bounded samples. Samples can be anonymized before leaving (tax IDs, social security numbers, IBAN, phone numbers, names), and an alternative provider never receives raw samples.",
      "evidence": [
        {
          "label": "Anonymization before the LLM",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#anonimização-antes-do-llm"
        }
      ]
    },
    {
      "id": "certifications",
      "question": "Are you ISO 27001 certified or do you have a SOC 2 report?",
      "answer": "Not yet. Both are in progress, building on the controls described on this page. Until then, we answer with the technical evidence for each control — not with badges we don't have.",
      "evidence": [
        {
          "label": "Certifications: ISO 27001 and SOC 2",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#certificações-iso-27001-e-soc-2"
        },
        {
          "label": "Audit log",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#registo-de-auditoria"
        }
      ]
    },
    {
      "id": "identity",
      "question": "Do you support SSO, MFA and SCIM provisioning?",
      "answer": "OIDC single sign-on with the customer's identity provider (Entra ID, Google Workspace, Keycloak and others), with per-workspace roles, teams and an audit log exportable to CSV. Password accounts have TOTP MFA (authenticator app) with single-use recovery codes: it is mandatory for organisation admins and BeryxTech staff, and the workspace admin can require it for every member. SSO accounts use your identity provider's MFA. BeryxTech support only enters a workspace with the consent of a customer admin, read-only and for 72 hours at most, and every access is recorded in the audit log. We do not offer SCIM provisioning yet.",
      "evidence": [
        {
          "label": "Access control and MFA",
          "url": "https://beryx.lbostuff.tech/en/seguranca#access"
        },
        {
          "label": "Audit log",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#registo-de-auditoria"
        }
      ]
    },
    {
      "id": "sla",
      "question": "Do you have an availability and support SLA?",
      "answer": "Not in a contract yet. The SLA only goes into a contract after a quarter of measured availability and a support policy by severity, still being defined. Today: daily backups with point-in-time recovery (7 days), checked on every deploy, and the product keeps working in offline mode if AI fails. The 7, 30 and 90-day targets in our vulnerability policy are for fixing security flaws, not a support SLA.",
      "evidence": [
        {
          "label": "Backups and recovery",
          "url": "https://beryx.lbostuff.tech/en/seguranca#backups"
        }
      ]
    },
    {
      "id": "accessibility",
      "question": "Do you meet WCAG 2.2 AA and EN 301 549? Do you have a VPAT or ACR?",
      "answer": "Partially, and the ACR is available. The Accessibility Conformance Report (based on VPAT® 2.5) assesses the 55 WCAG 2.2 level A and AA criteria in the app and on the website, with the EN 301 549 clause for each, and states what is still missing and where. Accessibility linting, axe and token contrast checks run in CI. It is a self-assessment, not an external audit.",
      "evidence": [
        {
          "label": "WCAG 2.2 ACR: summary by status",
          "url": "https://beryx.lbostuff.tech/en/docs/acessibilidade#resumo"
        },
        {
          "label": "ACR: the 55 criteria",
          "url": "https://beryx.lbostuff.tech/en/docs/acessibilidade#critérios-wcag-22-a-e-aa"
        },
        {
          "label": "ACR: known gaps and plan",
          "url": "https://beryx.lbostuff.tech/en/docs/acessibilidade#lacunas-conhecidas-e-plano"
        }
      ]
    },
    {
      "id": "regulatory_dossier",
      "question": "Can you show, per critical data element, that the data quality requirements of BCBS 239 or Solvency II are under control?",
      "answer": "Partly, and we say where not. Any dataset or column can be marked as a critical data element for BCBS 239, Solvency II or another regulation, with an owner and a reference. The regulatory dossier shows, per BCBS 239 principle (3 to 6) or per paragraph of Article 19 of Delegated Regulation (EU) 2015/35, the quality controls on each element, the latest result of each rule, open issues, the SLA, lineage and the data contract, and it points out the gaps. It exports to CSV and PDF and can be shared by link. Accuracy and integrity still show as a gap on every element, because no BeryX rule type measures them today. The dossier has no user interface yet: for now it is used through the API and the reports. The dossier is evidence for the supervisor, not a statement of compliance.",
      "evidence": [
        {
          "label": "Capabilities: critical data elements and regulatory dossier",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#elementos-de-dados-críticos-e-dossiê-regulatório"
        },
        {
          "label": "Developer portal (GET /cde/dossier)",
          "url": "https://beryx.lbostuff.tech/en/developers"
        }
      ]
    }
  ],
  "not_done": [
    {
      "id": "destructive_remediation",
      "title": "Destructive remediation in sources",
      "why": "We propose the fix and open the pull request; the customer applies it. Writing to sources would require write credentials — the number-one objection of European security teams.",
      "evidence": [
        {
          "label": "What we don't do, and why",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#o-que-não-fazemos-e-porquê"
        },
        {
          "label": "Cleansing and remediation",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#limpeza-e-remediação"
        }
      ]
    },
    {
      "id": "mdm_golden_record",
      "title": "MDM and golden record with write-back",
      "why": "We detect duplicates and propose the consolidation, but we do not maintain a master record nor write the «winning» version back to the sources. We complement the MDM tool you already have.",
      "evidence": [
        {
          "label": "What we don't do, and why",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#o-que-não-fazemos-e-porquê"
        },
        {
          "label": "Matching and deduplication",
          "url": "https://beryx.lbostuff.tech/en/docs/capacidades#matching-e-deduplicação"
        }
      ]
    },
    {
      "id": "multimodal_images",
      "title": "Multimodal image analysis",
      "why": "We read documents through their text layer. Images are not processed, and a scanned PDF without text is flagged as needing OCR instead of being sent to a vision model.",
      "evidence": [
        {
          "label": "What we don't do, and why",
          "url": "https://beryx.lbostuff.tech/en/docs/seguranca#o-que-não-fazemos-e-porquê"
        }
      ]
    }
  ]
}