DEV Community: Gorkem Ercan

Securing MCP: Applying Lessons Learned from the Language Server Protocol

Gorkem Ercan — Fri, 28 Mar 2025 18:37:07 +0000

I was deeply involved with the Language Server Protocol (LSP) from its earliest days at Red Hat, one of the instrumental organizations in driving LSP adoption. During that time, I contributed to several key implementations, including the second-ever language server—the Java Language Server—and the widely adopted YAML Language Server. These projects became benchmarks for reliability and widespread adoption in developer communities.

Why MCP Matters

Given my experience with LSP, I’m enthusiastic about the growing interest in the Model Context Protocol (MCP). However, I am concerned that the valuable lessons learned from LSP are not being effectively applied to MCP.

When LSP emerged, it transformed programming language tooling. Specifically, it allowed language experts to implement sophisticated, language-specific intelligence consistently across different IDEs and editors. LSP created an abstraction enabling the same compiler development teams to directly support any IDE or editor.

MCP provides an analogous abstraction between AI tools and agents and their computing environments. However, the type of abstraction provided by LSP—deep, specialized programming language expertise—is significantly more complex to integrate and replicate compared to the API interactions primarily targeted by MCP. This difference currently makes MCP’s value proposition lower than that of LSP, which raises ongoing questions about whether MCP provides substantial value beyond existing APIs.

Critical Risks with Current MCP Implementations

Unfortunately, MCP carries forward several critical shortcomings that were also issues with LSP. One significant oversight with LSP was the lack of standardized packaging. Visual Studio Code—the hero product driving LSP adoption—provided its own method for packaging extensions, but this approach was not easily transferable to other platforms. The absence of standardized, secure packaging made LSP implementations vulnerable to supply chain attacks. Even VS Code’s extension packaging was not originally designed with supply chain security in mind, proving vulnerable at times.

The risk is even greater with MCP due to its broader potential access and integration to critical systems. Organizations face significant security risks if they adopt MCP directly from third-party sources without a robust packaging solution that includes secure attestations and digital signatures.

Additionally, LSP is defined to operate on single-user desktop environments without built-in multi-tenancy, a feature that simplifies implementation, but limits use in cloud environments. This lack of multi-tenancy poses a much larger challenge for MCP, as MCP implementations are more likely to run in multi-tenant environments requiring robust authentication and authorization.

Without addressing these critical issues related to packaging, secure supply chains, multi-tenancy, authentication, and authorization, the overall value and viability of MCP will continue to be questioned.

At Jozu, we are uniquely positioned to address these critical MCP adoption challenges. With extensive experience gained from pioneering work on LSP and our development of KitOps—a proven open-source solution trusted by enterprises for securely packaging and deploying AI/ML workloads—we are prepared to solve MCP’s most pressing security and packaging issues. Partnering with us will help your organization significantly reduce exposure to supply chain risks while accelerating secure MCP adoption.

Your Opportunity: Become a Design Partner

We’re currently seeking a limited number of design partners to join us in shaping the future of MCP. As a design partner, you’ll gain exclusive access to our solution, have direct influence on product direction, and receive expert guidance on securely implementing MCP in your organization.

Spots are limited—contact today to secure your position.

The KitOps Methodology

Gorkem Ercan — Fri, 14 Mar 2025 16:29:53 +0000

In the ever-evolving world of AI and machine learning, the path from model conception to deployment is full of challenges. The KitOps methodology is designed to guide teams through this complex journey with a focus on security, reproducibility, and transparency. The KitOps methodology streamlines the entire AI lifecycle by offering a unified, OCI-compliant framework that bridges the gap between development, packaging, and deployment. This approach not only simplifies collaboration but also empowers teams to innovate without sacrificing clarity or security. KitOps creates an environment where data scientist, a DevOps engineer, or an application developer, KitOps helps bridge the gap between model creation, versioning, and operationalization, all while maintaining transparency, security, and modularity.

Core Principles

Secure, Immutable Versioning and Provenance
At the heart of KitOps is the idea to secure and immutable versioning. Each model version is encapsulated as a single, immutable entity that includes code, data, documentation, and configurations as a single, immutable entity. This guarantees:

