Skip to main content

EmbrAIon — AI-First Engineering System by GORYNED

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:

  1. Why EmbrAIon?
  2. EmbrAIon in 60 Seconds
  3. Five-Minute Sandbox
  4. Installation
  5. Choose the repository path:
  6. Your First AI Task
  7. 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.31

  • The optional litellm extra and the LiteLLM execution adapter move to LiteLLM 1.88.6, which fixes CVE-2026-84377. The adapter still accepts only that exact version: reinstall embraion[litellm] after upgrading, and re-record usage evidence that names an older adapterVersion (see the CLI reference).

New in 0.30

  • The optional check section of policy declares which organization-check modes (full, compare or both), security threshold and scan scope embraion check uses, and the reusable actions/check action 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 decisions contract slot and .embraion/decisions.yaml declare which changes are architectural, embraion decisions check (also run by embraion check --base-ref) requires a record or a Decision-Waiver, and embraion adr new scaffolds the next numbered record.

New in 0.28

  • embraion check runs every check the project configuration selects, so consumer CI needs one step; projection.<host>.components in policy declare the projections it verifies.
  • Optional privacy.sources gives 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/setup action, and embraion framework pin prints 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.yaml report drift between expected and observed MCP servers.
  • embraion validate checks the project's own .embraion/*.yaml, and claude-native status --require turns the Claude Code projection state into a CI gate.
  • Merge mode owner-permission lets 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 .meta for every file under its Unity roots, with orphan detection.
  • Security scan finds provider-prefixed tokens and home-directory paths, and --all-files extends 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

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 04:49 UTC

Metadata

Release files for embraion 0.33.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for embraion 0.33.2
File Size Uploaded
embraion-0.33.2.tar.gz 3.4 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for embraion 0.33.2
File Interpreter ABI Platform
embraion-0.33.2-py3-none-any.whl Python 3 none any Details

Total release size: 7.7 MB

Release files / embraion-0.33.2.tar.gz

Download URL embraion-0.33.2.tar.gz
Size 3.4 MB
Tags Source
SHA-256 checksum
How to use checksums
959db7214e87337cce14449171a220343792c5e0f2d29b24fc57c4d33fe1c574
BLAKE2b-256 checksum
How to use checksums
c49581bc674d8495b4fda9604bca427061e4c61b488be7bfcf3146352e36f644
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 8, 2026.

Transparency log

Release files / embraion-0.33.2-py3-none-any.whl

Download URL embraion-0.33.2-py3-none-any.whl
Size 4.3 MB
Tags Python 3
SHA-256 checksum
How to use checksums
3d248fd72fdb2d3d1c21d5a554aa5e3d8e5eaab1e22ad29ce87973ed95af9681
BLAKE2b-256 checksum
How to use checksums
0bc71f0c0bf041d5566a589858a077b643badc650a982228613558d105602918
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 8, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.33.2 This release

2 release files

0.17.1

2 release files

0.17.0

2 release files

0.16.3

2 release files

0.16.2

2 release files

0.16.1

2 release files

0.16.0

2 release files

0.15.3

2 release files

0.15.2

2 release files

0.15.1

2 release files

0.15.0

2 release files

0.14.0

2 release files

0.13.3

2 release files

0.13.2

2 release files

0.13.1

2 release files

0.13.0

2 release files

0.12.0

2 release files

0.11.0

2 release files

0.10.2

2 release files

0.10.1

2 release files

0.10.0

2 release files

0.9.4

2 release files

0.9.3

2 release files

0.9.2

2 release files

0.9.1

2 release files

0.9.0

2 release files

0.8.1

2 release files

0.8.0

2 release files

0.7.0

2 release files

0.6.1

2 release files

0.6.0

2 release files

0.5.0

2 release files

0.4.3

2 release files

0.4.2

2 release files

0.4.1

2 release files

0.4.0

2 release files

0.3.2

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page