Parte 60 · Clase 600 de 830

ARQ-600 · Proyecto de edificio tecnológico crítico

Parte 60 · Fase II · Clase desarrollada · Incorporada en v0.32.0.

Prerrequisitos conceptuales: ARQ-599. Sin calendario. Los casos, parámetros, capacidades y dimensiones son ficticios salvo antecedentes expresamente atribuidos. Material educativo: no constituye proyecto ejecutable, certificación, protocolo clínico o de bioseguridad, plan de emergencia, cálculo firmado ni habilitación profesional. Revisión externa especializada pendiente.

Pregunta central

¿Cómo cerrar un anteproyecto tecnológico integrando misión, carga, redundancia, laboratorio, seguridad y expansión sin fingir que una matriz equivale a validación?

Resultado y continuidad

Al terminar podrás explicar la tipología como sistema, reconstruir el caso cuantitativo, identificar al menos una interfaz crítica y separar resultado, hipótesis y evidencia pendiente. La Parte 61 continuará con industria, logística y plantas productivas, manteniendo fronteras explícitas.

1. El tipo arquitectónico como sistema

El proyecto final integra dos familias difíciles: infraestructura digital y espacios científicos. No las mezcla en una sola sala; construye interfaces entre cargas críticas, laboratorios, soporte, energía, enfriamiento, logística y operación.

Una forma útil de estudiar el tema es separar objeto, función, estado, magnitud y evidencia. El objeto indica qué componente o espacio se analiza; la función explica por qué existe; el estado fija la condición temporal; la magnitud define qué se mide o calcula; la evidencia establece qué permite defender la conclusión. Si falta alguna de esas piezas, la frase suele sonar más precisa de lo que realmente está respaldada.

2. Organización espacial, técnica y operativa

TECH-INT-01 tiene 12.000 m² brutos: 4.000 sala TI, 2.000 laboratorios, 1.500 soporte técnico, 1.200 circulación/control, 1.000 oficinas/colaboración, 900 muelle/almacenamiento y 1.400 infraestructura/estructura. La suma cierra, pero la geometría y sistemas deben verificarlo.

El proyecto define tres estados: operación normal, mantenimiento y ampliación. Cada estado debe mostrar qué rutas y capacidades permanecen. Las reservas de energía y frío no se suman si comparten el mismo equipo.

La defensa final separa indicadores: PUE para energía, redundancia para topología, clasificación de limpieza cuando corresponda, y evaluación de riesgo para laboratorio. Ninguno sustituye a los otros.

La planta, la sección y la secuencia de uso deben leerse juntas. Un espacio puede caber en área y fallar por altura, recorrido, mantenimiento, ruido, vibración o seguridad. Del mismo modo, una capacidad agregada puede ocultar un cuello de botella local. Por ello los modelos de esta clase se comprueban por balance y luego se limitan explícitamente.

3. Interfaces que deben coordinarse

Las interfaces son lugares donde dos decisiones dependen una de otra: público-producción, colección-instalaciones, rack-enfriamiento, laboratorio-extracción, equipo-estructura, seguridad-operación. Cada interfaz necesita versión, posición, función, estado y responsable. Resolver un cruce geométrico no verifica automáticamente su desempeño.

En un proyecto real también hay interfaces documentales: especificación, modelo, plano, plan de pruebas y manual de operación deben referir la misma configuración. Si cambia una base, se reabren las evidencias dependientes en lugar de mantener una marca de “aprobado” heredada.

4. Caso trabajado

TECH-INT-01 suma 12.000 m². Si 300 m² pasan de oficinas a soporte técnico, el total se mantiene; soporte=1.800 y oficinas=700. Deben reabrirse ocupación, colaboración, rutas y capacidad técnica.

Qué demuestra y qué no

Demuestra las relaciones aritméticas o geométricas declaradas dentro de las hipótesis. No verifica seguridad integral, incendio, accesibilidad reglamentaria, estructura completa, continuidad, conservación, bioseguridad, ciberseguridad, operación o autorización real. Los criterios de aceptación deben identificarse en las fuentes y jurisdicción correspondientes.

5. Construcción, operación y mantenimiento

Diseñar esta tipología exige considerar estados temporales. Montaje, mantenimiento, cambio de exposición, sustitución de equipos, limpieza, calibración o ampliación pueden ser más exigentes que el estado final. Las rutas técnicas deben existir cuando el edificio está ocupado y no solo en un plano vacío.

La mantenibilidad requiere espacio de acceso, aislamiento de servicios, piezas reemplazables, información actualizada y posibilidad de volver a verificar. Una solución muy compacta puede reducir superficie y aumentar indisponibilidad futura. El programa enseña a hacer visible ese compromiso, no a elegirlo automáticamente.