Consistency: Every component of a given model version is stored together, ensuring full reproducibility.

Traceability: Comprehensive attestations and provenance details make it easy to track changes and verify the authenticity of each model version.

Integrity and Accountability: Immutability prevents unauthorized modifications and supports compliance with DevSecOps best practices.

Separation of Concerns

KitOps advocates for a clear separation between model artifacts and infrastructure dependencies. This principle helps teams maintain:

Modularity: Models remain independent units, which simplifies updates and reducing the risk of conflicts.

Simplicity: Teams can focus on improving models without being entangled in infrastructure-level complexities.

Enhanced Maintenance: Updating models and infrastructure independently prevents unintended breakage and simplifies long-term maintenance.

Key Components

ModelKit

ModelKit: is an OCI-compliant packaging format that contains all the essential artifacts of the AI/ML model lifecycle. This includes:

Datasets: Comprehensive collections of training, validation, and test data.

Code: All logic required for model training, inference, and deployment.

Configurations: Environment variables, hyperparameters, and deployment settings.

Documents: Detailed records and guides related to the model.

Model Artifacts: Serialized model weights and associated metadata.

This standardized packaging ensures that models can be easily shared, audited, and redeployed, fostering a collaborative and transparent workflow.

OCI Registry

An OCI Registry, compatible with Open Container Initiative standards, serves as a centralized repository for storing and distributing OCI artifacts like ModelKits and container images. Its benefits include:

Standardization: Consistent management and access to model artifacts.

Integration: Direct compatibility with common CI/CD, MLOps, and DevOps tools.

Security: Hardened storage and secure artifact transmission, enhancing overall supply chain integrity.

Kitfile

The Kitfile is a YAML-based configuration file that precisely defines the contents of a ModelKit. With a Kitfile, teams can ensure:

Repeatability: Consistent model packages across different environments and teams.

Governance: A clear and auditable record of the artifacts included in each ModelKit.

Simplicity: One central place to specify datasets, code, configurations, and documentation artifacts.

Kit CLI and PyKitOps

The Kit CLI and the Pykitops library are powerful tools that enables users to create, manage, run, and deploy ModelKits. Whether you are packaging a new model for development or deploying an existing model into production, these tools simplify your workflow and accelerate your innovation cycle.

How it works?

Create or Generate a Kitfile:
Begin by specifying which documents, code, datasets, configurations, and serialized model weights should be included. Early stages might focus on datasets and code, while production-ready models include comprehensive elements such as weights, validation data, API code, and even infrastructure-as-code recipes like Terraform scripts.

Package the ModelKit:
Use the command kit pack to bundle your Kitfile into a ModelKit. This package acts as a single source of truth, simplifying collaboration, auditing, and distribution among stakeholders.

Push to a Registry:
Push your ModelKit to an OCI-compatible registry (e.g., Jozu Hub) to store, manage, and share it securely. This ensures that your team—across various regions and environments—has consistent and secure access to the model artifacts.

Use Automated Processing:
Leverage automation to handle the ModelKit for various tasks such as deployment, training, evaluation, or integration into downstream applications. Automated pipelines ensure consistency and rapid iteration, allowing teams to quickly adapt models to evolving requirements.

Benefits of the KitOps Methodology

Efficiency: Streamlined management of artifacts and distribution processes reduces friction and accelerates innovation

Security and Compliance: Strong governance, auditing, and immutability measures ensure that every change is traceable and compliant with industry standards.

Scalability: As models, datasets, and related resources expand, KitOps scales gracefully, maintaining uniform standards and practices.

Conclusion

The KitOps methodology represents a modern, secure, and reliable approach to managing AI/ML assets. By pairing well-defined artifacts with standardized tooling—supported by OCI registries and the Kit CLI—teams can confidently develop, test, share, and deploy models. In an era where rapid iteration and continuous improvement are key, KitOps not only enhances technical efficiency but also nurtures a culture of innovation and accountability.

Unifying Documentation and Provenance for AI and ML: A Developer’s Guide to Navigating the Chaos

Gorkem Ercan — Thu, 17 Oct 2024 14:32:58 +0000

