Company — Concepts, Entities, OKRs

An aachat team holds shared context about the company itself, outside any individual piece of work (project). There are three layers. Concept's internal model (kind, semantic axes, revisions, reviews, links, similarity gate) is canonical in concept-registry.md; OKR's internal model (structure, lifecycle, check-in contract) is canonical in okr.md. Entity's internal model is canonical on this page.

Layer	Content	Where in the WebUI	Detail
Concept	Decision criteria the team has agreed on (purpose, strategy, principles, decisions, findings). Every agent and human reads them as premises for judgment	Team sidebar "Concepts"	`concept-registry.md`
Entity	The map of what the company consists of (Company map): products, channels, assets, and their links to Concepts and OKRs	Team sidebar "Entity"	Below on this page
OKR	Objectives and Key Results. Check-ins update measured values and confidence	Team sidebar "OKRs"	`okr.md`

Where to ask

No dedicated place is needed. Ask an agent in any project session, the same way as any other request (for example, "organize and propose the concepts for this business" or "design this quarter's OKRs"). During a session, agents carry tools to read and write the team's Concepts, Entities, and OKRs.

Read: agents read published Concepts and current OKRs / Entities and use them as premises for their judgment
Proposing Concepts: agents register new Concepts, revisions, and links as proposals. A proposal stays pending, and a human reviews it on the Concepts screen in the WebUI to accept or decline. Only accepted Concepts become the team's decision criteria (see concept-registry.md)
Entities and OKRs: agents can register and update Entities (normal kinds only — see below), and register, update, check in, and link OKRs directly from a session. Unlike Concepts, these take effect immediately, without a proposal-and-review step

Which layer to use

A decision criterion, policy, or finding that should hold over time → Concept proposal
A map of what the company has and what to build → Entity
A goal to set and track with measurements → OKR (values are updated via check-ins)

Company context is both an input and an output of agent work. An agent working in a project returns findings as Concept proposals; once a human accepts them, every later session works on top of those criteria. This is how the company itself grows as an asset (the company-level version of the company assets flow in concepts.md).

Entity model — kind, sensitive boundary, hierarchy

Entity makes up the map of what the company consists of (Company map). Entity stores no properties, evaluations, goals, KPIs, owners, or progress. Those belong to Concept (decision criteria), Project/Session (work in progress), and Message/Shared Document (evidence and detail).

kind — 9 types

kind	Note
`organization`	Normal
`offering`	Normal. A product or service
`media`	Normal. A channel or medium
`community`	Normal
`system`	Normal. An internal or external system
`facility`	Normal
`person`	sensitive
`partner`	sensitive
`agreement`	sensitive

The sensitive-kind boundary (important)

The three kinds person / partner / agreement cannot be registered or changed by an agent. If an agent attempts to register one, rename it, change its status, move it, or link a Concept to it, the server rejects the request. The rejection message is returned in Japanese regardless of the agent's own language:

person / partner / agreement Entity の変更は human の操作が必要です。Project の human member に依頼するか aachat_ask を使ってください。

("Changing a person / partner / agreement Entity requires a human action. Ask a human member of the project, or use aachat_ask.")

Agents can read sensitive kinds — their name and structure are visible as part of the Company map. Writes are restricted to human team Owners / Admins; a regular human member is rejected as well. Don't infer an Entity's meaning or evaluation from what you read — only name, kind, status, and parent are stored.

status — position in the company structure

planned / current / retired describe only the Entity's position in the company structure, not the progress of a piece of work.

planned: planned as part of the company structure
current: currently part of the company structure
retired: no longer part of the company structure

Hierarchy constraint: an active Entity (planned / current) cannot be placed under a retired parent. Before retiring an Entity, its active children must be moved or retired first.

Hierarchy (parent/child)

Entities form a tree. A parent is at most one Entity in the same team; self-reference, cycles, and cross-team parents are never allowed. Reparenting is done with a move operation. Don't represent more than one kind of structural relationship through parent (don't encode undefined relationships such as dependency, provision, or ownership into hierarchy or name).

Concept link

An Entity can link to a published Concept with realizes. This is the only relation type in v1. Don't link to an archived Concept or one with no published content.

Change history

Entity changes are recorded as append-only events: registered, renamed, status_changed, moved, concept_link_added, concept_link_removed.

Concept's types and lifecycle: concept-registry.md
OKR's types and lifecycle: okr.md
Projects and work context: projects.md
The WebUI as a whole: webui.md
Terms: glossary.md