6. Errores de razonamiento frecuentes

Errores típicos son sumar capacidades de etapas consecutivas; promediar datos que representan posiciones distintas; tratar una guía internacional como regulación local; confundir indicador con resultado de servicio; suponer que duplicar componentes elimina dependencias compartidas; y declarar “flexible” o “redundante” una configuración sin ensayar estados.

También es un error corregir una incompatibilidad cambiando silenciosamente el dato base. Una modificación crea una variante identificada y obliga a repetir las verificaciones afectadas. La trazabilidad forma parte del proyecto.

7. Preguntas de profundización

• ¿Qué dato del programa podría cambiar la geometría completa?

• ¿Qué estado temporal es más exigente que el uso ordinario?

• ¿Qué punto común puede invalidar una supuesta redundancia?

• ¿Qué magnitud sería peligroso convertir en un promedio?

• ¿Qué evidencia debe provenir de especialista, ensayo o autoridad?

Práctica independiente

Proyecto 10.000 m²: 3.200 TI, 1.800 labs, 1.300 soporte, 1.100 circulación/control, 900 oficinas, 700 logística y 1.000 infraestructura. Comprueba suma. Luego traslada 200 m² de TI a infraestructura y explica qué cambia.

Además del cálculo, escribe dos conclusiones que sí estén respaldadas, dos que no puedas sostener y una comprobación que debería realizar un especialista antes de construir u operar.

Transferencia

El método puede trasladarse a otras tipologías, pero no sus parámetros. Teatro, museo, centro de datos y laboratorio comparten necesidad de coordinación y evidencia, pero sus cargas, riesgos, operación y referencias son distintos. La transferencia correcta conserva preguntas y reemplaza datos, normas y responsables.

Autoevaluación

Puedes avanzar cuando: 1) reconstruyes el caso sin mirar la solución; 2) distingues lo calculado de lo supuesto; 3) identificas una interfaz; 4) nombras un estado temporal relevante; 5) explicas qué evidencia falta; y 6) evitas presentar una fuente institucional como autorización universal.

Figura 600. Esquema conceptual original. No constituye plano ejecutable, certificación de conservación, diseño de data center, laboratorio aprobado ni protocolo de seguridad.

Decisión pedagógica y posición curricular

Por qué existe

Esta clase existe para resolver una necesidad concreta del recorrido: ¿Cómo cerrar un anteproyecto tecnológico integrando misión, carga, redundancia, laboratorio, seguridad y expansión sin fingir que una matriz equivale a validación?

Por qué está exactamente aquí

Cierra la Parte 60: integra lo producido en ARQ-599 · Continuidad, mantenimiento y expansión para responder «¿Cómo cerrar un anteproyecto tecnológico integrando misión, carga, redundancia, laboratorio, seguridad y expansión sin fingir que una matriz equivale a validación?». La transición hacia ARQ-601 · Fábrica como flujo de proceso transfiere el método y la disciplina de evidencia, no los datos o parámetros particulares de esta parte.

• Prerrequisitos: ARQ-599
• Capacidad que introduce: Al terminar podrás explicar la tipología como sistema, reconstruir el caso cuantitativo, identificar al menos una interfaz crítica y separar resultado, hipótesis y evidencia pendiente. La Parte 61 continuará con industria, logística y plantas productivas, manteniendo fronteras explícitas.
• Clases o experiencias que dependen de ella: ARQ-601

flowchart LR
    A["Prerrequisitos · ARQ-599"] --> B["ARQ-600 · necesidad y fundamento"]
    S["Fuentes · DC-ISO22237-1 ISO/IEC 22237-1:2021 — Data centre facilities and infrastructures — Part 1: General concepts + WORK-PUE…"] --> B
    B --> C["Actividad auténtica"]
    C --> D["Evidencia auditable"]
    D --> E["Continuidad · ARQ-601"]

El diagrama permite comprobar una relación que el texto lineal oculta con facilidad: esta clase recibe capacidades previas, toma decisiones apoyadas por fuentes, exige una experiencia y produce evidencia que habilita trabajo posterior. No representa un procedimiento de obra.

Resultado observable, evidencia y evaluación

1. Identificar y delimitar las condiciones necesarias para responder la pregunta central de proyecto de edificio tecnológico crítico.
2. Producir y comprobar la evidencia declarada por la clase: Al terminar podrás explicar la tipología como sistema, reconstruir el caso cuantitativo, identificar al menos una interfaz crítica y separar resultado, hipótesis y evidencia pendiente. La Parte 61 continuará con industria, logística y plantas productivas, manteniendo fronteras explícitas.
3. Justificar una decisión de proyecto de edificio tecnológico crítico mediante fuentes, supuestos, alternativas y límites explícitos.