In the fast-paced, constantly evolving world of artificial intelligence (AI) and machine learning (ML), you might expect there to be a well-defined standard for something as critical as model documentation. Yet, the current reality is far from expectation. While AI model documentation tools like Model Cards were meant to streamline accountability and transparency, we’ve instead landed in a fragmented space that lacks consistency.

What Is a Model Card?

A Model Card is a standardized documentation framework designed to provide essential information about a machine learning (ML) model, including its attributes, performance metrics, and ethical considerations. Model Cards help developers, researchers, and end-users better understand the model's intended use, its limitations, and any potential risks or biases associated with it. This documentation aims to improve transparency, accountability, and trust in AI and ML systems.

Key Information in a Model Card:

Model Overview: A description of the model, its architecture, and its intended use case.
Performance: Detailed metrics on how the model performs across different datasets, environments, or user demographics.
Ethical Considerations: Information on potential biases in the model and any fairness or safety concerns.
Training Data: Description of the data used to train the model, including its provenance, size, and any preprocessing steps.
Limitations: Clear details about where and how the model should not be used, including scenarios where it might fail.

Model Cards were introduced in a 2019 paper by Margaret Mitchell and her collaborators at Google AI. The idea emerged from the recognition that machine learning models, especially those deployed in real-world applications, often have far-reaching ethical and societal implications. Without clear and transparent documentation, these models can be misused or misunderstood, potentially leading to harmful outcomes, such as biased predictions or unfair decision-making processes.

The paper proposed Model Cards as a way to address these challenges, by offering a standardized and accessible format for documenting models. It drew inspiration from nutrition labels, which provide clear and consistent information to consumers about the contents of food products. Similarly, Model Cards are intended to serve as "nutrition labels" for ML models, offering critical details in a standardized and understandable format. In reality, it’s a bit more complex.

The Model Card Maze

Model Cards, in theory, are straightforward. They’re designed to offer clear, standardized documentation on the attributes, performance, and ethical considerations of machine learning models. The idea behind them is solid—a one-size-fits-all tool for explaining how models work and their implications.

However, in practice, Model Cards have taken on multiple forms:

HuggingFace uses YAML frontmatter and Markdown for its Model Cards.
AWS SageMaker employs a JSON schema.
VerifyML has its own unique spin on the format.
Google? They follow a different JSON schema entirely.

And that’s not even touching on the original Model Card proposal from the foundational paper. The variation across platforms is not just about different tastes or minor tweaks. These differences reflect deeper structural and intent-based divergences. HuggingFace's Markdown-driven simplicity is very different from SageMaker's JSON schema-based precision, and that disparity matters. Developers trying to adhere to best practices for AI accountability are left grappling with a lack of coherence.

Model Cards Are More Than Just Documentation

These differences aren’t just a matter of aesthetics. Model Cards play a critical role in ensuring compliance with a growing web of AI regulations, including:

The EU AI Act
The NIST AI Risk Management Framework (RMF)
ISO 42001

These regulations require robust documentation, and without a unified standard, developers are left to navigate this growing regulatory minefield without clear guidance. The result? Increased risk of non-compliance, and potentially, the perpetuation of biased or unsafe AI systems.

SBOMs: A Glimmer of Hope for Standardization

But all is not lost. Amid the chaos, there’s a promising development: SBOM formats (Software Bill of Materials) like SPDX 3.0 and CycloneDX. While not originally created for AI, these formats have started to incorporate AI models and datasets. This is a crucial step forward because SBOMs are a logical solution to providing the standardization that Model Cards are currently lacking, and they are already commonplace in software development practices.

Why SBOMs Matter for AI

Comprehensive Coverage: SBOMs can include both models and data, giving developers a more complete view of their AI systems.
Standardization: With a unified format like SPDX 3.0 or CycloneDX, we could bridge the gap left by the fragmented Model Card landscape.
Provenance and Trust: SBOMs offer a way to trace the lineage of AI models—what they do, where they came from, how they were trained, and under what conditions they should be used.

A Path Forward

