--- name: Arco Sitemapper version: 0.1.1 status: draft owner: Stoirm Arnold last_updated: 30-Sep-2026 --- # Arco Sitemapper ## Purpose Sitemapper is an Arco Function that maps the structure of a bounded content location and maintains a simple structural site map for that location. A site may be a folder, directory, SharePoint site, Google Drive folder, repository subtree or equivalent hierarchical content location. Sitemapper records what exists. It does not add descriptions, reinterpret the purpose of folders or restructure content merely to make it look cleaner. ## Function classification Sitemapper is a Function, not a Module. It performs a bounded operation against an existing content location and does not own an independent domain of durable organisational knowledge. ## Invocation A user may invoke Sitemapper in natural language against the location they are currently working in or against a specified location. Examples: - `Run Sitemapper here.` - `Map this folder.` - `Update the Client Operations site map.` - `Run Sitemapper against Finance.` The system should resolve the target location before making changes. ## Canonical output The site map for a location is stored at the root of that location. The filename follows: ```text -site-map.md ``` The filename should use the normal Arco machine-readable filename convention. Example: ```text Client Operations/ └── client-operations-site-map.md ``` ## Site map format A site map is intentionally simple. It contains a tree representing the actual structure of the mapped location. Example: ```text # Client Operations Site Map client-operations/ ├── clients/ │ ├── active/ │ └── archived/ ├── delivery/ │ ├── templates/ │ └── reports/ ├── operations/ └── client-operations-site-map.md ``` The site map must not contain: - folder descriptions; - commentary; - recommendations; - ownership information; - status information; - inferred purpose; - duplicated Governance information. The map represents structure only. ## Operating behaviour When Sitemapper is run: 1. Resolve the target site. 2. Inspect the current structure within that site. 3. Identify whether a canonical site map already exists. 4. Generate a tree that reflects the actual current structure. 5. Create or update the canonical `-site-map.md`. 6. Check whether the parent site has its own canonical site map. 7. If a parent map exists, ensure the mapped child site is represented correctly within it, subject to applicable Governance. 8. If no parent map exists, do not silently create a new higher-level site map outside the invocation scope. Where appropriate, propose creation or update through the applicable approval route. ## Mapping principles ### Map reality first Sitemapper must represent the structure that actually exists. It must not rename, move, merge or delete files or folders as part of ordinary mapping. ### No restructuring for aesthetics An unconventional or untidy structure is not, by itself, sufficient reason to change it. Sitemapper may identify a genuine structural issue during a run, but any proposed restructuring must remain separate from the canonical site map and follow applicable Governance. ### Structure only The site map is not documentation about what each folder means. If descriptive documentation is required, it belongs in an appropriate separate maintained source. ### Preserve provider independence Sitemapper should behave consistently across supported storage environments. The underlying provider may expose folders, directories, sites or repository paths differently, but the canonical output remains a simple hierarchy. ## Parent-site behaviour Site maps may form a hierarchy. For example: ```text organisation/ ├── finance/ │ └── finance-site-map.md ├── client-operations/ │ └── client-operations-site-map.md └── organisation-site-map.md ``` A site map owns the structure beneath its own mapped root. Where a parent site map exists, a child site should appear within the parent tree, but the parent map should not duplicate the complete contents of the child's own map unless that structure naturally falls within the chosen mapping depth. Sitemapper should therefore prefer: ```text organisation/ ├── finance/ ├── client-operations/ └── organisation-site-map.md ``` rather than reproducing every nested descendant from independently maintained child maps at every higher level. ## Governance Creating or updating a site map within a location should follow the permissions applicable to that location. Sitemapper does not define its own approval rules. Where the Function needs to change a maintained artefact outside the user's authorised scope, it should route the proposed change through the applicable Governance mechanism. If no parent site map exists and creation would affect a higher-level location, Sitemapper should identify the relevant owner or authority and submit or prepare the appropriate proposal rather than silently creating it. ## Recommendations and structural issues Sitemapper may detect issues while mapping, such as: - duplicated folders; - inconsistent hierarchy; - apparently misplaced content; - excessive nesting; - overlapping structures; - missing parent mapping. These findings must not be written into the canonical site map. Where useful, they may be returned separately to the user as observations or proposed actions. No structural change should be made solely because an alternative structure appears cleaner or more aesthetically consistent. ## Scope and depth By default, Sitemapper should map enough of the target hierarchy to provide a useful structural view without unnecessarily traversing unrelated or extremely deep content. A user may request a deeper or shallower map. Where child locations maintain their own canonical site maps, Sitemapper may treat those child sites as bounded nodes rather than repeatedly expanding their full structure into every parent map. ## Existing capability first Before creating a new local Function intended to perform substantially similar structural mapping, Arco should first determine whether Sitemapper can be used, configured or extended for the requirement. Follow the general capability-creation sequence: ```text discover ↓ reuse ↓ configure ↓ extend ↓ create ``` ## Boundaries Sitemapper does not: - own the underlying files or folders; - define organisational information architecture; - replace Governance; - document the purpose of folders; - act as a file-cleaning Function; - perform Defrag; - automatically reorganise content; - require every location in a deployment to have a site map. A site map should exist where maintaining one provides useful structural visibility. ## Canonical references [arco-governance.md](https://drive.google.com/file/d/1JmdNUNPVJLxFbNQKYS3cJTnDPJ6hRvxb/view). ## Changelog | Date | Version | Change | Approved by | Changed by | |---|---|---|---|---| | 30-Sep-2026 | 0.1.1 | Restored canonical provider-link references. | Stoirm Arnold — Defrag invocation | Codex Work | | 19-Sep-2026 | 0.1.0 | Created the initial Sitemapper Function draft, defining provider-agnostic site mapping, canonical `-site-map.md` output, tree-only content, parent-map behaviour, Governance routing and the no-restructuring-for-aesthetics rule. | Stoirm Arnold | GPT-5.6 Sol |