Capability status
Public claims use four states so delivered behavior, production acceptance, environment dependencies and planned work are not collapsed into one marketing label.
40 capabilities
analytics-governed
Reports can pin exact DatasetVersions, create immutable ReportVersions and retain permission, RLS, filter and run context.
Result retention and export are bounded, and access remains subject to underlying resource permissions.
analytics-postgresql-boundary
The current governed Dataset-aware Analytics compiler targets PostgreSQL.
Other sources require an accepted materialization or dialect-adapter path.
assurance-read-model
Advanexus Assurance builds a permission-aware, read-optimized operational story from supported canonical evidence sources.
Source modules remain canonical owners, and projection coverage varies by event and module.
assurance-user360-not-score
User 360 presents a drillable evidence footprint within the viewer's allowed scope.
It is not an employee productivity, performance or automated HR score.
assurance-visible-gaps
Assurance distinguishes known, verified, unverified, legacy and unavailable evidence rather than inventing missing history.
A visible event or generic renderer does not prove complete semantic coverage.
evidence-package-checksum
Authorized Evidence Packages can include scoped HTML, PDF, CSV, JSON, NDJSON and ZIP output with manifest and checksum metadata.
Generation, download, expiry and retained size remain bounded and permission-checked.
evidence-package-not-signed
Evidence Packages are checksum-verifiable technical exports, not automatically digitally signed or legally conclusive records.
KMS signing, WORM or object lock, legal hold and regulatory certification require separate controls.
source-aware-integrity
Integrity status reflects the verification strength available from each supported canonical source.
A successful Integrity Run can still contain unverified, pending or legacy records.
pricing-operational-scope
Public prices are non-binding planning estimates; final Advanexus scope is shaped by accepted operational responsibility, systems, controls, workloads and evidence obligations.
The executed proposal and Order Form remain authoritative for price, infrastructure, support, third-party costs, acceptance and exclusions.
connector-capabilities-vary
Connector capabilities are resolved per source, driver and deployment.
Discovery, preview, query, transfer, write, delete, quality and analytics paths are not identical across connectors.
connector-families
Seventeen connector contracts across eight capability families cover relational, warehouse, key-value, document, wide-column, search, graph and enterprise SaaS systems.
MariaDB uses the MySQL-compatible family, and named support never implies feature parity.
source-capability-contract
Sources provide project-scoped connection identity and expose only capability-supported operations.
Runtime availability depends on credentials, network, vendor libraries and deployment policy.
data-quality-assertions
Data Quality turns explicit source-oriented expectations into SQL assertions, QualityRuns and failure findings.
Custom SQL requires least-privilege read roles and careful review of returned fields.
data-quality-boundaries
Data Quality rules are currently mutable source contracts rather than immutable DatasetVersion-pinned rules.
Suite execution, automated repair and a complete finding-remediation workflow are not current capabilities.
dataset-version-contract
Dataset gives a data definition stable identity, immutable DatasetVersions, lineage and semantic metadata.
Downstream impact analysis is bounded to recorded contracts and relationships.
dataset-version-not-row-snapshot
A virtual DatasetVersion preserves the query and schema contract, not necessarily a frozen copy of live source rows.
Exact historical rows require a retained result artifact or an explicit materialized snapshot contract.
intelligence-actions-controlled
Models may propose; deterministic services validate; policy and people authorize registered state-changing actions.
Confirmation, approval and evidence behavior depend on the exact registered action contract.
intelligence-bounded
Advanexus Intelligence is a stateful, permission-aware orchestration layer over registered platform skills and tools.
It is not an unrestricted autonomous agent or a parallel authorization system.
intelligence-no-screen-scraping
Intelligence uses registered page, object and allow-listed context rather than scraping an arbitrary screen or result grid.
It has no general web-search, browser-automation or automatic documentation-RAG capability.
no-compliance-certification
This site does not claim regulatory certification or legal compliance badges without formally approved evidence.
Product controls can support a governed process but do not by themselves certify an organization.
pipeline-executors
Implemented Pipeline executors persist query, transfer, delete, Data Quality and Master run outcomes.
Job definitions are mutable, and the public catalog must distinguish active executors from unsupported historical types.
pipeline-schedule-boundary
Pipeline Schedule currently stores interval or cron intent; it does not dispatch jobs automatically.
There is no universal JobVersion, cancel, retry, rollback or exactly-once guarantee.
aws-managed-target
Advanexus runtime boundaries can be mapped to managed AWS database, cache, object storage, secrets, observability and workload services.
The repository does not provide a universally accepted production ECS or CDK stack.
bounded-by-default
Interactive preview, search, graph, artifact, export, notebook, transform and package paths use explicit bounds.
Truncated or partial results remain visible as such and are not presented as complete data delivery.
production-acceptance-required
Production sign-off is tied to an exact revision, immutable image, target infrastructure and recorded acceptance evidence.
Documentation, a readiness badge or repository tests alone do not certify a deployment.
tenant-project-scope
Tenant is the organization and data-isolation boundary; Project is the membership and execution scope within a tenant.
Each target environment must pass authorization, migration and negative-path acceptance.
capability-status-contract
Public capabilities are classified as available, production-oriented, environment-dependent or planned.
The status describes product scope; it does not replace acceptance of a customer's environment.
existing-stack
advanexus is designed to work across existing data systems rather than require their wholesale replacement.
Integration still requires supported connectors and an accepted deployment design.
platform-control-layer
advanexus connects governed data operations, analytics, controlled Python work and available evidence through a shared operating model.
Capability depth and production acceptance vary by module and deployment.
anpy-boundaries
ANPy is governed Python analysis, not a claim of full MLOps, GPU scheduling, model serving or autonomous execution.
Drive mounting, direct table-to-DataFrame access and full collaborative notebook behavior are not implicit capabilities.
anpy-governed-runtime
ANPy connects a project-scoped notebook, versioned environment, kernel lifecycle and bounded cell-run output.
Production use requires an accepted runtime-manager, image, package catalog and isolation policy.
managed-table-versioning
Successful transforms publish immutable physical table versions behind a stable, user-facing SQL alias.
Alias promotion occurs only after validation; rollback can change the schema expected by downstream consumers.
sandbox-bounded-transform
Bounded preflight and publication support CSV, delimited UTF-8 text, JSON object records and the first XLSX worksheet.
Format, size, encoding, delimiter, sheet and parser limits remain explicit; unsupported content fails closed.
sandbox-file-versions
Sandbox Drive preserves project-shared files as immutable versions with SHA-256 identity and quota accounting.
Production storage encryption, lifecycle and recovery depend on the accepted storage deployment.
general-deny-boundary
Module-specific permission contracts exist; a universal persisted platform-wide DENY-wins model is not yet complete.
Public security copy must not imply a stronger global negative-permission contract.
security-boundaries
Server-owned identity, tenant, project and permission contexts are revalidated at protected application and data-access boundaries.
Target-environment identity, session, role and negative-path acceptance remains mandatory.
sql-read-only
SQL Console is a controlled read-only exploration surface with server-owned source and scope validation.
Source capability and SQL dialect still determine what can be executed safely.
public-site-accessibility
The public site is designed for keyboard access, semantic structure, reduced motion and responsive reading.
Final conformance requires automated and manual acceptance on the exact public build.
public-site-data-minimization
The public static site is designed to minimise collection and does not require an embedded contact-form backend.
Direct email follows the sender's and recipient's mail systems; formal legal-owner review remains a release gate.
public-site-no-nonessential-cookies
The initial public static site does not require analytics, advertising or other non-essential cookies.
Any future optional technology requires policy, consent and documentation review before release.
No results
The ledger pairs reviewed public wording with status, boundary, evidence references, owner and last-reviewed date. Search and module filters help locate a capability; they never turn a conditional or planned item into an available one.
What the current product contract actually supports.
The permission, connector, deployment or evidence condition that must remain visible with the claim.
Repository documentation or test references used for review, not a substitute for target-environment acceptance.
Who must revisit the claim when product or public wording changes.
The capability exists in the current product contract with supporting implementation or test evidence. Connector, permission and bounded operation limits can still apply.
The capability exists, but infrastructure, authorization, storage, recovery, browser or live-service acceptance is required for the exact production deployment.
Availability depends on driver, vendor runtime, network, secrets, worker, storage, model provider or deployment policy.
The capability is a documented hardening or future phase. It is not presented as something a current user can rely on.
Claim records link public wording to evidence references and review date. A product change requires claim and translation review before the public build is released.
Production sign-off belongs to an exact source revision, immutable images, target infrastructure and recorded migration, authorization, recovery, storage, connector, browser and operational acceptance. Repository tests, a readiness label or this public ledger cannot certify a customer environment by themselves.
Next step
Bring the systems, owners, rules, delivery obligations and evidence requirements that matter.
Discuss a critical flow