3. Context and Scope

The system boundary is the branded application with its embedded Rukh core and owner-selected trusted integrations. Extension publishers, distribution sources, optional organization services, agent applications and protected resources remain outside. Ordinary extension code is admitted for supervised execution; it does not become a trusted core integration merely because it is installed. The diagram presents the application as one unit; 5. Building Block View opens its internal boundaries. ADR-0001, ADR-0010

3.1 Business context

Components and decisions

CLI owner · CLI user · Extension author · Named CLI application · Approved artifact sources · External identity service · External permission service · Protected resources · Agent or machine client

ADR-0002 · ADR-0005 · ADR-0006 · ADR-0007 · ADR-0010 · ADR-0011 · ADR-0012 · ADR-0013 · ADR-0016

Communication partner	Supplies to the application	Receives / retains responsibility for	Source
CLI owner and delegated administrator	Approved application code, trust/source configuration, command mounts and access rules	A coherent application; responsibility for the authority of those choices, not every publisher’s implementation	ADR-0009, ADR-0010
Extension publisher	Static command declarations, compatibility and runtime requirements, exact released artifacts	Independent publication; requested facilities do not grant the publisher core registration or user permissions	ADR-0006, ADR-0007
CLI user / operator	Command requests and input; separately authorized install, update or configuration requests	Help, terminal interaction, results and maintenance diagnostics within the selected policy	ADR-0002, ADR-0007
Agent application	Discovery and typed tool requests through an approved host binding	Tool descriptions and finalized results; responsibility for its own planning and tools outside Rukh	ADR-0013, ADR-0014
Catalog and artifact sources	Permitted candidate references and exact release bytes	Bounded discovery/retrieval requests; hosting does not confer publisher trust or execution permission	ADR-0005, ADR-0007
Identity and permission authorities, when selected	Verified identity facts, access decisions and their validity evidence	Requests bound to the selected authority, subject, actor and actual action; their own identity/policy remains authoritative	ADR-0005, ADR-0011, ADR-0012
Resource owner / service	Operation replies, resource conditions and supported effect evidence	Admitted operations under its own contract; control of resource-side permissions, effects and reconciliation support	ADR-0015, ADR-0016

The operator is the person maintaining or using the local CLI. The subject is the verified principal whose rights apply, when the configuration requires identity. The actor is the separately bound person or application making the request on that subject’s behalf. Credentials used by an adapter to contact a service form another binding: they are not automatically the caller’s identity. A local configuration can have an explicit local context without inventing a verified organizational subject. ADR-0005, ADR-0009, ADR-0014

3.2 Domain objects and distinctions

An extension’s authority-qualified package identity identifies the published package; its exact release binds a version, descriptor and payloads. A command has a stable identity within that package. Its visible CLI path is a route selected from the declared tree and owner mounts. Executable subcommands have their own command IDs; groups organize routes without a handler. An alias points to the same command and cannot change its meaning, requirements or authorization identity. Access to a parent route or group does not grant access to all child commands. Release version, command identity and route spelling answer different questions; a namespace’s spelling alone does not prove publisher trust. ADR-0002, ADR-0006, ADR-0007

The following are separate decisions about those objects, not interchangeable meanings of “available”:

Decision	What it establishes	What it does not establish
Discovery	The caller may see a candidate under the selected catalog and visibility rules	Trust in its bytes or permission for all its commands
Release trust and compatibility	Exact publisher/content bindings and declared requirements satisfy owner checks	Rights to install or invoke a command
Installation	Complete verified artifacts exist in the managed store	Participation in the current command tree
Activation	One validated configuration and command generation becomes the active profile	A permanent permission grant for its users
MCP exposure and visibility	An eligible active command is approved for the machine interface and visible to this caller	Permission to execute it, or approval of a later external action
Invocation admission	This exact call may start under its pinned context and current checks	Unrestricted use of every resource the implementation can name
Protected-operation admission	The specific operation may begin for the actual resource and applicable task limits	Proof that an external effect succeeded or can be repeated

These distinctions follow ADR-0005, ADR-0007, ADR-0012, ADR-0013 and ADR-0016. They apply to local and organization-backed configurations alike.

An active profile binds an immutable owner-configuration revision to a complete command generation, including built-ins and exact extension releases. An invocation captures that binding; an update does not retarget the running call. Current checks can nevertheless prevent its later actions. The installed store, active command set and caller-visible command set therefore need not contain the same entries. ADR-0007, ADR-0010

Catalogs and access rules maintained as code are versioned configuration data under owner authority. Extension declarations are publisher data under a different authority. Review, Git hosting or KCL compilation does not by itself grant either source trust. Neither downloaded declarations nor help, logs and results can register implementation code, redefine identity or issue task authority. ADR-0006, ADR-0009, ADR-0013

3.3 Technical context

External interaction	Selected channel or boundary	Source
Human invocation	CLI arguments and standard streams; the core owns terminal presentation	ADR-0002
Agent invocation	Optional MCP stdio; authenticated HTTP is a separate owner-selected integration	ADR-0013
Catalog and release retrieval	Local catalog data and OCI, HTTPS or Git artifact bindings; verification is common	ADR-0007, ADR-0009
Identity and permission integration	Standard OIDC/OAuth and AuthZEN mappings or registered custom/domain adapters	ADR-0005, ADR-0011
Runtime supply	Owner-admitted integration verifies a selected existing environment or performs separately authorized preparation; the extension declares requirements, not an installer	ADR-0008
Resource access	Owner-registered core operations and the explicit OS boundary of the selected executor	ADR-0015, ADR-0016

The private extension channel is an internal execution boundary described in 7. Deployment View; it is distinct from the external MCP interface.

3.4 Usage configurations

These are independent combinations, not mandatory maturity levels. They use the same extension and invocation model. ADR-0009

Configuration	Who maintains the context	Implication for the boundary
Local shared tools	The owner supplies a static catalog and explicit local policy	No organizational sign-in or remote permission service is required; protected resources and runtime preparation retain their own grants
Catalog and access rules in a repository	Authorized maintainers publish reviewed, versioned data; verified identity is added if rules target individuals	Repository membership or a name in a group file is not itself authentication; approved configuration authority remains required
Organization integrations	The owner connects existing identity, catalog and permission facilities independently	A required service failure cannot switch the configuration to permissive local rules
Approved agent use	The owner enables MCP and a bounded task preset alongside any suitable configuration above	A local stdio host needs no extra service; HTTP hosting and stronger execution restrictions require their separately supported integrations

MCP is a different caller interface, not a new publisher or a different source of command implementations. The initial path is noninteractive and uses owned foreground invocations; a longer-lived host does not imply background extension jobs. ADR-0004, ADR-0013

3.5 Outside the product boundary

Rukh does not replace the organization’s identity directory, permission database, resource-side enforcement or the agent’s planner. Security Broker names the integration boundary, not a mandatory server. Ordinary loading retrieves verified published artifacts rather than building arbitrary source repositories. ADR-0005, ADR-0007

The core owns command admission and lifecycle, not every business effect a trusted program can perform directly. A host-trusted process retains its OS account’s authority. Required confinement and controlled effects cover only their supported enforcement and registered-operation boundaries; neither a trusted publisher nor the MCP interface expands those guarantees. ADR-0015, ADR-0016