The inclusion of AI models in SBOM standards like SPDX 3.0 and CycloneDX is a critical advancement. If these formats gain widespread adoption, they could provide the transparency and accountability that the AI industry so desperately needs. This isn’t just about technical improvements—embracing SBOMs is a moral imperative to ensure that AI is developed and deployed ethically and transparently.

In the end, the future of AI documentation depends on our ability to standardize and unify our approaches. It’s time for the industry to rally around SBOMs and adopt standards like SPDX 3.0 and CycloneDX, before the lack of coherence in documentation leads us down a risky path.

Let’s not wait for regulations, like the EU AI Act, to force our hand. The time to act is now.

Why Devs Love Open Source KitOps–Tales from the ML Trenches

Gorkem Ercan — Thu, 29 Aug 2024 16:51:12 +0000

In the world of AI/ML there are a lot of puff pieces singing the latest technical innovation. Most of the time, these innovations aren’t being used outside of a cadre of scientists who have adopted. In contrast, we put together this article to share how a real user at a real company is using KitOps - and explain, in stark terms, why KitOps is the only solution that meets their needs.

The Folly of TARs and S3

First, let's address the elephant in the room: TAR files. Yes, they’re handy little bundles of joy, squeezing your artifacts into neat, portable packages. But that’s where the honeymoon ends. One user, Niklas and engineer at a German federal technology company, broke it down for us with the kind of brutal honesty that only comes from experience “S3 and GitLFS are like the wild west—anything goes, and that’s precisely the problem because both fall short”
Not Tamper Proof: Without immutability, there's no guarantee your artifacts haven’t been tampered with. Good luck explaining that to your compliance officer.

Lack of Audibility: When it’s time to trace back a decision to its source, TARs and S3 aren’t much help. New AI regulations, Niklas points out, "requires securing the integrity and authenticity of release artifacts." How’s that supposed to happen when your artifacts are floating around, unchained and unverified?

No Easy Tagging: Champion vs. challenger models, semantic versioning—good luck implementing those without the right tools. TARs don’t do it, and neither does S3.

Poor Metadata Handling: Sure, your artifact might have a name, but does it tell the whole story? What about the additional metadata that’s crucial for downstream processes?
Inconsistent Supply Chain: "Everything is in Artifactory," Niklas notes. "So why not store ML artifacts there too?" It’s about consistency, and that’s not something TARs or S3 can deliver.

The Power of KitOps

KitOps, by contrast, doesn’t just store your artifacts—it puts them into your existing OCI registry (DockerHub, Quay.io, Artifactory, GitHub Container Registry) which has already passed security vetting and is covered by enterprise-grade authentication and authorization. Now they’re guarded like a hawk, while the KitOps ModelKit format ensures that every byte is accounted for, every version is tagged and tracked, and every artifact is as immutable as Mount Everest. This isn’t just about meeting compliance—it’s about ensuring that your AI models are trustworthy, reliable, and secure from the get-go.

Why KitOps?

Tamper-Proof: With KitOps, your artifacts are locked down, hashed, and immutably stored. No more waking up in cold sweats wondering if something was altered on the sly.

Auditability: Every artifact comes with a complete history, ensuring that when the auditors come knocking, you’re not scrambling for answers.

Tagging and Versioning: With built-in support for champion vs. challenger models, semantic versioning, and more, KitOps makes it easy to manage complex ML workflows.

Elegant Bundling: KitOps doesn’t just store your artifacts—it bundles them with all the metadata you need, ensuring that every deployment is consistent and reliable.

Consistency Across the Supply Chain: By storing everything in Artifactory, KitOps ensures that your AI/ML workflows are as seamless as the rest of your DevOps processes.

Scaling Up

Of course, all of this wouldn’t mean much if KitOps couldn’t scale. But as Niklas explains, that’s not an issue. His team might be small now—just 10-15 data scientists, engineers, and SREs working on five predictive ML models—but they’re growing. And as they do, KitOps will scale with them, ensuring that their workflows remain smooth, secure, and consistent, no matter how many models they deploy. That’s why it’s being adopted by some of the largest government agencies, science labs, and global technology companies in the world.

Predictive ML, Not LLMs

