Skip to content

ICA + SkillMeat Integration Flowcharts

Overview

This document captures workflow assumptions for integrating ICA skill operations with SkillMeat Enterprise. It is a planning companion to ICA Skill Library Use Case, focused on lifecycle flow rather than screen-by-screen product behavior.

All workflows below are performed in the ICA UI. SkillMeat is the backing engine that provides artifact, version, governance, deployment, and SkillBOM APIs to ICA.

ICA-Side Assumptions

  • ICA owns the user interface for authors, team leads, project owners, platform admins, auditors, and developers.
  • ICA has an enterprise-level catalog or registry where approved skills, embedded agents, and governance metadata can be published and browsed.
  • ICA supports team and project scopes, with inheritance from enterprise defaults to team baselines to project deployments.
  • ICA calls SkillMeat APIs for artifact intake, validation, version lineage, policy evaluation, deployment orchestration, update impact analysis, and SkillBOM generation.
  • SkillMeat provides artifact, version, governance, deployment, and BOM APIs; it does not own the ICA user experience in these workflows.
  • ICA can emit or expose events for skill creation, skill version publication, upstream catalog updates, and deployment policy changes.
  • ICA can identify teams, projects, repositories, and users with stable IDs that SkillMeat can map to enterprise tenants, teams, projects, and artifact owners.
  • ICA can distinguish between centrally managed artifacts and project-local overrides.
  • ICA can accept SkillMeat-generated artifacts, pull requests, deployment manifests, deployment records, version metadata, governance results, or SkillBOM references as integration outputs.
  • Approval gates, policy checks, and compliance attestations may be surfaced in ICA while SkillMeat records the backing artifact, version, governance, deployment, and BOM state.

Workflow 1: Skill Creation

sequenceDiagram
    actor Author as ICA Author
    participant ICA as ICA UI
    participant ArtifactAPI as SkillMeat Artifact API
    participant GovernanceAPI as SkillMeat Governance API
    participant CatalogAPI as SkillMeat Catalog API

    Author->>ICA: Draft skill and metadata
    ICA->>ICA: Validate required ICA fields
    alt Draft needs author changes
        ICA-->>Author: Show inline feedback
    else Draft ready for intake
        ICA->>ArtifactAPI: Submit skill package and source identity
        ArtifactAPI->>ArtifactAPI: Normalize artifact metadata
        ArtifactAPI->>GovernanceAPI: Request validation and policy checks
        GovernanceAPI-->>ArtifactAPI: Return approval result and findings
        alt Rejected or needs approval
            ArtifactAPI-->>ICA: Return findings and staged artifact ID
            ICA-->>Author: Show required fixes or approval path
        else Approved
            ArtifactAPI->>CatalogAPI: Publish curated skill record
            CatalogAPI-->>ICA: Return catalog artifact ID and availability
            ICA-->>Author: Show skill in ICA catalog
        end
    end

Boundary decisions

  • ICA owns authoring, review screens, user identity, and catalog display.
  • SkillMeat owns artifact intake, metadata normalization, validation results, governance state, and catalog records exposed through APIs.
  • The enterprise must decide whether final approval is captured before API intake, during SkillMeat governance evaluation, or both.

Workflow 2: Skill Versioning

sequenceDiagram
    actor Maintainer as ICA Maintainer
    participant ICA as ICA UI
    participant VersionAPI as SkillMeat Version API
    participant GovernanceAPI as SkillMeat Governance API
    participant CatalogAPI as SkillMeat Catalog API

    Maintainer->>ICA: Create candidate skill version
    ICA->>ICA: Capture changelog, compatibility, and release reason
    ICA->>VersionAPI: Submit candidate payload and release metadata
    VersionAPI->>VersionAPI: Compute content hash and lineage
    VersionAPI->>GovernanceAPI: Evaluate breaking-change and policy impact
    GovernanceAPI-->>VersionAPI: Return approval requirements
    alt Approval or migration notes required
        VersionAPI-->>ICA: Return staged version and required actions
        ICA-->>Maintainer: Request approval, migration notes, or changes
    else Standard update
        VersionAPI->>CatalogAPI: Publish version to catalog
        CatalogAPI-->>ICA: Return published version, diff, and upgrade metadata
        ICA-->>Maintainer: Show published version in ICA
    end

