LOGIC OR NOT — Organizar la información de un proyecto
Project Information Architecture Instructions — v0.1.2-CANDIDATE
Canonical Product Key: SP-GEN:P019
Governance Class: GOV-PROJECT
Modifiers: PROJECT_CONTEXT | PERSISTENT_STATE


PURPOSE
Mantener una arquitectura de información recuperable, con autoridad semántica separada de almacenamiento físico, mínima para el contexto y escalable a repositorio durable sólo cuando hace falta.


SEMANTIC MANIFEST FIRST
El Information Architecture Manifest es el router semántico del Project, no un inventario de carpetas.
Debe ser CURRENT, versionado y único para su scope.
Cada information_class material declara:
class_id, role, semantic_authority_ref, owner, sensitivity/access rule, lifecycle rule, read_route, write/writeback_route y storage_role.


AUTHORITY
Ubicación, recencia, nombre, provider metadata o connector availability nunca crean autoridad.
La autoridad semántica pertenece al Project/domain authority designado.
El storage registry, cuando existe, gobierna identidad/locator/persistencia física dentro de su contrato; no duplica decisiones semánticas.


STORAGE ROUTING GATE
HOST_LOCAL_BOUNDED:
usar cuando un state canónico acotado + referencias host-local directas bastan. P082 NOT_REQUIRED.


EXTERNAL_DURABLE_REPOSITORY / HYBRID:
activar P082 JIT cuando múltiples objetos durables, external storage elegido, registry/direct locators, multi-object evidence/history, relations, provider-specific ownership/recovery, multi-writer conflict control o portable stable identity sean materialmente necesarios.
Si la edición compatible no existe/observable: STORAGE_ADAPTER_REQUIRED / HOLD; semántica puede continuar sin inventar implementación física.


P082 BINDING
Cuando ACTIVE, declarar exact:
provider, provider_surface, ownership_model, writer_model, adapter_edition_ref, storage_manifest_ref, operational_registry_ref.
No heredar proof entre providers/ownership/writer models.


RETRIEVAL
P082 ACTIVE: Project IA manifest → operational registry → object_id/current_version/lifecycle → direct_locator → CURRENT object.
No folder traversal como ruta primaria.
HOST_LOCAL_BOUNDED: manifest → exact local authority/reference; tampoco recorrer carpetas por defecto si el locator ya es conocido.


REGISTRATION-FIRST INGEST
Todo durable object nuevo/importado bajo P082 ACTIVE:
classify semantic class → assign/preserve stable object_id → choose governed destination → physical write/move → register authoritative master registry → derived indexes if used → readback object_id/locator/metadata → semantic adoption only when domain rules permit.
Si la registración falla después del write físico: objeto = UNREGISTERED/PENDING_INGEST; no autoridad automática, no ocultar orphan y no afirmar CURRENT.


WRITEBACK TRANSACTION
Antes: leer manifest_version + registry current_version.
Aplicar cambio en la autoridad propietaria.
Cambios físicos: write/move → readback → registry update → registry readback.
Cambios semánticos: IA manifest/domain state update según autoridad.
No promover una copia a CURRENT por ubicación/recencia.
Version/locator conflict => CONFLICT/HOLD antes de dependent retrieval.


CURRENT / HISTORY
Un solo CURRENT semántico por object/scope. Physical snapshots/shortcuts/history no crean copias canónicas. Supersession preserva object identity y lineage.


MIGRATION
Preservar object_id, semantic authority, owner/access, lifecycle y lineage. Cambiar provider locator sólo tras destino/readback + registry reconciliation. Provider history es recovery evidence, no semantic authority.


PRIVACY / PERMISSIONS
No mover, compartir, cambiar ownership o permisos sin autoridad aplicable. Move y share son efectos distintos.


VERIFICATION
Reportar manifest_version/status, semantic authority, storage mode, exact adapter binding si ACTIVE, registry/locator health, pending ingest/conflicts, ownership/access y observabilidad de writeback.