It’s worth noting that Niklas’s team isn’t diving into the deep end of LLMs just yet—they’re focused on predictive ML. But whether you’re deploying LLMs, fine-tuning them, or just managing a handful of predictive models, KitOps has you covered. Of course, if you’re doing LLMs, KitOps makes even more sense since the number and size of project artifacts only grows.

The Bottom Line

If you’re serious about AI/ML, and you’re tired of wrestling with tools that promise the world but deliver a mess, it’s time to give KitOps a look. It’s not just about storing your artifacts—it’s about ensuring they’re secure, auditable, and ready for deployment at a moment’s notice. Because in this game, anything less is a risk you can’t afford to take.

If you have questions about integrating KitOps with your team, join the conversation on Discord and start using KitOps today!

The Expected Cooling of the Generative AI Hype

Gorkem Ercan — Mon, 26 Aug 2024 13:48:07 +0000

Environmental changes have always been catalysts for evolutionary shifts. The rise of Large Language Models (LLMs) like ChatGPT has ignited the birth of a new technological ecosystem. But, as with any seismic change, the initial response is often wildly exaggerated, driven by those who don't fully grasp the nuances—a phenomenon we now dub the AI Hype. For those of us who've seen such waves before, it was clear from the start: this was a hype cycle, and like all hype cycles, it had to run its course. Now, the signs are undeniable—the hype is cooling down. But what's next for AI?

No technology, no matter how revolutionary, can thrive without delivering real value. And here's the truth: we haven’t yet cracked the code on generating consistent value for enterprises from AI. The next phase of AI's evolution won't be about shiny new algorithms or eye-catching demos; it will be about the nitty-gritty work of building standards, developing techniques, and creating frameworks that enable AI and ML to integrate into the fabric of business seamlessly and safely. We've begun to see pockets of success and early experiments that hint at the financial benefits AI/ML can offer. But as the hype bubble bursts, there's always a danger that the technology itself will be blamed for the inevitable disappointments—rather than the non-specialists who inflated expectations to begin with.

The reality is clear: AI/ML works. It has proven, valuable applications and should not be discarded just because it was overhyped. Now, more than ever, it’s time to rally behind standards, support open-source initiatives, and back companies that are focused on streamlining the adoption of AI and ML. This is how we accelerate the next phase of AI's evolution, turning what was once hype into sustainable, real-world impact.

Announcing the Preview Release for Jozu Hub

Gorkem Ercan — Wed, 24 Jul 2024 12:53:19 +0000

The benefits that AI will bring to enterprises will manifest as a gradual transformation rather than a sudden change. Much like transformative technologies of the past, such as cloud computing, mobile, or the internet, organizations that can integrate these technologies at a fundamental level will see significant advantages. Similar to its predecessors, AI as a transformative technology requires infrastructure, tooling, and practices to support its adoption.

At Jozu, our goal is to empower organizations to deploy and operate AI applications in production. We have open-sourced KitOps, which includes ModelKits—an OCI-compliant package containing everything needed to integrate with a model or deploy it to production—and the Kit CLI, which manages ModelKits on any OCI-compliant repository. Since launching KitOps a few months ago, we have experienced significant interest, as evidenced by the increasing download numbers, which have surpassed a thousand weekly downloads. We have also partnered with several companies in the US and Europe to help them adopt KitOps into their AI/ML pipelines.

One recurring piece of feedback we have received is that while organizations appreciate using their existing OCI registries, they would prefer a ModelKit-first registry experience. Today, we are launching the preview of Jozu Hub, our SaaS registry with a ModelKit-first experience. Jozu Hub is designed to work with ModelKits and provide essential information about a ModelKit, such as datasets and models, at your fingertips. It allows you to see the differences between ModelKit versions and easily spot essential security information, such as provenance.

Today’s launch is just the beginning. We have more features in the works, such as private repositories, more options for search, inference container images, and many more. We have not forgotten organizations that cannot use our SaaS service. We will also release a version of Jozu Hub that you can run in your infrastructure, which will work with your existing OCI registry.

