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 |