Skip to main content
gpodz

How it works

Three layers, in a fixed order.

Gpodz Compute is designed around a shared base model, a company adapter, and a role adapter. This page describes that design: what each layer is, how an adapter is made, and where your material goes.

Status

This page describes the product design. Which layers are available to your organization, and on what timeline, is confirmed in writing during scoping.

Listed from top to bottom.

  1. Role adapter. Tuned for the work one team does, such as claims review or policy questions.
  2. Company adapter. Trained on material your company approves: policies, product rules, and terminology.
  3. Base model. An open-weight foundation model for general language and reasoning, shared by every customer.

What each layer does

Base model

An open-weight foundation model for general language and reasoning. Every customer starts from the same base. By design, the base is not retrained on your material; your material goes into your adapters.

We do not name the base model family on this site. We disclose it during scoping and in contract documents.

Company adapter

A layer trained on material your company approves, such as policies, product documentation, procedures, and terminology. One company adapter serves every team in your organization, so they share the same grounding.

Role adapter

A layer for one function, such as claims review, underwriting support, or policy questions. It sits on top of the company adapter and tunes behavior to the tasks, formats, and limits of that role.

How an adapter is made

  1. Choose the material. Your team selects the documents and examples the adapter should learn from. The design uses only material your team selects.
  2. Train the adapter. The adapter is trained on that material and stored as a new version. The base model is not changed.
  3. Review before use. Your reviewers test the new version on examples you choose before it is activated.
  4. Activate, update, or roll back. A version is activated when you approve it. If a later version falls short, the previous version is designed to be restored without retraining the base model.

Where your material goes

  • Material you approve is used to train your organization’s adapters.
  • Each organization’s material and adapters are designed to be stored under that organization’s own storage paths, separate from other organizations’.
  • Adapter changes and other platform events are designed to be recorded in an append-only, hash-chained log.
  • Retention and deletion periods are being set with counsel. They will be published on the trust page once approved.

Map the layers to your organization.

Tell us which teams you want to support and what your review process requires.