If you are interested in the ModelKit-first experience of Jozu Hub, visit our beta release at jozu.ml. If you are interested in storing your own ModelKits, sign up for early access. If you are an organization that would prefer to run your own Jozu Hub, contact us at info@jozu.com, and in the meantime, sign up for early access to test the features.

KitOps Release v0.2–Introducing Dev Mode and the ability to chain ModelKits

Gorkem Ercan — Wed, 01 May 2024 12:25:41 +0000

Welcome KitOps v0.2! This update brings two major features for working with LLMs, as well numerous smaller enhancements. We are excited to introduce KitOps’ Dev mode - making it possible to test LLMs locally (even if you don’t have an internet connection or GPU).

We also introduce model parts to Kit so you can “chain” ModelKits, simplifying the building of things like adapters for common open source LLMs. These were both features requested by the community 💝

Here's what you need to know about the new additions:

Introducing KitOps Dev Mode

You can try Kit’s new dev mode by using the kit dev command. This initializes and launches a local development portal, allowing you to test various large language models (LLMs). The kit dev command uses the contents of the Kitfile. This initial version of dev mode includes a user-friendly chat and prompt interface and an OpenAI-compatible API, to seamlessly integrate an LLM into your applications.

Getting started is simple:

# Unpack a base LLM
kit unpack ghcr.io/jozu-ai/llama3:8B-text-q4_0 -d ./my-ai-project

# Launch the developer portal
kit dev ./my-ai-project

After running these commands, you will receive a URL to access the portal through your browser.

Currently dev mode is only available on MacOS, although we plan to expand it to additional platforms and include more inference runtimes and utilities for models, data, and code. File an issue in our GitHub repository telling us what platform we should tackle next, or how to improve the Kit dev command in general - we love community feedback!

More Powerful Model Packaging with Model Parts and Referencing
This release also introduces model parts, a feature to bring even more flexibility to ModelKits. Now you can reference other ModelKits as the base for your ModelKit, or package a more complex AI/ML project into multiple ModelKits, each focused on different models or model parts.

For example, to package a LoRA adapter that you have fine-tuned from the Llama3 base model, your Kitfile would be structured as follows:

model:
  name: my fine-tuned llama3
  path: ghcr.io/jozu-ai/llama3:8B-instruct-q4_0
  parts:
    - path: ./lora-adapter.gguf
      type: lora-adapter

This configuration instructs the kit pack command to package only the LoRA adapter, while the kit unpack and kit pull commands will retrieve your ModelKit and the base model from the referenced ModelKit - so users have everything they need from one command.

Model parts and referencing provide a flexible way to manage and distribute even complex models - for use cases like LoRA adapters, projectors, introducing new parameter sets, and many more. This feature is also helpful for enterprises who want to keep a library of base models, adapters, and even embedding or integration code pre-packaged in ModelKits, for development teams to reference. This can be a great way to provide approved AI/ML packages and “guardrails” for teams as they begin to build with AI/ML.

Get Started Now

We encourage you to explore these new features and take advantage of the other improvements in this release, including bug fixes, documentation enhancements, and performance optimizations. As always, the latest release is available on the KitOps project releases.

Try KitOps v0.2 today and see how these new capabilities can enhance your AI development workflow!

For support or to join the KitOps community, checkout the KitOps Discord server and Star the KitOps GitHub repo to support the project.

Strategies for Tagging ModelKits

Gorkem Ercan — Fri, 19 Apr 2024 13:57:52 +0000

ModelKits, much like other OCI artifacts, can be identified using tags that are comprehensible to humans. This blog explores various strategies for effectively tagging your ModelKits.

Multiple tags

A ModelKit can carry multiple tags and that is for a good reason. When you create a ModelKit, you typically want to have a tag that identifies its contents. For instance llama-2:7b-chat-q8_0 where 7b-chat-q8_0 tells the parameter size, variant and quantization of the llama2 model. If a ModelKit exclusively contains data, it might be tagged as categorization:sales-data-2023. These tags define the artifacts a user expects to receive. If a ModelKit includes both a model and significant datasets, it can be tagged with multiple tags that deliniates its contents. Generally, such tags are considered immutable by convention.

