Una buena pregunta para un modelo no es solo “¿qué sabes?”, sino también “¿qué no sabes y qué ocurrirá cuando necesites saberlo?”
— Tymur Levitin
Un modelo 3D puede contener mucha información.
Dimensiones.
Restricciones.
Parámetros.
Referencias.
Relaciones.
Fórmulas.
Dependencias.
Una secuencia completa de operaciones.
Y, sin embargo, seguir sin saber algo esencial.
Esto parece extraño porque solemos evaluar un modelo por lo que contiene.
Pero en ingeniería también importa lo contrario:
lo que el modelo no contiene.
Una pieza puede tener la geometría correcta y no saber que debe mantener una distancia respecto a otra pieza.
Puede tener dos agujeros perfectamente colocados y no saber que deben permanecer coaxiales con elementos externos.
Puede representar un espesor correcto sin saber que ese espesor responde a una condición funcional.
Puede mostrar una simetría perfecta sin saber si esa simetría es una regla o una coincidencia del estado actual.
Por eso, comprender un modelo exige estudiar dos territorios:
lo que está representado
y
lo que ha quedado fuera de la representación.
Todo modelo es incompleto
Esto no es necesariamente un defecto.
Un modelo técnico no necesita contener toda la realidad.
De hecho, sería imposible.
Una pieza real tiene:
- material;
- masa;
- temperatura;
- tolerancias;
- rugosidad;
- historia de fabricación;
- deformaciones;
- desgaste;
- coste;
- interacción con otras piezas;
- condiciones de montaje;
- comportamiento durante el uso.
Un modelo geométrico puede ignorar muchas de estas propiedades y seguir siendo perfectamente útil para su propósito.
La cuestión no es:
¿contiene toda la información posible?
La cuestión correcta es:
¿contiene la información necesaria para las decisiones que esperamos tomar con él?
Esta diferencia cambia completamente la forma de evaluar un modelo.
Omitir información también es una decisión
Supongamos que modelamos una placa con un agujero.
El diámetro está definido.
La posición está definida.
El espesor está definido.
Todo parece completo.
Pero el agujero debe coincidir con un eje perteneciente a otro componente.
Si esa relación no está representada en el modelo, tenemos dos posibilidades.
La primera:
esa información no es necesaria para el propósito de este modelo.
La segunda:
hemos olvidado representar una relación importante.
Visualmente no podemos distinguir ambas situaciones.
La ausencia es la misma.
El significado no.
Por eso una omisión puede ser:
intencional
o
accidental.
Y esa diferencia es fundamental.
Un modelo no sabe automáticamente por qué algo es correcto
Imaginemos que dos agujeros están separados exactamente 80 mm.
El modelo conoce el valor:
80 mm.
Pero ¿qué significa?
Puede ser una distancia establecida por una norma.
Puede corresponder a otra pieza.
Puede ser resultado de una fórmula.
Puede ser simplemente la distancia que funcionó en el primer prototipo.
Puede incluso ser una medida provisional.
El número no contiene automáticamente esta información.
Si el significado no está expresado mediante la estructura del modelo, documentación, parámetros, referencias u otro mecanismo adecuado, una parte del conocimiento sigue estando únicamente en la cabeza del diseñador.
El archivo contiene:
80 mm.
La persona sabe:
por qué son 80 mm.
No es lo mismo.
Existe conocimiento fuera del modelo
Aquí aparece una distinción importante.
Podemos tener:
CONOCIMIENTO DEL MODELO
y
CONOCIMIENTO SOBRE EL MODELO.
El primero está codificado en su estructura.
El segundo puede existir solo en:
- la memoria del diseñador;
- un plano;
- una especificación;
- una conversación;
- una norma;
- otro archivo;
- una decisión tomada durante una reunión;
- una condición que todos conocen hoy pero que nadie registró.
Mientras la misma persona trabaja con el proyecto, esta diferencia puede pasar desapercibida.
Ella recuerda lo que el modelo no dice.
Pero ¿qué ocurre seis meses después?
¿Y si otra persona abre el archivo?
¿Y si se reutiliza el modelo en otra variante?
¿Y si cambia el requisito que justificaba aquella decisión?
Entonces la frontera entre lo que el modelo sabe y lo que el diseñador recordaba empieza a importar.
Dos modelos idénticos pueden depender de cantidades distintas de memoria humana
Consideremos dos archivos con la misma geometría.
En el primero, las relaciones importantes están expresadas de manera clara.
En el segundo, muchas decisiones dependen del conocimiento del diseñador original.
Ambos funcionan hoy.
Ambos producen la misma pieza.
Pero requieren cantidades diferentes de conocimiento externo para ser comprendidos y modificados.
Podríamos decir:
Modelo A + poca explicación externa → suficiente conocimiento
mientras que:
Modelo B + mucha memoria del diseñador → suficiente conocimiento.
Cuando desaparece esa memoria externa, el segundo modelo pierde parte de su significado práctico aunque su geometría permanezca intacta.
Esto revela algo importante:
la robustez no es solo resistencia geométrica al cambio. También puede ser resistencia a la pérdida de contexto.
Pero tampoco debemos intentar meter todo dentro del modelo
Aquí aparece el extremo contrario.
Si una información existe fuera del modelo, podríamos concluir:
entonces debemos codificar absolutamente todo.
Tampoco.
Un modelo saturado de relaciones, parámetros y reglas puede ser difícil de entender, modificar y mantener.
No toda información merece convertirse en una dependencia CAD.
No todo conocimiento necesita una fórmula.
No toda condición necesita un constraint.
No toda explicación pertenece al feature tree.
La pregunta vuelve a ser selectiva:
¿qué conocimiento necesita formar parte de la estructura del modelo para que este cumpla su función?
La frontera del modelo es una decisión técnica
Podemos imaginar una línea.
Dentro de ella está lo que el modelo representa explícitamente.
Fuera está el resto de la realidad.
La posición de esa línea depende del propósito.
Para un modelo conceptual puede bastar con:
forma general + dimensiones principales.
Para fabricación quizá necesitemos además:
tolerancias + interfaces + restricciones relevantes.
Para una familia paramétrica:
reglas de variación + relaciones + límites.
Para integración con otros componentes:
referencias externas + condiciones de montaje + interfaces.
Por tanto, no existe una única frontera correcta para todos los modelos.
Existe una frontera adecuada o inadecuada para una tarea determinada.
La pregunta clave: ¿qué ocurrirá fuera de las condiciones actuales?
Un modelo suele parecer completo mientras permanece dentro del contexto para el que fue creado.
El problema aparece cuando cambia el contexto.
Por ejemplo:
la pieza se utiliza en otro conjunto;
aparece otro tamaño;
cambia el material;
cambia el proceso de fabricación;
se modifica una pieza vecina;
otro diseñador continúa el trabajo;
la empresa reutiliza el modelo años después.
Entonces puede aparecer una relación que siempre existió en la realidad, pero nunca fue representada en el archivo.
El modelo no necesariamente se rompe.
Puede seguir funcionando perfectamente.
Simplemente empieza a producir respuestas que ya no corresponden al nuevo contexto.
Eso es especialmente peligroso porque no siempre aparece un mensaje de error.
El silencio del software también contiene información
Estamos acostumbrados a prestar atención cuando CAD muestra un error.
Una referencia perdida.
Un sketch que no puede resolverse.
Una operación fallida.
Una geometría imposible.
Pero ¿qué significa que el programa no muestre ningún error?
Solo significa que ha podido ejecutar las reglas que contiene.
No significa que contenga todas las reglas necesarias.
Esta diferencia es crucial.
Sin error de software no equivale a:
sin error técnico.
El programa puede permanecer completamente silencioso mientras falta una relación esencial.
Por eso el silencio también debe interpretarse.
No como prueba de corrección.
Solo como ausencia de un conflicto detectable dentro del conocimiento que el modelo posee.
Una relación ausente puede ser invisible durante años
Supongamos que una pieza siempre se ha fabricado con una anchura fija.
Un agujero está colocado a 30 mm del borde.
Durante años no cambia nada.
Nadie necesita preguntar por qué son 30 mm.
Después aparece una nueva variante.
La anchura cambia.
Ahora descubrimos que el agujero realmente debía mantenerse alineado con otro componente.
La distancia de 30 mm nunca fue la regla.
Era una consecuencia del diseño original.
Durante años el modelo funcionó.
No porque conociera la relación correcta.
Sino porque nunca se le hizo una pregunta capaz de revelar lo que ignoraba.
Para descubrir lo que el modelo no sabe, hay que hacerle preguntas nuevas
Esto nos da un método de diagnóstico.
No basta con probar los cambios habituales.
También podemos introducir cambios que obliguen al modelo a revelar los límites de su conocimiento.
Por ejemplo:
¿Qué pasa si cambia una pieza vecina?
¿Qué pasa si cambia el tamaño general pero la interfaz debe permanecer?
¿Qué pasa si desaparece una referencia que usamos por comodidad?
¿Qué pasa si otra persona necesita modificar el archivo sin conocer su historia?
¿Qué pasa si creamos una variante fuera del rango habitual?
Cada pregunta explora una frontera diferente.
Podemos expresarlo así:
NUEVA SITUACIÓN → INFORMACIÓN NECESARIA → ¿ESTÁ REPRESENTADA? → COMPORTAMIENTO DEL MODELO
Una prueba puede revelar conocimiento; otra puede revelar ignorancia
Si cambiamos un parámetro y el modelo mantiene correctamente una relación, hemos descubierto algo que sabe.
Si cambiamos otra condición y la relación necesaria no aparece, hemos descubierto algo que no sabe.
Ambos resultados son útiles.
Por eso el objetivo de una prueba no debería ser únicamente demostrar que el modelo funciona.
También puede ser descubrir hasta dónde funciona su conocimiento.
Es una diferencia importante.
La pregunta:
¿funciona el modelo?
es demasiado general.
Una pregunta más precisa sería:
¿para qué conjunto de situaciones posee este modelo información suficiente?
El dominio de validez del modelo
En matemáticas y ciencias es normal preguntar bajo qué condiciones una afirmación es válida.
Podemos aplicar una idea semejante al modelado.
Un modelo puede ser correcto:
para cierto rango de dimensiones;
para determinada familia de productos;
para un proceso concreto;
para una configuración específica;
para ciertas relaciones con componentes vecinos.
Fuera de ese dominio, algunas de sus suposiciones pueden dejar de ser válidas.
Entonces la robustez no significa:
este modelo funciona ante cualquier cambio imaginable.
Eso sería una exigencia absurda.
Significa algo más preciso:
el modelo se comporta correctamente dentro del dominio de cambios para el que fue concebido.
Y, si es posible, sabemos dónde termina ese dominio.
Los límites también son conocimiento
Esto produce una conclusión interesante.
Un modelo avanzado no necesariamente es el que pretende saberlo todo.
Puede ser el que deja claro:
qué sabe,
qué supone,
qué depende de información externa,
y
dónde deja de ser válido.
Reconocer un límite no debilita un modelo.
Lo hace más comprensible.
Una fórmula con condiciones conocidas es más útil que una fórmula aparentemente universal que solo funciona por casualidad en los casos probados.
Lo mismo ocurre con una estructura CAD.
¿Qué debe estar dentro y qué puede permanecer fuera?
No existe una respuesta automática.
Pero podemos formular algunas preguntas.
¿Esta información afectará probablemente a futuras modificaciones?
¿Representa una relación funcional importante?
¿Otra persona podría necesitar comprenderla?
¿Su ausencia puede producir una geometría aparentemente correcta pero técnicamente equivocada?
¿La relación pertenece realmente al propósito del modelo?
¿Codificarla aumentará claridad o solo complejidad?
¿Existe otro lugar mejor para conservar esa información?
Estas preguntas evitan dos errores opuestos:
modelo demasiado pobre
y
modelo innecesariamente sobrecargado.
Modelar también significa decidir qué ignorar
Esta frase puede parecer provocadora.
Pero toda abstracción funciona así.
Un mapa de metro ignora la forma exacta de las calles.
Un esquema eléctrico ignora muchos detalles físicos de los componentes.
Una ecuación ignora aspectos de la realidad que no son relevantes para el problema.
Un modelo 3D hace lo mismo.
La calidad de una abstracción no depende de representar todo.
Depende de ignorar correctamente.
Eso significa excluir información que no necesitamos sin excluir aquello que será esencial para las decisiones que esperamos tomar.
La ausencia puede ser correcta
Es importante insistir en esto.
Si un modelo no contiene una determinada relación, no debemos concluir inmediatamente que está incompleto.
Quizá esa relación pertenece a otro nivel del sistema.
Quizá se controla en un ensamblaje.
Quizá está definida en una especificación.
Quizá no es relevante para el propósito del archivo.
Quizá introducirla crearía una dependencia innecesaria.
Por eso la pregunta no es:
¿falta información?
En cualquier modelo falta una cantidad enorme de información.
La pregunta es:
¿falta información que este modelo necesita para cumplir correctamente su función?
El conocimiento distribuido
En proyectos reales, el conocimiento técnico rara vez vive en un solo lugar.
Puede distribuirse entre:
modelo 3D → plano → especificación → ensamblaje → norma → documentación → conocimiento del equipo.
Esto no es necesariamente un problema.
Pero genera una responsabilidad:
debemos saber qué información pertenece a cada nivel.
Si una relación crítica existe únicamente en la memoria de una persona, tenemos un riesgo.
Si la misma información está duplicada en cinco lugares independientes, también podemos crear un riesgo porque las versiones pueden divergir.
La arquitectura del conocimiento técnico no consiste simplemente en almacenar más.
Consiste en decidir dónde debe vivir cada tipo de información.
CAD también es gestión de conocimiento
Aquí el modelado 3D se conecta con un problema mucho más amplio.
No solo construimos objetos.
Organizamos conocimiento.
Decidimos:
qué será explícito;
qué será implícito;
qué será paramétrico;
qué dependerá de otro elemento;
qué permanecerá externo;
qué deberá recordar una persona;
qué podrá reconstruir otra persona observando la estructura.
Por eso un archivo CAD puede verse como una pequeña arquitectura de conocimiento técnico.
Su geometría es solo la parte más visible.
Una pregunta útil para el estudiante
Después de terminar un modelo, podemos preguntar:
¿Qué sabe tu modelo?
El estudiante puede responder:
sabe que estos agujeros son iguales;
sabe que esta superficie debe permanecer paralela;
sabe que este diámetro depende de aquel;
sabe que esta posición se define desde un eje.
Después viene la segunda pregunta:
¿Qué no sabe?
Aquí comienza una reflexión diferente.
No sabe por qué se eligió este material.
No sabe que esta pieza debe coincidir con otra si no hemos representado esa relación.
No sabe que cierto valor es provisional.
No sabe que una regla funciona únicamente dentro de determinado rango.
Y finalmente:
¿Necesita saberlo?
Esa tercera pregunta convierte una lista de ausencias en una decisión técnica.
De construir geometría a definir fronteras
Podemos representar otra trayectoria de aprendizaje:
COMANDO → GEOMETRÍA → RELACIÓN → DEPENDENCIA → CONOCIMIENTO REPRESENTADO → CONOCIMIENTO OMITIDO → DOMINIO DE VALIDEZ → JUICIO TÉCNICO
Al principio aprendemos qué puede hacer el programa.
Después aprendemos a construir.
Luego aprendemos a relacionar elementos.
Más tarde empezamos a preguntar qué información contiene realmente nuestra estructura.
Y finalmente:
¿hasta dónde podemos confiar en ella?
Ese último nivel no se resuelve con un botón.
Exige comprender la tarea, el contexto y los límites de la abstracción.
Para quienes quieran desarrollar el modelado desde esta perspectiva, Learn AutoCAD and 3D Modeling permite conectar las herramientas CAD con geometría, dependencias, análisis del comportamiento del modelo y resolución técnica de problemas.
Conclusión
Un modelo 3D no se define únicamente por la información que contiene.
También se define por sus silencios.
Por las relaciones que no fueron codificadas.
Por las condiciones que quedaron fuera.
Por las decisiones que todavía viven en la memoria de una persona.
Por los contextos que nunca fueron probados.
Por los límites dentro de los cuales sus reglas siguen teniendo sentido.
Eso no significa que debamos llenar cada modelo con toda la información imaginable.
Significa algo más exigente:
debemos distinguir entre ignorancia necesaria e ignorancia peligrosa.
Un buen modelo no tiene que saberlo todo.
Pero nosotros sí deberíamos saber, en la medida de lo posible, qué no sabe nuestro modelo y por qué.
La madurez de un modelo no consiste en saberlo todo, sino en que sus límites no nos sorprendan cuando la realidad cambie la pregunta.
— Tymur Levitin
Investigación relacionada
El artículo en inglés A Correct 3D Shape Is Not Necessarily a Correct 3D Model estudia qué relaciones debería conservar una estructura ante los cambios futuros para los que fue concebida.
El artículo en alemán Ein richtiges Maß macht noch kein richtiges 3D-Modell separa el valor numérico correcto de la justificación técnica de una relación.
El artículo en ruso Точная 3D-модель может быть неверным ответом на задачу analiza la transformación de un requisito técnico en una interpretación y, después, en una estructura CAD.
El artículo en ucraniano Що 3D-модель вважає незмінним — і чому саме це показує її логіку examina los invariantes: aquello que una estructura debe conservar mientras otras propiedades cambian.
El artículo en polaco Każdy element może być poprawny, a cały model 3D nadal błędny estudia la jerarquía de dependencias y la arquitectura de decisiones del modelo.
El estudio de partida Two 3D Models Can Look Identical and Still Contain Different Knowledge plantea el problema fundamental del ciclo: dos geometrías visualmente idénticas pueden contener conocimiento técnico diferente.
Tymur Levitin
Founder & Director, Levitin Language School / Language Learnings
Languages • Academic & Professional Subjects • Language + Subject
© 2026 Tymur Levitin. All rights reserved.
