Register Owner: CTO and General Counsel
Effective Date: May 8, 2026
Reviewed: On each material model change and at least annually
Next Review: May 8, 2027
The model registry referenced from the AI Acceptable Use Policy → Model cards. Every model surfaced through a Neuroscale product feature — whether built on a third-party provider or own-trained — has an entry here. New customer-facing entries, material updates, or replacements are gated on a registry entry plus an AI Review Log decision.
Operational mirror: the technical artifacts (training datasets, eval scripts, model weights) live in the engineering data lake / model store. This registry is the human-readable summary referenced from the policy and from external trust-center materials.

​
Model-card schema

Every entry captures the following sections:
  1. Model identity — name, version, intended customer use, owner.
  2. Provider — own-trained / Anthropic / OpenAI / AWS Bedrock / other (cite specific model and version).
  3. Training data summary — for own-trained models, source data categories and licensing. For third-party models, refer to the provider’s published documentation and Neuroscale’s enterprise terms.
  4. Evaluation — benchmarks used, metrics, current scores, evaluation date. Include any fairness / bias evaluations relevant to the use case.
  5. Known limitations — failure modes, situations where the model should not be used.
  6. Recommended uses to avoid — explicit list (e.g., “Do not use for medical diagnosis,” “Do not use as the sole basis for a hiring decision”).
  7. Data flow — what customer data flows to / from the model, what is logged, and what retention applies.
  8. EU AI Act classification — provisional tiering (prohibited / high-risk / limited-risk / minimal-risk) plus GPAI / systemic-risk flag where applicable. Confirmed by counsel before EU launch. Mandatory Annex III screen: every feature card must record an explicit yes/no determination of whether the feature is an Annex III(4) high-risk AI system (recruitment or selection of natural persons, including placing targeted job ads, screening or filtering applications, or evaluating/ranking candidates), with a one-line rationale. A “limited-risk” or “minimal-risk” tag is not valid without this recorded screen. Where the feature is recruitment/screening/ranking, the default is high-risk unless an Art. 6(3) derogation is documented and counsel-approved. High-risk features carry the provider obligations in the AI Acceptable Use Policy and a FRIA per the DPIA Procedure.
  9. Customer disclosures required — text used in product UI and in customer DPAs.
  10. DPIA reference — link to the DPIA covering the processing.
  11. AI review record — link to the AI Review Log entry that approved this version.
  12. Re-review date — default 24 months; sooner on material change.
AIMS / ISO 42001 fields. For the AI Management System (ISO/IEC 42001) track, each card additionally records: (a) AI-system impact assessment reference — the DPIA/FRIA or bias-audit covering impact on individuals and groups (links to fields 8 and 10); (b) data-governance and lineage — training/fine-tune dataset card, provenance, and licensing (for own-trained models); and (c) post-market monitoring — how the deployed model is monitored for drift, bias regression, misuse, and incidents, and the cadence. These fields make the registry the AIMS operational-control record; see AI Acceptable Use → AI Management System.

​
Active models (customer-facing)

The four entries below are third-party AI provider integrations that power customer-facing product features (and are also approved for internal workforce use). They are listed publicly on the Sub-processor List as of 2026-05-07.
Model / providerApproved tierCustomer-facing useData flowCustomer-facing?EU AI Act tier (provisional)DPIAReview recordRe-review
Anthropic — Claude (API + Team / Enterprise)Enterprise / APIProduction AI features in Neuroscale products; internal workforce assistantCustomer prompts + retrieved context → Anthropic API → response back to product. Inputs are not used to train Anthropic models per enterprise terms. Full data-flow detail per feature lives in the corresponding DPIA.YesLimited-risk (Neuroscale’s use, under Art. 50 transparency obligations); provider operates a GPAI model.Customer-facing AI DPIA, DPIA RegisterAI Review Log 2026-05-072028-05-07
OpenAI — ChatGPT / API (Enterprise + API)Enterprise / APIProduction AI features in Neuroscale products; internal workforce assistantSame as above with OpenAIYesSame as aboveCustomer-facing AI DPIA, DPIA RegisterAI Review Log 2026-05-072028-05-07
xAI — Grok (API + Enterprise)Enterprise / APIProduction AI features in Neuroscale products; internal workforce assistantSame as above with xAIYesSame as aboveCustomer-facing AI DPIA, DPIA RegisterAI Review Log 2026-05-072028-05-07
Cerebras — cerebras.ai inference (API)Enterprise / APIProduction AI features (fast inference); internal workforce assistantSame as above with CerebrasYesSame as aboveCustomer-facing AI DPIA, DPIA RegisterAI Review Log 2026-05-072028-05-07
Reconfirmation cadence: every 24 months (next due 2028-05-07) or sooner on a material change in any provider’s terms, model surface, or in the BIS / EU AI Act / state-AI rules. Adding a new provider, retiring a provider, or routing a new data category to a provider requires a new AI Risk Review and a DPIA addendum. Per-feature model cards. A separate model card per Neuroscale product feature is added to the table below once the product surface is named and the feature is launched. The provider rows above are the provider-level entries that any feature card cross-references.

​
Per-feature model cards

