Product content

coming This page describes a settled design that is not in a released version yet.

After installation the products run and people can sign in, but there is nothing to work with yet: no connection to the outside systems your processes call, no AI model settings, no secret for the API key. That is product content: things that live in a product’s own database and that you would otherwise create by hand in each console.

With the provisioner you declare it in files, and one run puts it in place through each product’s public API.

Kind	Product	What you declare
TinyGuardContent	TinyGuard	sign-in providers (for example Google), the tenant’s sign-in and multifactor settings
TinyVaultContent	TinyVault	the secrets the environment expects (names, descriptions, labels, never values), links to your own secret manager, who may change each secret
TinyConductorContent	TinyConductor	connections, AI settings, model policies, prompts, element templates

Example: an AI model and its key

vault.yaml says which secret the environment expects and who may change it. The value itself never appears in a file.

apiVersion: tinyblox.ai/v1alpha1
kind: TinyVaultContent
environment: production
tenant: default
secrets:
  - name: MODEL_API_KEY
    description: API key of the model provider, used by the credit-risk policy
    source: manual                 # a person sets the value; the run checks it has one
grants:
  - key: operators-rotate-model-key
    subject: group:operators
    names: [MODEL_API_KEY]
    actions: [write]               # may add a new version; still cannot read the value

conductor.yaml names that secret wherever TinyConductor needs it:

apiVersion: tinyblox.ai/v1alpha1
kind: TinyConductorContent
environment: production
tenant: default
connections:
  - name: model_api
    scope: tenant
    type: rest-authentication
    value:
      url: https://api.example-model.com/v1
      authentication:
        type: bearer
        token: { secret: MODEL_API_KEY }
aiPolicies:
  - name: credit-risk
    variants:
      - id: main
        weight: 10000
        provider:
          type: openai
          openai:
            api: { type: completions }
            backend:
              type: custom
              custom:
                endpoint: https://api.example-model.com/v1
                authentication:
                  type: apiKey
                  apiKey: { secret: MODEL_API_KEY }
            model: { model: example-model }

The plan shows everything before it happens:

tinyvault (tenant: default)
  ~ secret        MODEL_API_KEY       description (value set by hand)
  + grant         operators-rotate-model-key
tinyconductor (tenant: default)
  + connection    model_api (tenant)  secret MODEL_API_KEY (has a value)
  + policy        credit-risk         1 variant
… 3 to create, 1 to update, 0 to delete

Rules it follows

• Secret values never go into files. A value is entered once in TinyVault’s console, or piped into provision secrets set from your password manager, or linked from your own secret manager. Files only name secrets.
• Something still in use is not deleted. If you remove a connection from the file while a deployed process still uses it, the run fails and names the processes; nothing is deleted.
• It keeps things in step. The run happens on every change to the files, and on a schedule (every 30 minutes by default), so a change made by hand in a console is put back. Set the schedule to only report differences if you prefer to correct them yourself.
• One short-lived client per run. Each run makes its own client at the identity provider with only the rights it needs, and deletes it at the end.
• Products at different versions. Each running product says which versions of its file it accepts. A file that asks for something a product’s release does not offer fails the plan instead of being skipped.