FISS Specification Status This document is the normative core of the File-based Intellectual Space Standard (FISS). Human-facing documentation may explain or illustrate this specification but MUST NOT override it. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are to be interpreted as normative requirements. Intellectual Space An intellectual space is an abstract logical system of knowledge, rules, state, context, and artifacts that supports collaboration between humans and AI agents. It describes what exists in the space and how it is used, not where or in which format it is stored. This document defines the intellectual-space concept only to the extent needed by FISS. FISS is the complete filesystem-based standard that realizes this model. Logical Model An intellectual space contains logical artifacts identified by their purpose rather than by a filesystem path or format. Logical artifacts MAY represent knowledge, rules, current state, operational work, decisions, plans, evidence, or other project information. Logical artifacts MAY have relationships to one another. An intellectual space SHOULD make relationships understandable and SHOULD allow a person or agent to determine which context is relevant to a particular task. FISS does not require a typed relationship language. For information represented in multiple places, the intellectual space MUST identify a canonical source or a rule for selecting one. Derived representations MUST identify their canonical source when omission could cause incorrect use. The intellectual space MUST NOT silently treat a derivative or projection as a competing source of truth. An intellectual space MAY use external mechanisms. An external mechanism is a mechanism used by the intellectual space but not part of the project or its intellectual space. External mechanisms MAY include agent skills, task trackers, documentation systems, version-control systems, tools, and processes. External mechanisms remain independent of the intellectual space. The project MAY define how an external mechanism is applied within the project and MAY override applicable behavior without modifying the mechanism itself. An override replaces only the behavior it explicitly defines; unspecified behavior remains governed by the external mechanism and other applicable project rules. Principles of Intellectual Space - An intellectual space SHOULD start small and grow when content or context needs arise. - Information SHOULD be organized so that its applicability to a task can be determined. - Navigation and selection of context SHOULD be distinct from detailed content. - Durable knowledge, current state, and rules governing changes SHOULD be distinguishable as different information classes. - Canonical sources SHOULD remain clear when information has multiple representations. - Useful knowledge and changes in context SHOULD be preserved where people and agents can discover them. - External mechanisms SHOULD remain independent while project-specific rules define how they are applied. Other standards MAY define different representations, storage, navigation, or access mechanisms for intellectual spaces while applying these principles. FISS defines the filesystem-based realization below. FISS — Filesystem Realization Scope FISS defines a minimal filesystem-based organization and navigation model for a project's intellectual space. FISS does not define a project's domain model, architecture, development method, toolchain, task tracker, version-control system, lifecycle, skill format, skill discovery, or skill execution. Methods and artifacts such as DDD, ADR, task trackers, and agent skills are outside FISS. A project MAY organize information about them using FISS. Definitions FISS directory The FISS/ directory in a project root. It is the filesystem entry point defined by this specification. Area A thematically coherent unit in a FISS directory. Single-file area An area represented by one Markdown file. The filename is determined by the project. Composite area An area represented by a directory containing INDEX.md. Container A directory without INDEX.md that groups areas. Its parent index provides navigation to its child areas. Index An INDEX.md file that provides navigation to a FISS directory or composite area. Read condition A statement attached to an index link that specifies when its target MUST be read. Canonical source The source that a project defines as authoritative for a class of information. Override A project rule that changes or explicitly fixes how an external mechanism is applied in that project. Operational artifact An artifact used as an active element of a work process, rather than only as a description. A statement, plan, evidence record, or verification result MAY be an operational artifact. Operational artifacts MAY be located outside the FISS directory while remaining part of the project's intellectual space. Conforming FISS Directory A conforming FISS directory MUST contain: FISS/ ├── INDEX.md └── BOOTSTRAP.md FISS/INDEX.md MUST link to FISS/BOOTSTRAP.md with a read condition requiring it before work begins on the project. FISS/BOOTSTRAP.md is content, not an index. It MUST provide the minimum project context required for initial orientation. Every used area MUST be reachable from FISS/INDEX.md through indexes. A composite area MUST have an INDEX.md. Every index link MUST have a read condition and MUST resolve to an existing target. A container MUST NOT require its own index; its child areas MUST be reachable through the navigation of an enclosing index. Navigation An index MUST contain navigation and information required to select context. It MUST NOT be the primary location for detailed area content. An index link MUST identify its target and state when to read it. The wording of a read condition is not prescribed. An index for a composite area MUST provide navigation to its material and child areas. The same rules apply to root and nested indexes. When an area represented by a file becomes a composite area, all incoming links MUST be updated to its new index. Material in a single-file area SHOULD be organized into modular, logically coherent sections from the outset to facilitate extraction into separate documents or child areas when the content expands. Information Classes FISS defines no required areas other than the root files. A project MAY create areas for the following information classes: Area — Purpose FISS/knowledge/subject/ — Durable knowledge about the subject domain. FISS/knowledge/project/ — Durable knowledge about the project as a system and work object. FISS/state/ — Current information that can affect work. FISS/overrides/ — Project overrides for external mechanisms used by the project. FISS/human/knowledge/ — Human-oriented knowledge that is not required as ordinary agent context. FISS/human/projection/ — Human-oriented projections of canonical knowledge. Subject terms and project terms MAY be stored in separate glossaries. A term with the same meaning in multiple areas SHOULD have one definition and references from other areas. Different meanings of the same word MUST have separate definitions with their applicable area identified. A human projection MUST identify its canonical source or sources. A projection MUST NOT become a canonical source merely by existing. If an external system is a canonical source for current state, FISS MUST NOT create a competing registry of the same information without an explicit source rule. Canonical Sources and Conflicts For information that exists in multiple sources, the project MUST define a canonical source or a rule for selecting one. FISS MUST NOT duplicate a canonical source without a stated purpose and source rule. A derived representation MUST identify its canonical source when omission could cause incorrect use. When sources conflict, an agent or human MUST apply the established source rule. If no rule exists, the conflict requires an explicit project decision. Markdown links and concise explanations are sufficient to express relationships between artifacts. FISS does not require a typed relationship language. Project Overrides Overrides are OPTIONAL. A project with overrides MUST expose FISS/overrides/INDEX.md from FISS/INDEX.md as the override entry point. The entry-point link MUST have a read condition requiring it before use of any skill. FISS/overrides/ is a composite area. A project MUST use it as the override entry point and MUST NOT maintain a parallel override entry point elsewhere. Before using a skill, an agent MUST read the override entry point when it exists. The agent MUST then read only the override documents whose read conditions apply to the current work. Override navigation MUST be based on the subject of a rule, not on a skill name. An override read condition MUST NOT require a particular skill name. A composite FISS/overrides/ area MAY organize overrides for a particular external mechanism within a dedicated container. For example, skill behavior overrides MAY be organized within a skills/ container (FISS/overrides/skills/open-questions.md). Such documents define how the corresponding mechanism is adapted for the project. Overrides MAY define rules for: - behaviors, lifecycles, and state transitions of external mechanisms; - human approval, autonomy, review, and escalation; - artifact locations and naming; - artifact formats and templates; - verification and completion criteria; - agent orchestration and execution limits; - context and memory handling; - project language, interaction style, and author voice. An override replaces only the behavior it explicitly defines. For unspecified behavior, an agent MUST apply, in order: 1. other explicit project rules and canonical sources; 2. an applicable repository convention; 3. the skill default. An override that conflicts with another explicit project rule MUST be resolved using the project's source rules. An agent that cannot apply an override MUST report the condition to a human. An override is a canonical human-readable document. A machine-readable representation MAY exist only as a derivative of that document and MUST NOT be independently maintained as a competing source. Operational Artifacts and Skills A skill that uses a project artifact MUST identify it by logical purpose. A skill MAY define a default filename for an operational artifact. A default filename MUST NOT be treated as a fixed project path. A project MAY define either: - a shared directory for operational artifacts of the current task; or - an explicit full path for a specific logical artifact. An explicit full path for a logical artifact takes precedence over a shared directory and a skill's default filename. If only a shared directory is defined, the resolved path is the shared directory plus the skill's default filename. Before reading or creating an operational artifact, an agent MUST resolve its location in this order: 1. explicit project path for the logical artifact; 2. shared task-artifact directory plus the default filename; 3. repository convention or skill default. Skills that use the same logical operational artifact in one task MUST resolve it to the same location. An agent MUST NOT create a second instance solely because another location was expected. Conflicting locations MUST be resolved using the project's source rules. For parallel tasks, a project MUST provide separate task workspaces or another unambiguous method to distinguish operational artifacts. Agent Entry Point If a project uses AGENTS.md or another root instruction file for AI agents, that file MUST direct agents to FISS/INDEX.md and MUST NOT duplicate space content. Conformance A project conforms to FISS if it satisfies all applicable MUST and MUST NOT requirements in this document. License FISS is distributed under the MIT license. Copyright © 2026 Andrey Vorozhko.