Boundary decisions

  • ICA owns the versioning UI, release intent, changelog capture, and maintainer approval flow.
  • SkillMeat owns artifact-level version truth: content hash, lineage, staged and published version state, deployment impact, and upgrade availability.
  • Version pinning and deferral policy should be explicit in ICA while SkillMeat stores the backing version and governance records.

Workflow 3: Skill Deployments

sequenceDiagram
    actor Developer as ICA Developer
    participant ICA as ICA UI
    participant GovernanceAPI as SkillMeat Governance API
    participant DeploymentAPI as SkillMeat Deployment API
    participant Git as Project Git Provider

    Developer->>ICA: Select skill and target project
    ICA->>GovernanceAPI: Check team and project deployment policy
    GovernanceAPI-->>ICA: Return allow, deny, or approval requirements
    alt Deployment denied
        ICA-->>Developer: Show policy failure and remediation path
    else Deployment allowed
        ICA->>DeploymentAPI: Request deployment plan
        DeploymentAPI->>DeploymentAPI: Resolve artifact version and target profile
        DeploymentAPI->>Git: Create branch, commit files, and open PR
        Git-->>DeploymentAPI: Return PR URL and commit metadata
        DeploymentAPI-->>ICA: Return deployment record and PR reference
        ICA-->>Developer: Show PR, deployment status, and next actions
        Git-->>DeploymentAPI: Report merge or close status
        DeploymentAPI-->>ICA: Update active, blocked, or rejected deployment state
    end

Boundary decisions

  • ICA owns skill selection, project visibility, approval prompts, and deployment status presentation.
  • SkillMeat owns policy evaluation, deployment planning, artifact resolution, Git deployment bundle generation, PR creation, and deployment tracking APIs.
  • Repository merge authority remains with the project team's normal Git workflow.

Workflow 4: Upstream Updates: Skill Agents

sequenceDiagram
    actor Admin as ICA Platform Admin
    participant ICA as ICA UI
    participant ArtifactAPI as SkillMeat Artifact API
    participant VersionAPI as SkillMeat Version API
    participant DeploymentAPI as SkillMeat Deployment API
    participant GovernanceAPI as SkillMeat Governance API

    ICA->>ArtifactAPI: Notify upstream skill-agent update
    ArtifactAPI->>VersionAPI: Identify affected skill artifacts and versions
    VersionAPI->>VersionAPI: Compute source-to-catalog diff
    VersionAPI->>GovernanceAPI: Evaluate update safety and policy
    GovernanceAPI-->>ICA: Return review requirement or auto-update eligibility
    alt Admin review required
        ICA-->>Admin: Show diff, affected skills, and risk summary
        Admin->>ICA: Approve, reject, or defer
        ICA->>GovernanceAPI: Record admin decision
    else Auto-update eligible
        GovernanceAPI->>VersionAPI: Authorize catalog candidate or version update
    end
    VersionAPI->>DeploymentAPI: Find deployed projects and compute drift
    DeploymentAPI-->>ICA: Return impacted teams, projects, and rollout actions
    ICA-->>Admin: Show ICA rollout queue and project update options

Boundary decisions

  • ICA owns upstream update review, admin decision capture, affected-scope display, and rollout controls.
  • SkillMeat owns affected-artifact discovery, version diffing, governance evaluation, drift calculation, and rollout action APIs.
  • Auto-update rules must be explicit because skill-agent changes can alter runtime behavior.

Workflow 5: Upstream Updates: Enterprise to Team to Projects

