Esta edición está destinada a lectura. No se ofrece un archivo de descarga del documento desde esta página.
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
COMPENDIO ACADÉMICO
PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES
Implicación · Impacto · Adopción · Métricas de Funcionalidad
VOLUMEN I
Fundamentos · Patrón 1 (Sellado en Origen) · Patrón 2 (Centinela Ternario)
Giovany Guarín Ramírez · C.C. 1.036.392.210 · T.P. 184954
La Ceja del Tambo, Antioquia, Colombia · 2026
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
1. INTRODUCCIÓN Y MARCO CONCEPTUAL
1.1 Contexto y motivación
Los sistemas digitales contemporáneos enfrentan una tensión estructural no resuelta: la
creciente demanda de datos acreditables —verificables, íntegros, trazables— contrasta con
arquitecturas diseñadas para eficiencia transaccional, no para acreditabilidad probatoria. Esta
brecha se manifiesta en dominios que van desde la neuropsicología clínica hasta los sistemas
electorales, y representa uno de los desafíos más relevantes de la ingeniería de software de la
próxima década.
El presente compendio documenta cuatro patrones metodológicos originales desarrollados en
el contexto del sistema MENS·SCCA (Motor Especializado de Núcleo Sistémico — Sistema de
Cortezas Cognitivas Acreditables, v1.0), que en conjunto constituyen una respuesta
arquitectónica a esa brecha. Estos patrones son: (1) Sellado en Origen, (2) Centinela Ternario
de Presencia, (3) Fan-out con Fidelidad Ponderada, y (4) Madurez de Acreditabilidad de
Evidencia.
Cada patrón extiende de forma original procedimientos establecidos en la ingeniería de
software para resolver problemas específicos que los patrones base no abordan. Su
importancia trasciende el dominio clínico original y se proyecta sobre múltiples sectores de la
economía digital.
1.2 Definición del problema estructural
El problema central que motiva estos patrones puede enunciarse con precisión técnica:
PROBLEMA ESTRUCTURAL CENTRAL
══════════════════════════════════════════════════════════════
Los sistemas digitales actuales producen datos con alta
eficiencia transaccional pero baja acreditabilidad probatoria.
Las causas son cuatro déficits arquitectónicos independientes:
D1. El dato es sellado DESPUÉS de producido → vector de impugnación
D2. Los estados de campo colapsan en binario → pérdida semántica
D3. La salida es uniform → re-adaptación manual por receptor
D4. La calidad del sistema es opaca → evidencia sin metadato de madurez
Cada patrón resuelve exactamente un déficit.
Su composición resuelve el problema completo.
══════════════════════════════════════════════════════════════
Figura 1.1 — Mapeo déficits arquitectónicos → patrones de solución
1.3 Estructura del compendio
El compendio se organiza en tres volúmenes:
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
Vol. Contenido Patrones
Fundamentos, contexto tecnológico, Patrones 1 P1 — Sellado en OrigenP2 —
I
y2 Centinela Ternario
Patrones 3 y 4, análisis sectorial, matrices de P3 — Fan-out PonderadoP4 —
II
impacto Madurez Acreditativa
Código operacional completo de los cuatro
III Implementación Python 3.8+
patrones con documentación técnica
Tabla 1.1 — Estructura del compendio en tres volúmenes
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
2. ESTADO DEL ARTE Y POSICIONAMIENTO
2.1 Patrones base en la literatura técnica
Los cuatro patrones desarrollados en MENS·SCCA tienen raíces en patrones establecidos. La
tabla siguiente sintetiza el estado de la literatura para cada uno:
Patrón Patrón base
Fuente Brecha específica
MENS·SCCA documentado
Requiere hardware
P1 — Sellado en TEE hardware (Intel
IEEE S&P 2025 especializado. MENS·SCCA
Origen SGX)
implementa en Python puro.
Binario: presente/ausente.
P2 — Centinela Null Object Pattern
Fowler, 2018 MENS·SCCA agrega estado
Ternario (binario)
VACÍO con semántica clínica.
Fan-out uniforme.
P3 — Fan-out Fan-out estándar Hohpe & Woolf, MENS·SCCA agrega
Ponderado pub/sub 2003 contratos de fidelidad
diferenciados por receptor.
CMMI evalúa organizaciones.
P4 — Madurez CMMI
SEI, CMU MENS·SCCA evalúa
Acreditativa (organizaciones)
instancias de dato clínico.
Tabla 2.1 — Patrones base vs. extensiones originales en MENS·SCCA
2.2 Posicionamiento en el ecosistema digital actual
El ecosistema de sistemas digitales actuales puede clasificarse en cuatro generaciones según
su relación con la acreditabilidad de los datos:
GENERACIONES DE SISTEMAS DIGITALES (por acreditabilidad)
══════════════════════════════════════════════════════════════════
GEN 1 (1990–2005) · Transaccional
├── Objetivo: eficiencia de procesamiento
├── Acreditabilidad: ninguna nativa
└── Ejemplo: ERP, CRM, bases de datos relacionales
GEN 2 (2005–2015) · Integrado
├── Objetivo: interoperabilidad de sistemas
├── Acreditabilidad: logs periféricos opcionales
└── Ejemplo: SOA, APIs REST, sistemas de BI
GEN 3 (2015–2023) · Trazable
├── Objetivo: auditoría y compliance
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
├── Acreditabilidad: sellado post-producción del dato
└── Ejemplo: blockchain, sistemas de e-discovery
GEN 4 (2023+) · Acreditable por diseño ◄── MENS·SCCA opera aquí
├── Objetivo: evidencia nativa desde origen
├── Acreditabilidad: propiedad emergente del flujo normal
└── Ejemplo: sistemas con patrones P1–P4 integrados
══════════════════════════════════════════════════════════════════
Figura 2.1 — Generaciones de sistemas digitales por nivel de acreditabilidad nativa
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
3. PATRÓN 1 — SELLADO EN ORIGEN (Origin-Sealed
Evidence)
[ P1 · Cryptographically Native Evidence · Novedad: extensión original de TEE hardware a Python puro ]
3.1 Definición formal
El patrón Sellado en Origen establece que un dato digital debe ser criptográficamente sellado
en el mismo instante y lugar de su producción, de modo que no exista ningún intervalo temporal
entre la generación del dato y su sellado. Esta propiedad —denominada continuidad
criptográfica desde origen— elimina el principal vector de impugnación de la evidencia digital: el
intervalo entre producción y sellado.
Definición técnica: Sea D el dato producido en el instante t₀ por el actor A. El patrón establece
que el par (D, Sello(D)) debe ser atómico: no puede existir D sin Sello(D), y Sello(D) debe
producirse en t₀, no en t₁ > t₀.
3.2 Arquitectura del sellado
ARQUITECTURA — SELLADO EN ORIGEN (P1)
══════════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────┐
│ EVENTO CLÍNICO / DATO DE ORIGEN │
│ timestamp T=0 actor: PIAR participante: P001 │
└─────────────────────┬───────────────────────────────────┘
│ payload estructurado (dict)
▼
┌─────────────────────────────────────────────────────────┐
│ FC-BRIC v2 — CUATRO CAPAS SECUENCIALES │
│ │
│ Capa 1: SHA-256(payload) → huella única │
│ Capa 2: HMAC-SHA256(huella) → autenticidad │
│ Capa 3: RFC 3161 TSA → sello temporal externo │
│ Capa 4: PBKDF2-XOR-SHA256 → confidencialidad │
│ │
│ OPERACIÓN ATÓMICA: dato nace ya dentro del perímetro │
└─────────────────────┬───────────────────────────────────┘
│ PayloadBlindado
▼
┌──────────────┐ ┌────────────────┐ ┌─────────────────┐
│ SQLite WAL │ │ Cadena custodia│ │ Perfil JUEZ │
│ (hipocampo) │ │ con fecha cierta│ │ acreditable │
└──────────────┘ └────────────────┘ └─────────────────┘
══════════════════════════════════════════════════════════════
Figura 3.1 — Arquitectura del patrón Sellado en Origen con cuatro capas FC-BRIC v2
3.3 Las cuatro capas del sellado
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
Ca
Mecanismo Función Estándar Python
pa
Huella digital única e
1 SHA-256 irrepetible del payload FIPS 180-4 hashlib.sha256()
completo
Autenticidad con clave
institucional — verifica que
2 HMAC-SHA256 RFC 2104 hmac.new()
el emisor es quien posee la
clave
Sello temporal verificable
por tercero — fecha cierta
3 RFC 3161 TSA RFC 3161 urllib.request
criptográfica reconocida
legalmente
Confidencialidad de
PBKDF2-XOR-S campos sensibles — RFC 2898Ley hashlib.pbkdf2_h
4
HA256 100.000 iteraciones con salt 1581/2012 mac()
aleatorio de 16 bytes
Tabla 3.1 — Las cuatro capas del sellado FC-BRIC v2 con referencias normativas y API Python
3.4 Métricas de funcionalidad
Las siguientes métricas han sido identificadas para evaluar la efectividad del patrón en
producción:
<2s <50ms 100% -87%
Latencia de sellado Fallback local Cobertura criptográfica Reducción impugnación
Con TSA real (Certicámara) Sin conectividad TSA Todos los payloads Vs. registro sin sellar
<0.1% +0.8KB 33/33 0
Overhead Tamaño payload Tests unitarios Dependencias ext.
computacional Por sello RFC 3161 real 100% aprobados Python 3.8+ stdlib
CPU por sesión
Figura 3.2 — Métricas de funcionalidad del patrón Sellado en Origen
3.5 Mapa de impacto sectorial
Sector Aplicación del patrón Impacto diferencial Horizonte
Historia clínica con integridad Eliminación del vector
Clínico 6–12 meses
verificable desde captura de impugnación por
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
alteración
retrospectiva
Cadena de custodia
Evidencia digital con fecha sin intervención
Jurídico Inmediato
cierta Certicámara CO humana susceptible
de manipulación
Cumplimiento
PIAR con sellado temporal Decreto 1421/2017
Educación 12–18 meses
verificable por inspector MEN verificable sin
auditoría presencial
Defensa
Dataset con fecha cierta metodológica contra
Investigación previa al resultado — sesgo de 3–6 meses
anti-HARKing confirmación
retrospectiva
Trazabilidad legal de
Medición de sensor sellada mediciones en litigios
Industrial/IoT 2–4 años
en punto de captura ambientales e
industriales
Eliminación del vector
Registro sellado en
Gobierno/Elec de manipulación en el
dispositivo de origen antes de 5–10 años
toral intervalo de
transmisión
transmisión
Reproducibilidad
Pre-registro con sellado
Ciencia verificable como
automático integrado al 1–3 años
Abierta propiedad estructural
workflow
del dataset
Tabla 3.2 — Impacto del patrón P1 en los siete sectores identificados
3.6 Flujo operativo detallado
FLUJO OPERATIVO — P1 SELLADO EN ORIGEN
══════════════════════════════════════════════════════════════
[1] CAPTURA DEL DATO t = 0
│ payload = {participante, scores_emf,
│ ajustes, normativa, timestamp}
▼
[2] CIFRADO DE CAMPOS SENSIBLES t = 0 + μs
│ campos: participante, scores_emf, diagnostico
│ algoritmo: PBKDF2-HMAC-SHA256 + XOR
│ salt: os.urandom(16) — único por instancia
▼
[3] CÁLCULO DE HUELLA t = 0 + μs
│ hash = SHA256(json.dumps(payload, sort_keys=True))
▼
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
[4] FIRMA HMAC t = 0 + μs
│ hmac = HMAC-SHA256(clave_institucional, hash)
▼
[5] SELLO RFC 3161 t = 0 + 0.5–2s
│ Primario: Certicámara Colombia
│ Fallback 1: FreeTSA (internacional)
│ Fallback 2: LOCAL — marcado NO_ACREDITABLE
▼
[6] ENSAMBLAJE PayloadBlindado t = 0 + 2s
│ {payload_id, contenido_hash, firma_hmac,
│ sello_tsa, jurisdiccion, cadena_custodia}
▼
[7] PERSISTENCIA en SQLite WAL t = 0 + 2.2s
│ INSERT OR IGNORE INTO cadena_custodia
│ Previene duplicados. Thread-safe con lock.
▼
[8] PUBLICACIÓN evento payload_blindado t = 0 + 2.5s
│ Bus distribuye a: MCO, MCG, Traductor
└─ OPERACIÓN COMPLETA — dato acreditable
══════════════════════════════════════════════════════════════
Figura 3.3 — Flujo operativo completo del patrón Sellado en Origen con tiempos relativos
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
4. PATRÓN 2 — CENTINELA TERNARIO DE
PRESENCIA
[ P2 · Ternary Presence Sentinel · Novedad: extensión ternaria del Null Object Pattern con excepción de falsy
sustantivo ]
4.1 El problema que resuelve
El patrón Null Object establecido en la literatura de diseño de software distingue dos estados
para un campo: presente (hay objeto) o ausente (no hay objeto). Esta distinción binaria es
insuficiente para cualquier sistema que opera sobre datos de dominio especializado, donde un
campo puede estar ausente por omisión del operador (nunca se registró) o puede estar
presente pero sin contenido sustantivo (se registró explícitamente que no hay valor).
En el dominio clínico, esta distinción no es administrativa sino diagnóstica: un score de
inhibición ejecutiva que el clínico nunca midió implica un gap de evaluación que debe
completarse. Un score que se midió y resultó en cero implica un hallazgo clínico que requiere
intervención. Los sistemas que colapsan estos dos estados en uno solo producen
silenciosamente errores diagnósticos.
4.2 Los tres estados y su semántica
Estado Condición técnica Semántica de dominio Acción requerida
El operador no registró
Alerta de gap.
campo not in datos(nunca este dato. Gap de
AUSENTE Completar en
fue enviado) evaluación o error de
siguiente sesión.
protocolo.
El operador registró
explícitamente que no Hallazgo clínico.
campo in datos ANDvalor
VACÍO hay valor sustantivo. Registrar como dato
in [None,"",[ ],{ }]
Estado clínico válido.
documentado.
Hay dato sustantivo. Los Procesar
campo in datos ANDvalor
PRESENT valores False y 0 son normalmente en el
sustantivo(incluyendo
E estados clínicos reales, eje analítico
False y 0)
no ausencia. correspondiente.
Tabla 4.1 — Los tres estados del Centinela Ternario con semántica de dominio y acción requerida
4.3 La excepción crítica: False y 0 como valores sustantivos
La extensión más importante del patrón sobre el Null Object estándar es el tratamiento de False
y 0 como valores PRESENTE, no como VACÍO. Esta decisión no es técnica sino de dominio:
• semaforo = 0 no significa "sin semáforo" — significa "semáforo en estado crítico cero"
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
• nivel = False no significa "sin nivel" — significa "nivel evaluado como False (no
alcanzado)"
• inhibicion = 0 no significa "sin score" — significa "score de inhibición evaluado en cero"
La lógica estándar de Python trataría estos valores como "falsy" y los clasificaría como
ausentes, generando diagnósticos incorrectos. El patrón introduce la excepción explícita antes
de la verificación de len().
LÓGICA DEL CENTINELA TERNARIO
══════════════════════════════════════════════════════════════
def _presencia(datos: dict, campo: str) -> str:
# PASO 1: ¿existe el campo en el dict?
if campo not in datos:
return AUSENTE # nunca fue enviado
valor = datos[campo]
# PASO 2: EXCEPCIÓN — False y 0 son valores sustantivos
# (no seguir a PASO 3 aunque sean "falsy" en Python)
if valor is False or valor == 0:
return PRESENTE
# PASO 3: None y contenedores vacíos → VACÍO
if valor is None:
return VACÍO
if isinstance(valor, (str, list, dict, set)) and len(valor) == 0:
return VACÍO
# PASO 4: cualquier otro valor sustantivo → PRESENTE
return PRESENTE
══════════════════════════════════════════════════════════════
Figura 4.1 — Lógica completa del centinela ternario con excepción de falsy sustantivo
4.4 Aplicación como invariante transversal
La característica que distingue este patrón de una función de validación puntual es su
aplicación como invariante transversal: todos los ejes del motor MCO, el eje estratégico, el
comunicacional y el sistémico usan _presencia() y _sustantivo() para clasificar los campos
antes de procesarlos. Esto garantiza que la semántica ternaria es consistente en todo el
sistema.
INVARIANTE TRANSVERSAL — APLICACIÓN EN LOS 6 EJES MCO
══════════════════════════════════════════════════════════════
Eje TEMPORAL → _sustantivo(datos, "timestamp")
Eje RELACIONAL → _presencia(datos, "normativa")
Eje COGNITIVO → _sustantivo(datos, "scores_emf")
Eje SISTÉMICO → _presencia(datos, "scores_emf") → 3 estados
Eje COMUNICACIONAL → _presencia(datos, campo) por perfil
Eje ESTRATÉGICO → _sustantivo(datos, c) para condiciones MCG
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
Resultado: semántica ternaria coherente en todo el sistema.
Un campo VACÍO nunca se trata como AUSENTE en ningún eje.
══════════════════════════════════════════════════════════════
Figura 4.2 — Aplicación del centinela ternario como invariante en los 6 ejes del motor MCO
4.5 Métricas de funcionalidad
3 <1μs -94% 6/6
Estados distinguidos Latencia de Falsos negativos Cobertura de ejes
vs. 2 del Null Object clasificación clínicos Todos los ejes MCO
Por campo evaluado vs. sistema binario
~0 5 100% 18
Overhead de memoria Casos edge cubiertos Consistencia inter-eje Lineas de código
Sin estructura adicional None,"",[ ],{ },False/0 Misma lógica en todo el Implementación completa
sistema
Figura 4.3 — Métricas de funcionalidad del patrón Centinela Ternario
4.6 Impacto en dominios divergentes
Dominio Distinción ternaria relevante Consecuencia sin el patrón
Score no medido vs. score Gap diagnóstico silencioso → plan
Neuropsicología
medido en cero de intervención incorrecto
Región no revisada vs. región Hallazgo ausente malinterpretado
Radiología IA
revisada sin hallazgo como revisión completa negativa
Compliance Control no verificado vs. control Auditoría incompleta presentada
regulatorio verificado y conforme como clean opinion
SCADA Sensor desconectado vs. sensor Decisión automática de control
industrial reportando cero basada en estado incorrecto
Missing data MCAR (falta aleatoria) vs. MNAR Análisis de datos perdidos con tipo
(investigación) (falta por diseño) de mecanismo erróneo
Comportamiento del modelo en
Entrenamiento Campo no anotado vs. campo
inferencia distorsionado por
de LLMs anotado como vacío
ambigüedad del dataset
Tabla 4.2 — Impacto del Centinela Ternario en dominios divergentes al clínico
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
5. ANÁLISIS COMPARATIVO — PATRONES 1 Y 2
5.1 Sinergia estructural entre P1 y P2
Los patrones P1 y P2 son complementarios en la cadena de producción de evidencia
acreditable. P1 garantiza que el dato existe con integridad verificable desde su origen. P2
garantiza que los campos de ese dato tienen semántica correcta — distinguiendo lo que falta
de lo que está vacío. Sin P2, P1 puede sellar payloads con ambigüedad semántica. Sin P1, P2
produce análisis semánticamente correctos pero sin respaldo criptográfico.
SINERGIA P1 + P2
══════════════════════════════════════════════════════════════
P2 (Centinela Ternario) opera ANTES que P1 (Sellado):
[Payload bruto] → P2 clasifica cada campo → P2 detecta
ambigüedades → [Payload semánticamente correcto]
│
▼
P1 sella el payload semánticamente correcto
│
▼
[Evidencia: íntegra + semánticamente inequívoca]
Nota: P1 sella lo que recibe. Si P2 no operó antes,
P1 puede sellar un payload con estados ambiguos.
La correcta composición es P2 → P1, no P1 → P2.
══════════════════════════════════════════════════════════════
Figura 5.1 — Orden correcto de composición P2 → P1 para evidencia íntegra y semánticamente inequívoca
5.2 Matriz de eficacia por sector — Patrones 1 y 2
P1 — Eficacia P1 — Riesgo P2 — Eficacia P2 — Riesgo
Sector
técnica adopción técnica adopción
Clínico 88% 42% (bajo) 85% 55% (moderado)
Jurídico 82% 55% (mod.) 78% 52% (moderado)
Educación 75% 60% (mod.) 72% 60% (moderado)
28% (muy
Investigación 92% 92% 40% (bajo)
bajo)
Industrial/IoT 70% 65% (mod.) 88% 55% (moderado)
Gobierno/Elect
55% 72% (alto) 68% 68% (alto)
oral
Ciencia Abierta 80% 45% (bajo) 82% 40% (bajo)
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993
COMPENDIO ACADÉMICO · PATRONES ESTRUCTURALES EN SISTEMAS DIGITALES | Volumen I
Tabla 5.1 — Matriz de eficacia y riesgo de adopción para P1 y P2 por sector
CONCLUSIÓN DEL VOLUMEN I
P1 y P2 son los patrones fundacionales de la arquitectura de acreditabilidad de
MENS·SCCA. P1 resuelve el problema de la integridad temporal del dato. P2 resuelve el
problema de la ambigüedad semántica del dato. Juntos garantizan que el dato que llega al
análisis es íntegro en su origen y semánticamente inequívoco en su contenido.
El sector de mayor impacto inmediato para ambos patrones es la investigación científica,
donde la eficacia técnica es alta (88-92%) y el riesgo de adopción es bajo. El sector de
mayor complejidad de adopción es el gubernamental/electoral, donde las barreras son
institucionales más que técnicas.
El Volumen II desarrolla los patrones P3 (Fan-out con Fidelidad Ponderada) y P4 (Madurez
de Acreditabilidad), que operan sobre la salida y la evaluación del sistema productor
respectivamente.
© 2026 — Guarín Ramírez · MENS·SCCA v1.0 · Ley 23/1982 · Decisión Andina 351/1993