Kanyman
en
EnglishРусскийO‘zbekcha
Get started
Documentation sections

For developers

Solution Packs

Connect product roles and scenarios declaratively without adding product-specific code to Kanyman Core.

Updated: August 11, 2026

01

What the manifest stores (short example)

jsonKanyman docs
{
  "schema": "kanyman.solution-pack.v1",
  "id": "example.support",
  "version": "1.0.0",
  "core_contract": "kanyman.external-integrations.v1",
  "roles": [{ "key": "support", "title": "Support" }],
  "scenarios": [{
    "key": "support.diagnostics",
    "version": "1.0.0",
    "entry_role": "support",
    "allowed_capabilities": ["project.get_diagnostics"]
  }],
  "required_capabilities": [{
    "name": "project.get_diagnostics",
    "version": "1.0.0",
    "kind": "read",
    "side_effect": "none"
  }]
}
  • The manifest contains roles, scenarios, policies, knowledge requirements, UI labels, and acceptance fixtures.
  • Credentials, private keys, tokens, and direct access to the product database are forbidden in the manifest.
  • A capability is identified by a stable name and exact version; the current contract accepts read and draft.
  • DISP and VerifyBox use the same schema contract as any third-party product.
02

Installation and compatibility

  1. 1Create and activate an external integration.
  2. 2Add and test the capabilities required by the selected pack.
  3. 3Install the pack on the integration. Kanyman stores an immutable manifest snapshot and digest.
  4. 4If a capability is missing, inactive, or has a different policy/version, the installation receives blocked status.
  5. 5After changing capabilities, run the check again and activate the pack.
  6. 6A pack can be disabled without deleting history; rollback moves the pointer only to a previously installed immutable snapshot.
  7. 7At runtime, the model selects the exact pack, scenario, and specialist role; the server validates the selection again and exposes only the capabilities of the current scenario step.
  8. 8A blocked or disabled pack fails closed: its capabilities are not exposed to the agent until a successful recheck and activation.
httpKanyman docs
GET /api/projects/{project_id}/external-integrations/{integration_id}/connectors/{connector_id}/versions/{version}/manifest
Authorization: Bearer <Kanyman access token>

{
  "schema": "kanyman.connector-contract.v1",
  "digest_scope": "manifest_without_lifecycle_status",
  "digest": "<sha256 canonical contract>",
  "manifest": {
    "schema": "kanyman.connector-manifest.v1",
    "id": "example.support-api",
    "version": "1.0.0",
    "status": "planned",
    "capabilities": ["...full input/output schemas..."]
  }
}
03

Scenario Library and persistent state

jsonKanyman docs
{
  "schema": "kanyman.solution-scenario.v1",
  "pack_id": "example.support",
  "pack_version": "1.0.0",
  "scenario_key": "support.diagnostics",
  "scenario_version": "1.0.0",
  "status": "active",
  "entry_step": "identify_issue",
  "steps": [{
    "key": "identify_issue",
    "kind": "question",
    "role_keys": ["support"],
    "allowed_capabilities": ["project.get_diagnostics"],
    "answer_options": [{
      "key": "resolved",
      "next_step": "completed"
    }]
  }]
}
  • A scenario definition is stored separately from the immutable pack manifest and linked by exact pack/scenario versions.
  • The draft, review, active, paused, and archived statuses are supported; runtime executes only active definitions.
  • In the account, an owner/admin can validate JSON on the server, save an immutable draft, submit it for review, and activate it separately; draft and review do not affect runtime and can be archived without losing history.
  • An active tenant-scoped version overrides the code default without a Core release; if none exists, runtime uses the definition shipped with the pack.
  • Each run stores an immutable definition snapshot and SHA-256 digest, the current step, role, and control version.
  • Only safe step/answer keys and product/tariff signals enter the log; user text, tokens, and PII are not copied there.
  • The server calculates the next step and role from the snapshot; the model cannot submit an arbitrary transition direction.
  • A transition is recorded in one transaction with the allowed answer. A retry does not create a duplicate transition.
  • Disabling, incompatibility, or a pack-version change cancels the active run fail-closed and records a cancelled event.
04

Account API

textKanyman docs
GET  /api/projects/{project_id}/solution-packs/catalog
GET  /api/projects/{project_id}/solution-packs
POST /api/projects/{project_id}/solution-packs/install
POST /api/projects/{project_id}/solution-packs/{installation_id}/refresh
POST /api/projects/{project_id}/solution-packs/{installation_id}/activate
POST /api/projects/{project_id}/solution-packs/{installation_id}/disable
POST /api/projects/{project_id}/solution-packs/{installation_id}/rollback

GET  /api/projects/{project_id}/solution-packs/{installation_id}/scenarios
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/{scenario_key}/preview
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/{scenario_key}/drafts
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/versions/{version_id}/submit
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/versions/{version_id}/activate
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/versions/{version_id}/archive

Continue reading

Read-only toolsSafe HTTP calls for up-to-date diagnostics.Confirmed actionsAction lifecycle, Idempotency-Key, and unknown-result handling.API and errorsPublic Web Chat endpoints and safe error codes.
Solution Packs — Kanyman Docs