Information Areas

The standard defines optional canonical areas. A team creates only what it needs. Structuring information into distinct areas realizes the “Distinguish information types” principle: durable knowledge, current state, and rules governing changes serve different purposes. An area can be represented by a single file or by a directory with INDEX.md; its structure should be organized modularly from the start, designing sections with future decomposition in mind. Paths in the table show directory-based setups:

Area	Purpose	Example Contents
FISS/knowledge/subject/	Domain knowledge the project operates within	Concepts, business rules, processes, domain invariants
FISS/knowledge/project/	Durable knowledge about the project itself	Architecture, project terms, environment, conventions, practices
FISS/state/	Mutable state affecting ongoing work	Open questions, active risks, temporary constraints
FISS/overrides/	Project rules for applying agent skills	Skill behaviors and lifecycles, templates, verification criteria, human governance
FISS/human/knowledge/	Standalone material primarily for humans	Observations, personal context, explanatory notes
FISS/human/projection/	High-level synthesis of extensive knowledge for human comprehension	Domain concept maps, architecture diagrams

The team may add custom areas. Standard structural and navigation rules apply to them.

Knowledge: Domain and Project

FISS/knowledge/subject/ answers the question "What must be understood about the domain?" It describes entities, terminology, processes, rules, and invariants. The name subject is not tied to any mandatory methodology, including DDD.

FISS/knowledge/project/ answers the question "What must be known about the project structure and workflows?" It describes architecture, component relationships, environments, tooling, conventions, common pitfalls, and known workarounds.

Glossaries can span both areas. Domain terms belong in FISS/knowledge/subject/, while component names, internal abbreviations, and project-specific terms belong in FISS/knowledge/project/. If a term shares the exact meaning in both areas, define it once and cross-reference. If a word has different meanings, define each separately and explicitly identify its applicable scope.

Durable knowledge may also evolve over time. Its distinction from current state lies in purpose: it supports understanding and working on the project across multiple tasks.

State

FISS/state/ describes the current situation that can affect work: open questions, active risks, and temporary constraints.

If current state is already tracked in an external tool, link to that authoritative source. For example, when tasks are tracked in an issue tracker, FISS must not create a duplicate tracker for the same items. Rules for transitioning state, if the project customizes skill behavior, reside in FISS/overrides/.

Material Primarily for Humans

The entire intellectual space should remain accessible to humans. The FISS/human/ area is used when a team wants to separate materials that do not need to be included in routine agent context.

• FISS/human/knowledge/ contains standalone notes and knowledge primarily intended for people.
• FISS/human/projection/ helps humans navigate and reason about complex systems when knowledge in FISS/knowledge/subject/ and FISS/knowledge/project/ becomes too vast to hold in working memory. This area is intended for large projects; there is no need to create it prematurely.

Projections can be concept maps, architecture overviews, and dependency charts. They distill essentials for humans from detailed sources. A projection is not an independent source of truth: it must link to canonical sources and note significant simplifications. When source knowledge changes, related projections must be reviewed.

The name FISS/human/ denotes intended audience and purpose, not access restriction. Document applicability is determined by read conditions and project policies.