English · Русский
EmbrAIon
AI-First Engineering System by GORYNED
EmbrAIon keeps the rules for AI-assisted engineering with the repository — project knowledge, protected paths, routing, validation, review, and evidence — instead of scattering them across prompts and AI-client settings.
Use the same project contract with Codex, GitHub Copilot, Claude Code, or a host-neutral Portable bundle.
Why use it?
Use EmbrAIon when:
- important project rules no longer fit in one prompt;
- several AI clients need to follow the same repository contract;
- protected paths and validation need deterministic checks rather than prose alone;
- architecture knowledge and policy must survive model/session changes;
- model selection, review, and evidence should be reusable project settings instead of ad hoc choices.
Mental model: EmbrAIon is the operating system for AI-assisted engineering;
.embraion/is the Settings for this repository.
EmbrAIon does not replace the AI client, intercept every prompt, or run inside the finished product.
Quick start
pipx install embraion
cd MyProject
embraion init
embraion install --host codex --destination .
Open the repository in your AI client and ask:
Configure EmbrAIon for this project.
Lead uses the canonical Core Project Bootstrap skill to inspect existing truth, bind knowledge, preserve safety policy, and discover real validation. Routing stays optional. See Project Bootstrap.
Then work normally:
Fix the retry flow and add regression coverage.
Use copilot or claude-code instead of codex when that is your host.
Lead reads the project contract, selects specialists automatically, classifies each assignment independently, resolves project routing, and applies configured model/effort through supported native host capabilities. It collects proportional validation and review, integrates results, and retains final authority.
Want to experiment first? Use the Five-Minute Sandbox.
Before / after
Before
prompts + AGENTS.md + host settings + CI + tribal knowledge
↓
drift
After
.embraion/
↓
one repository-owned project contract
↓
host projections + validation + review
Documentation
Canonical site: https://embraion.goryned.com/
Recommended onboarding:
- Why EmbrAIon?
- EmbrAIon in 60 Seconds
- Five-Minute Sandbox
- Installation
- Choose the repository path:
- Add EmbrAIon to a Project for a new or simple repository.
- Adopt an Existing Repository for a mature repository with existing AI-client configuration.
- Your First AI Task
- How It Works
Need a term or a direct answer? See the Glossary, FAQ, and Security & Data Flow.
For engineers, see Engineering Model Deep Dive.
New in 0.30
- The optional
checksection of policy declares which organization-check modes (full,compareor both), security threshold and scan scopeembraion checkuses, and the reusableactions/checkaction runs it after the setup action, so consumer CI carries no project flags.
New in 0.29
- Architecture decision records are part of the workflow: the optional
decisionscontract slot and.embraion/decisions.yamldeclare which changes are architectural,embraion decisions check(also run byembraion check --base-ref) requires a record or aDecision-Waiver, andembraion adr newscaffolds the next numbered record.
New in 0.28
embraion checkruns every check the project configuration selects, so consumer CI needs one step;projection.<host>.componentsin policy declare the projections it verifies.- Optional
privacy.sourcesgives each source ID its data class, and execution requests that name a source fail closed below that class.
New in 0.27
- Consumer CI can install the pinned release with the reusable
GORYNED/EmbrAIon/actions/setupaction, andembraion framework pinprints the exact pin; enforcement generates workflows that use the action. - Projections carry project-owned skills from
.embraion/skills/, specialist triggers and outputs, Core links pinned to the release tag, and an opt-in Claude Code hooks component; files recorded in projection ledgers count as generated sources. - Declared integrations in
.embraion/integrations.yamlreport drift between expected and observed MCP servers. embraion validatechecks the project's own.embraion/*.yaml, andclaude-native status --requireturns the Claude Code projection state into a CI gate.- Merge mode
owner-permissionlets an agent merge with the owner's explicit permission; validation profiles gain per-command timeouts, full logs and process-tree containment.
New in 0.26
- Core rules are projected into each host's startup instructions: Claude Code and Copilot rule files and the managed Codex instructions. Whether a surface applies them is checked on that surface; see Claude Code and Copilot.
- API execution builds fail-closed context envelopes from committed files, records each attempt in a local ledger that feeds candidate health, and checks readiness without a provider call.
- Code organization checks file names and can require a
.metafor every file under its Unity roots, with orphan detection. - Security scan finds provider-prefixed tokens and home-directory paths, and
--all-filesextends the precise checks to source code. - Policy ceilings also bound host routing overrides, and the report contract can require a Workers summary and a compare link.
New in 0.20
- Engineering skills and live skill evaluations cover repeatable procedures and fresh host-run comparisons. A recorded eval remains distinct from a live run.
- Code organization checks changed files incrementally; existing debt does not waive new violations.
- Task checkpoints and knowledge maintenance track local freshness with hashes and explicit baselines. They do not approve review or rewrite project documents.
- External capabilities record independently installed host capabilities. A declaration does not install a plugin or prove host loading or execution.
Examples
- Minimal — smallest complete project overlay.
- Python — ordinary Python app + EmbrAIon engineering layer.
- Unity — Unity 6 project with EmbrAIon outside the game runtime.
Status
EmbrAIon is pre-1.0. Projects pin exact published framework versions so upgrades remain intentional.
License and brand
Source code and documentation are licensed under the MIT License except where explicitly stated otherwise. The EmbrAIon and GORYNED names, logos, wordmarks, visual marks, and files under brand/assets/ are governed separately by TRADEMARKS.md.
Last updated: 2026-10-07 03:45 UTC
1 maintainer
Metadata
1 maintainer
Release files for embraion 0.30.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| embraion-0.30.0.tar.gz | 3.3 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| embraion-0.30.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 7.5 MB
Release files / embraion-0.30.0.tar.gz
| Download URL | embraion-0.30.0.tar.gz |
|---|---|
| Size | 3.3 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
0b3cebc0322aef58e4d5296476a9b3dd602aa12e1988004c3308206b34c8624e
|
|
BLAKE2b-256 checksum How to use checksums |
6e828ba4fbf3988804b553c22ad607a329aae57a0f214ed186a220709ab4878d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 7, 2026.
Transparency logRelease files / embraion-0.30.0-py3-none-any.whl
| Download URL | embraion-0.30.0-py3-none-any.whl |
|---|---|
| Size | 4.1 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
a1f00ee39215cf07d1242582a00dcf544eb914fc60c377bf9ccb81371c88e0cf
|
|
BLAKE2b-256 checksum How to use checksums |
bf30ecce3c72c4eb2a836a62f6d380dcaf970f06d903ca3a5756217760da221a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 7, 2026.
Transparency log
