Trust and evidence
Design System Evaluation methodology
AgentKogei publishes inspectable evidence and complete Design Contracts so a Builder can judge a Design System before Installation. The process establishes traceable facts without promising a particular result in every Project.
Current workflow
One evidence backed path to publication.
1. Inspect the Design Reference
A maintainer supplied image or public URL establishes broad visual direction. AgentKogei inspects it for useful principles without copying product identity, proprietary assets, distinctive compositions, or a living designer's style.
2. Author one final release
The Design System Addition creates an original Design Contract, structured Design System Preview data, a Design System Mark, publication metadata, and generation evidence for one final 1.0 release.
3. Evaluate the reference implementation
Design System Evaluation checks required screens, responsive viewports, light and dark color schemes, reduced motion, automated validation, and public evidence. Accessibility evaluation targets WCAG 2.2 Level AA for the reference implementation.
4. Validate the publication record
Generation blocks when metadata is invalid, evidence is missing, the Design Contract digest changes, a release identity is duplicated, required Design System Preview values are absent, or unexpected release files appear.
5. Publish by merging
A pull request exposes the complete change for maintainer review. Merge to the main branch is the publication boundary and triggers production deployment. A failed validation result prevents completion.
What evaluation means
Evidence, not a blanket guarantee.
Generation evidence
The publication record identifies agent generation runs, required surfaces, viewports, color schemes, automated checks, and evidence paths. Published files remain open for inspection.
Automated validation
Validation proves that required publication data and evidence exist, that the fixed Design Contract digest matches, and that the release meets the repository contract. It does not judge every future use.
Accessibility scope
Evaluation covers a reference implementation against WCAG 2.2 Level AA expectations. It does not claim that every resulting interface conforms. A Builder remains responsible for testing the interface and content produced in the Project.
Human review
Older evaluation records may identify a separate human review and rights review. The current workflow exposes a pull request for maintainer review but does not require or imply an independent human approval record.
Workflow language
Current facts and retired gates.
The earlier gated process kept a Candidate Design System Release separate from Authoring Approval, Design System Evaluation, and Publication Approval. Those three gates had distinct meanings. They are not claims about the current Design System Addition workflow.
- Candidate Design System Release
- An unpublished release in the retired gated workflow. Current Design System Additions create one final release in isolation until its pull request is merged.
- Authoring Approval
- The retired gate that accepted creative direction without claiming evaluation or publication. The current workflow has no separate Authoring Approval state.
- Publication Approval
- The retired gate that authorized admission to the Design Systems collection. Current publication is authorized by merging the validated pull request, not by a separate Publication Approval record.
Design System Evaluation
The standardized generation and automated validation a Design System Release must pass before publication, including evidence that its reference implementation meets WCAG 2.2 Level AA.
Published Design System
A Design System whose final release has met its completeness and quality requirements and has been merged into the Official Catalog source. Before merge, it is not published.
Installation
The declarative application of one Published Design System to a Project through its root Design Contract. Installation is not publication or redesign.
Releases and rights
Stable versions, open terms.
Immutable two part releases
Every Design System Release uses a two part major.minor version. A minor release adds compatible direction. A major release may change visual or behavioral direction in breaking ways. There is no patch release category, and an exact release keeps the same Design Contract bytes.
MIT License
The repository and every Published Design System are MIT licensed. Builders may use, copy, modify, distribute, sublicense, or sell copies under those terms. AgentKogei publishes only original direction or material it has the right to use.
Compatibility
Every current Design Contract directly targets React 18 or 19, Next.js 15 or 16, Tailwind CSS v4, and shadcn/ui. Compatibility is published per release so a Builder can check it before Installation.
Retrieval and Installation
Public by design. Private by default.
The Design Systems collection is public and stateless. Current and exact Design System Releases can be inspected and retrieved without an account or authorization. The web application keeps no persistent application state.
The CLI sends only the requested Design Contract selector. It sends no Project name, path, Git remote, file content, prompt, generated interface, or dependency list. The installed Design Contract works offline without AgentKogei or network access.
Installation places the complete Design Contract at the Project root and may maintain one marked AGENTS.md reference so agents can find it. It does not redesign an existing interface, execute the direction, add hidden state, or manage future releases.