Besides content identification, tags can also signify different stages, environments and other characteristics for a ModelKit. Like latest, production, challenger. By convention, such tags are expected to be mutable.

Mutable vs Immutable

Tags are inherently mutable in nature. Some registries, like ECR, allow the configuration of tag mutability at the repository level. However, because a repository often needs to manage both mutable and immutable tags, enforcing immutability becomes impractical. Therefore, tags should not be relied upon when immutable references are required.

Instead, each ModelKit is equipped with a content-addressable tag called digest which is immutable. A ModelKit's digest is a 64-character hex-encoded SHA-256 hash of its contents. It is based on the contents of every artifact code, models, data and configuration. Changing any of these bits of information would result in a new digest.

You can pull a ModelKit by digest, verify the contents match the given digest. The digest is the canonical ID of a ModelKit by its contents.

Comparison with Git Tags

If you're familiar with Git, you may be thinking at this point that a digest is like a commit SHA, that is because a Git commit SHA is a 40-character hex-encoded SHA-1 hash of the contents of a given state of the source code. Changing a file's contents or metadata would result in a new commit SHA.

Git also has a concept of tags. When you want to share the state of a source code with others, you can apply a tag like 1.0.0, Git maps the tag 1.0.0 to some commit SHA. ModelKit tags are similar. Instead of having to deal with a long hex-encoded digest, you can deal with a tag like :7b-q4_0.

Both Git tags and ModelKit tags are mutable. In both cases, anyone with permission to push to the repo can also update and push a tag. This could be malicious, but usually it's a well-meaning mistake. If you want to know exactly the truth and immutability is really needed digests is the only way.

Some of you at this point may be thinking what about Git branches? Git branches also point to commits, when you Git commit something on a branch, the branch moves to point to the new commit. But this is really just a convention supported by Git tooling. ModelKits do not have a concept of branches but you can imagine the tags like latest that are expected to move to be a similar convention.

Conclusion

Effective tagging of ModelKits not only facilitates ease of identification and organization but also enhances the manageability of different versions and configurations of these artifacts. Whether leveraging mutable tags for operational flexibility or immutable digests for ensuring integrity, the thoughtful application of tagging strategies ensures that ModelKits can be seamlessly integrated and reliably referenced within any type of workflow. Remember, while tags offer convenience and adaptability, digests provide the cornerstone of trust and verification in the lifecycle of a ModelKit. Adopting these practices will empower your teams to maintain a robust, efficient, and secure AI/ML project management system.

Introducing the New GitHub Action for using Kit CLI on MLOps pipelines

Gorkem Ercan — Fri, 05 Apr 2024 19:15:59 +0000

One of the goals of KitOps is streamlining AI integration with your existing DevOps practices. Our latest contribution on this evolving landscape is a GitHub Action that simplifies integrating Kit CLI into your existing CI/CD toolset. This development is particularly exciting for those looking to leverage ModelKits, our OCI-compliant AI project packaging, directly within their CI/CD pipelines.

With the Setup Kit CLI action. Using Kit as part of your Github workflows is effortless. You can setup the latest version of the CLI to your workflow simply by adding the following to your workflow.

steps:
  - uses: jozu-ai/gh-kit-setup@v1.0.0
    id: install_kit

KitOps uniquely addresses a critical challenge in AI/ML development: the versioning and management of all project artifacts—including code, models, and data—under a unified framework. This integrated approach ensures that each component of an AI project is tracked and managed with precision, eliminating the common pitfalls associated with fragmented artifact management.

ModelKits, being OCI compliant, provide a standardized way to package AI projects, ensuring compatibility across your existing infrastructure. This standardization is vital for teams looking to deploy AI solutions in diverse operational landscapes without getting bogged down by compatibility issues.

To begin taking advantage of the streamlined AI project management KitOps offers, simply incorporate the Setup Kit CLI action into your GitHub workflows. For an in-depth understanding of all the features this action provides, visit the detailed documentation linked above.

As we continue to innovate and improve KitOps, your feedback is invaluable to us. Whether you're encountering challenges, have suggestions for new features, or simply want to share your success stories, we're all ears. You can provide feedback on our GitHub repo or our Discord channel.