sequenceDiagram
    actor TeamLead as ICA Team Lead
    actor ProjectOwner as ICA Project Owner
    participant ICA as ICA UI
    participant GovernanceAPI as SkillMeat Governance API
    participant VersionAPI as SkillMeat Version API
    participant DeploymentAPI as SkillMeat Deployment API

    ICA->>GovernanceAPI: Submit enterprise baseline update for evaluation
    GovernanceAPI-->>ICA: Return team rollout eligibility and constraints
    alt Not eligible for rollout
        ICA-->>TeamLead: Show hold reason and required enterprise action
    else Eligible for team rollout
        ICA-->>TeamLead: Show available baseline update
        TeamLead->>ICA: Accept, modify, or defer team baseline
        ICA->>VersionAPI: Record team baseline, override, or deferral
        VersionAPI->>DeploymentAPI: Find projects inheriting team baseline
        DeploymentAPI-->>ICA: Return inherited, pinned, and locally overridden projects
        ICA-->>ProjectOwner: Show project diff and update action
        ProjectOwner->>ICA: Accept, defer, or keep local override
        ICA->>DeploymentAPI: Request project PRs or deployment updates
        DeploymentAPI-->>ICA: Return project update records and lineage
    end

Boundary decisions

  • ICA owns enterprise, team, and project workflow screens plus the accept, modify, defer, and override actions.
  • SkillMeat owns governance evaluation, version lineage across scopes, inherited versus pinned state, local override state, and deployment update APIs.
  • Team and project deferrals should be auditable because they create policy exceptions.

Workflow 6: SkillBOMs

sequenceDiagram
    actor Auditor as ICA Auditor
    participant ICA as ICA UI
    participant DeploymentAPI as SkillMeat Deployment API
    participant BOMAPI as SkillMeat BOM API
    participant GovernanceAPI as SkillMeat Governance API
    participant Git as Project Git Provider

    ICA->>DeploymentAPI: Request current project skill environment
    DeploymentAPI-->>BOMAPI: Provide deployed artifacts, versions, owners, and hashes
    BOMAPI->>BOMAPI: Generate point-in-time SkillBOM snapshot
    BOMAPI->>GovernanceAPI: Request signing or attestation policy
    alt Signing required
        GovernanceAPI-->>BOMAPI: Return signing policy and attestation fields
        BOMAPI->>BOMAPI: Sign BOM and store signature
    else Signing not required
        GovernanceAPI-->>BOMAPI: Return unsigned BOM policy
        BOMAPI->>BOMAPI: Store unsigned BOM with provenance metadata
    end
    BOMAPI->>Git: Attach BOM reference to commit or PR metadata when enabled
    BOMAPI-->>ICA: Return BOM reference, signature state, and restore metadata
    ICA-->>Auditor: Show SkillBOM evidence and point-in-time environment
    opt Recovery or comparison requested
        Auditor->>ICA: Request restore or compare view
        ICA->>BOMAPI: Request restore or drift comparison data
        BOMAPI-->>ICA: Return reproducible environment metadata
    end

Boundary decisions

  • ICA owns compliance display, auditor workflow, and restore or comparison controls.
  • SkillMeat owns SkillBOM generation, artifact and version resolution, signing metadata, commit or deployment references, and restore or compare APIs.
  • The enterprise must decide whether unsigned BOMs are acceptable for development environments or whether signatures are mandatory.

Integration Ownership Summary

Workflow ICA-owned assumptions SkillMeat-owned responsibilities
Skill creation Authoring UI, source identity, author feedback, catalog display Artifact intake, validation, governance findings, catalog records
Skill versioning Version UI, release intent, changelog, compatibility notes, approval prompts Hashing, lineage, staged/published versions, deployment impact
Skill deployments Skill selection, project visibility, approval prompts, deployment status display Policy checks, deployment plan, Git PR creation, deployment tracking
Skill-agent upstream updates Admin review UI, decision capture, rollout controls Affected artifact discovery, diffing, drift analysis, rollout action APIs
Enterprise/team/project updates Scope workflow UI, accept/modify/defer/override actions Governance evaluation, lineage preservation, pin/override state, update APIs
SkillBOMs Compliance display, audit review, restore/compare controls BOM generation, signing, deployment references, restore/compare metadata