A feature card identifies the specific model and version invoked by a named Neuroscale product feature and is the artifact cross-referenced from the corresponding customer-facing DPIA. Provider terms set forth at Active models apply to each feature card by reference and shall not be restated.
FeatureModel and versionProvider rowIntended useInputs and outputs loggedBias and fairness evaluationEU AI Act tier (provisional)DPIAReview recordRe-review
Aurora — customer-facing synthetic media of authenticated user. Governed by AI Acceptable Use → Synthetic media of persons.Aurora synthesis pipeline (Neuroscale-operated); exact model identifier and version recorded by Engineering at the corresponding AI Review Log entry created at DPIA approval (see DPIA column).Own-trained / self-hosted — governed by Own-trained and self-hosted models.Generate AI-synthesized video, audio, and lip-synced media of the authenticated user, from in-person crew-captured source material (no user-uploaded source).Inputs: in-person video and audio capture of the subject; identity-verification record at the session start; signed release. Outputs: synthesized media files carrying a persistent AI-generated label at the point of display and a C2PA-style provenance manifest on file export where supported. Logged: generation events, output metadata, abuse-monitoring signals; retention per the Records Retention Schedule.Subgroup-parity evaluation across skin-tone, voice-pitch, and gender-presentation cohorts (artifact-rate parity, lip-sync-quality parity) prior to launch and annually thereafter; methodology, date, and results recorded in the AI Review Log entry.Limited-risk — EU AI Act Art. 50(4) deep-fake disclosure obligation attaches; not Annex III high-risk because synthesis of a consenting, authenticated subject is not employment / recruitment / education / consequential-decision decisioning. The General Counsel re-confirms tiering prior to placement on the EU market and on each material feature change.Required before first production deployment — DPIA pending filing per DPIA Procedure; owner General Counsel + CTO. Aurora is not yet a production-available service; the filing gate is first production deployment, so no in-window control gap exists for the initial SOC 2 observation period. The DPIA is filed before Aurora launches. Filed in the DPIA Register.Pending — AI Review Log entry created at DPIA approval.24 months from approval (default); sooner on material change.
A new or updated feature card shall be issued upon any of the following: (i) a change in model identifier or version; (ii) a change in provider; (iii) the routing of a new data category to the model; (iv) the introduction of a decision surface based solely on automated processing within the meaning of GDPR Art. 22 or the California Privacy Protection Agency’s Automated Decision-making Technology regulations; or (v) a material change to customer-facing disclosure copy. Each such event requires an AI Review Log entry and a DPIA addendum prior to launch.

​
Own-trained and self-hosted models

This section governs (i) models that Neuroscale fine-tunes; (ii) open-source models that Neuroscale self-hosts, including without limitation Llama, Qwen, Mistral, and DeepSeek, where surfaced through a customer feature; and (iii) any model trained from scratch by Neuroscale. Each entry shall comprise the twelve schema fields specified at Model-card schema together with the additional fields tabulated below. Fine-tunes and from-scratch training are subject to the dataset-card requirement set forth in the AI Acceptable Use Policy → Training data. Where a model qualifies as a general-purpose AI model, the training-content summary required by EU AI Act Art. 53(1)(d) shall be prepared and approved by the General Counsel prior to placement on the EU market.
Model identityBase model and licenseTraining or fine-tune dataset (dataset card)HostingProvider roleBias and fairness evaluationEU AI Act tier; GPAI flagDPIAReview recordRe-review
Template — to be completed upon first own-trained or self-hosted entry. <internal name; version><base model; license (e.g., Llama 3.1 70B; Llama 3 Community License)><dataset-card link(s); for inference-only deployments of upstream weights, state "Not applicable; see upstream model card"><deployment surface and region>Neuroscale operates the deployed model; upstream weight licensor identified separately<method; date; subgroup metrics; link><tier>; GPAI: <yes / no>; counsel confirmation required prior to EU placement on market<DPIA link><AI Review Log entry><date; default 24 months from approval>
Inference-only deployments of upstream open-source weights. A registry entry is required where the model is surfaced through a customer feature. The training-data field shall cite the upstream model card; a Neuroscale dataset card is not required absent fine-tuning, reinforcement learning from human feedback, or other modification of weights. Fine-tunes. Each fine-tune constitutes a distinct entry, notwithstanding that the base model is separately registered, because intended use, evaluation results, and dataset composition differ from the base. Training-data sourcing, lawful basis, and dataset-card requirements are governed by the AI Acceptable Use Policy → Training data. Customer Content as a training-data source — deidentification required. Where a fine-tune or from-scratch training run consumes Customer Content (including Candidate data submitted to Arbi), the corpus shall be processed through the Deidentification Standard before admission, and the resulting model shall pass the Reidentification Audit Procedure before production deployment. The dataset card shall record the Stage-3 k and l values actually achieved, the Stage-5 differential-privacy accountant report, and the Stage-6 audit result. Tier-based training-use opt-outs are enforced upstream of the Deidentification Standard per Section 7.3 of the Terms of Service.

​
Provider terms — current state

All four approved providers operate under enterprise / API terms that prohibit training on Neuroscale-submitted inputs. Customer-facing AI processing is disclosed in the Sub-processor List and in the Customer DPA template. Adding a new provider, or moving any data category not previously covered to an existing provider, requires a new AI Risk Review and a DPIA addendum before launch.

​
Adding a model

  1. Product owner drafts the model card using the schema above.
  2. Engineering attaches evaluation results.
  3. General Counsel reviews EU AI Act tiering and customer-disclosure language.
  4. AI risk-review group approves per the AI Review Log procedure.
  5. The card is added here; a launch is not authorized until the entry is in this registry.

​
Retiring a model

When a model is retired or replaced:
  • The current entry is moved to the Retired table below with the retirement date and the replacement model (if any).
  • Customers affected are notified per the relevant DPA notice obligations.

​
Retired models

Model identityRetired onReplaced byNotes
None.

​
Cross-references

​
Version history

VersionDateDescriptionAuthorApproved by
1.0May 8, 2026Initial versionCameron WolfeIshan Jadhwani