ARCORIS is an engineering project focused on making distributed workload execution more predictable, safer under pressure, and easier to control in real systems.

It is built for platform engineers, operators, integrators, and contributors who need clear control over how work enters the system, how it is scheduled, how overload is handled, how resources are protected, and how runtime behavior remains observable under contention, failure, and changing system conditions.

This organization is intentionally structured as a multi-repository system. Each repository has a clear responsibility so that source code, public documentation, engineering standards, community structure, design-change tracking, and runnable examples remain easy to navigate instead of collapsing into one noisy place.

Use this map to choose the right entry point.

ARCORIS is centered on execution control in distributed environments.

That includes:

• admission control for deciding whether new work should be accepted, delayed, redirected, or rejected;
• rate control for shaping throughput based on live system conditions instead of fixed assumptions;
• overload protection for preventing cascading failure and protecting the system under pressure;
• workload isolation for preventing one tenant, queue, class, or flow from consuming the whole system;
• priority and fairness models for balancing urgency, guarantees, and resource distribution;
• feedback-driven scheduling behavior based on observed runtime conditions;
• observability-aware execution control where metrics, signals, and system state are first-class inputs into decision-making;
• failure-aware runtime behavior where retry, timeout, cancellation, backpressure, and degradation are treated as design concerns, not afterthoughts;
• integration and extensibility surfaces so ARCORIS can fit into broader platform and control-plane environments.

ARCORIS is most relevant when one or more of the following are true:

• workload arrival is bursty, uneven, or difficult to predict;
• resource pressure changes faster than static configuration can safely absorb;
• multiple tenants, queues, or workload classes compete for the same execution capacity;
• overload in one path can degrade unrelated work unless isolation is enforced;
• you need explicit admission, throttling, and degradation behavior instead of implicit failure;
• you need operationally visible control over rate, concurrency, fairness, and overload handling;
• you want execution behavior to respond to live system signals rather than only static policy.

This organization is structured so that each repository answers a different class of question.

• Core repository

The main technical repository for the project itself.

Start here when you need to understand:

• what ARCORIS is at system level;
• where the main implementation lives;
• how the source tree is organized;
• what the primary runtime and component boundaries look like;
• what the current implementation focus is.

• Documentation

The main public documentation entry point for users, evaluators, operators, and integrators.

Start here when you need:

• quick starts and onboarding;
• concepts and architecture overviews;
• deployment and operational guidance;
• tutorials, how-to guides, and troubleshooting;
• public reference documentation.

• Examples

Runnable examples, demo setups, baseline deployments, integration scenarios, observability bundles, and failure-oriented evaluation material.

Start here when you need:

• a minimal runnable setup;
• local or dev-cluster demos;
• example integrations;
• practical evaluation scenarios.

• Enhancements

The design and change-management repository for significant proposals and tracked architectural work.

Start here when you need to understand:

• what major changes are being proposed;
• what has already been accepted, rejected, withdrawn, or superseded;
• how large changes are tracked from proposal to implementation.

• Community

Defines how the project community works.

Start here when you need to understand:

• ownership and roles;
• decision-making;
• coordination structures and working groups;
• contributor growth paths.

• Handbook

Defines how engineering work is expected to be done across the project.

Start here when you need:

• engineering standards;
• documentation rules;
• review and quality expectations;
• release and process conventions.

If you are new to ARCORIS, this is the most effective order:

1. Core repository
2. Documentation
3. Examples
4. Community
5. Handbook
6. Enhancements

That order gives you:

• project understanding first;
• usage and operational context second;
• runnable material third;
• contributor and collaboration context next;
• engineering standards after that;
• major design-change history and future direction last.

This separation is intentional.

• The core repository contains and explains the implementation.
• The documentation repository is the public entry point for usage, operations, integration, and reference.
• The examples repository provides runnable setups and practical evaluation material.
• The enhancements repository tracks significant design changes and their lifecycle.
• The community repository explains ownership, roles, and coordination.
• The handbook repository defines how work is expected to be done across the project.

This keeps the project easier to navigate, easier to maintain, and easier to scale as both the codebase and the contributor surface grow.

Start with:

• Core repository
• Documentation
• Examples

You should be able to answer quickly:

• what problem ARCORIS solves;
• what kind of systems it is designed for;
• how it relates to schedulers, queues, workers, and control planes;
• whether it can be evaluated locally or in a small cluster;
• what its main architectural assumptions are.

Start with:

• Documentation
• Examples
• Core repository

You will primarily care about:

• deployment models;
• operational boundaries;
• observability expectations;
• failure handling;
• sizing and capacity assumptions;
• runbooks, troubleshooting, and upgrade guidance.

Start with:

• Documentation
• Core repository
• Examples

You will primarily care about:

• interface boundaries;
• extension points;
• compatibility assumptions;
• configuration surfaces;
• observability integration;
• adapter and deployment patterns.

Start with:

• Community
• Handbook
• Core repository
• Enhancements

Contributors should understand:

• how the project is structured;
• how ownership and review work;
• when a change fits a normal pull request;
• when a change requires a tracked enhancement;
• how tests, docs, and release-facing changes are expected to be handled.

For responsible disclosure and security handling, see:

• Security policy

Do not report sensitive vulnerabilities through public issues or public pull requests.

For contribution defaults and organization-level expectations, see:

• Contributing guide
• Community
• Handbook

ARCORIS should be evaluated based on repository content, documented scope, available examples, and the current state of tracked changes.

For the most accurate view of significant ongoing and upcoming work, see:

• Enhancements

For the most accurate public usage and operational guidance, see:

• Documentation

If you remember only one thing, use this map:

• What is ARCORIS? -> Core repository
• How do I use, run, or operate it? -> Documentation
• Where are runnable demos and setups? -> Examples
• How does the project community work? -> Community
• How do engineering standards and review rules work? -> Handbook
• Where are major proposals and accepted decisions tracked? -> Enhancements