Actividad, evidencia y criterio de aceptación

Actividad: Proyecto 10.000 m²: 3.200 TI, 1.800 labs, 1.300 soporte, 1.100 circulación/control, 900 oficinas, 700 logística y 1.000 infraestructura. Comprueba suma. Luego traslada 200 m² de TI a infraestructura y explica qué cambia.

Evidencia mínima: Al terminar podrás explicar la tipología como sistema, reconstruir el caso cuantitativo, identificar al menos una interfaz crítica y separar resultado, hipótesis y evidencia pendiente. La Parte 61 continuará con industria, logística y plantas productivas, manteniendo fronteras explícitas.

Archivo sugerido: evidence/ARQ-600/evidencia.md.

Criterio de aceptación: la entrega se acepta cuando:

• La entrega responde explícitamente a la pregunta: ¿Cómo cerrar un anteproyecto tecnológico integrando misión, carga, redundancia, laboratorio, seguridad y expansión sin fingir que una matriz equivale a validación?
• La actividad conserva las fronteras del caso y permite reconstruir el procedimiento: Proyecto 10.000 m²: 3.200 TI, 1.800 labs, 1.300 soporte, 1.100 circulación/control, 900 oficinas, 700 logística y 1.000 infraestructura. Comprueba suma. Luego traslada 200 m² de TI a infraestructura y explica qué cambia.
• Cada afirmación externa puede seguirse hasta una fuente, su alcance consultado y su límite.
• La evidencia deja disponible una entrada comprobable para ARQ-601.
• Errores típicos son sumar capacidades de etapas consecutivas; promediar datos que representan posiciones distintas; tratar una guía internacional como regulación local; confundir indicador con resultado de servicio; suponer que duplicar componentes elimina dependencias compartidas; y declarar “flexible” o “redundante” una configuración sin ensayar estados. También es un error corregir una incompatibilidad cambiando silenciosamente el dato base.

La rúbrica común complementa estos criterios; no los reemplaza. Una entrega puede superar un promedio y continuar pendiente si oculta una condición crítica.

Trazabilidad de las decisiones

La tabla permite auditar las relaciones; la explicación, el caso y la práctica de la clase siguen siendo la documentación principal.

Autoevaluación, recuperación y continuidad

Errores diagnósticos

Antes de avanzar, comprueba si puedes reconstruir cada resultado sin mirar la solución, señalar qué evidencia lo sostiene y nombrar una condición que obligaría a revisar tu decisión. Conserva la primera versión, la objeción recibida y la revisión.

Conexión siguiente: La continuidad inmediata es ARQ-601 · Fábrica como flujo de proceso; conserva el método y vuelve a verificar datos y límites.

Fuentes y alcance de uso

[DC-ISO22237-1] ISO/IEC 22237-1:2021 — Data centre facilities and infrastructures — Part 1: General concepts

ISO/IEC. https://www.iso.org/standard/78550.html

Consulta: Ficha pública de la edición 2021. Apoyo: Principios generales, modelos de referencia, disponibilidad, seguridad y eficiencia durante la vida del centro de datos. Límite: No se leyó íntegramente la norma ni se asigna una clase de disponibilidad al ejercicio.

[DC-ISO30134-2] ISO/IEC 30134-2:2026 — Power usage effectiveness (PUE)

ISO/IEC. https://www.iso.org/standard/30134-2

Consulta: Ficha pública de la edición 2, publicada en enero de 2026. Apoyo: Definición de PUE, medición de energía y necesidad de fronteras coherentes. Límite: La clase usa números ficticios y no realiza una medición conforme completa.

[LAB-NIH-DRM] NIH Design Requirements Manual

National Institutes of Health. https://orf.od.nih.gov/TechnicalResources/Pages/DesignRequirementsManual.aspx

Consulta: Portal oficial del DRM; se consultaron alcance y apartados actualizados de predesign de laboratorios. Apoyo: Programación, relaciones funcionales, flexibilidad, seguridad, tipos de laboratorio y crecimiento futuro. Límite: Manual institucional estadounidense; no se trasladan requisitos como legislación chilena.

[LAB-BMBL6] Biosafety in Microbiological and Biomedical Laboratories (BMBL), 6th Edition

CDC / NIH. https://www.cdc.gov/labs/bmbl/index.html

Consulta: Página oficial de la sexta edición, publicada en 2026. Apoyo: Evaluación de riesgo basada en protocolos y relación entre prácticas, contención y condiciones del laboratorio. Límite: BMBL es una guía consultiva en su ámbito; no se asigna nivel de bioseguridad a un proyecto ficticio ni se sustituye evaluación profesional.