Decisión de diseño clave:
El Backend EAC opera como un servicio centralizado en el Nodo Central Coordinador del VFDS. Los centros FP actúan como consumidores del servicio, configurando un plugin LMS, un Aggregator/Anonymizer local y su propio FIWARE Dataspace Connector (CONNECTOR_CFP), que actúa como frontera de soberanía del dato de cada centro. El FIWARE Dataspace Connector Central (CONNECTOR_CENTRAL) actúa como API Gateway del Nodo Central, siendo el único punto de entrada al Backend EAC para todos los conectores de los centros.
Responsabilidad: Construir y mantener el Grafo de Precedencia del Ecosistema Laboral: Situaciones de Competencia, sus Nodos de Requisito y los Umbrales de Maestría.
Funcionalidades:
Tecnologías:
Responsabilidad: Generar automáticamente Situaciones de Competencia contextualizadas a partir del estado del estudiante y de los parámetros pedagógicos solicitados por el docente.
Funcionalidades:
Prompt Engineering: Ver sección 7
Responsabilidad: Seleccionar la siguiente Situación de Competencia óptima para cada estudiante, operacionalizando la Zona de Despliegue Proximal mediante el cálculo de la Outer Fringe del Grafo de Precedencia.
Algoritmo básico (MVP):
def recommend_next_problem(student_knowledge_state):
outer_fringe = calculate_outer_fringe(student_knowledge_state)
# Filtrar SCs que cubran habilidades de la franja
candidate_scs = filter_scs_by_skills(all_scs, outer_fringe)
# Heurística de selección por Gradiente de Autonomía
if student_performance_last_3 > 0.85: # Resuelve con alta autonomía
return select_max_difficulty(candidate_scs)
elif student_performance_last_3 < 0.50: # Tiene dificultades
weak_skills = identify_weak_prerequisites(student_knowledge_state)
return select_sc_reinforcing(weak_skills)
else: # Rendimiento medio
return random.choice(candidate_scs)
Responsabilidad: Evaluar automáticamente las evidencias de desempeño de los estudiantes mediante rúbricas multi-criterio, actualizando el Perfil de Habilitación y el Gradiente de Autonomía.
Funcionalidades:
SkillMasteryAggregate en Orion-LDTipos de evaluación:
El sistema opera con dos conectores de idéntica arquitectura interna pero con responsabilidades diferenciadas. Cada conector integra dos capas funcionales:
Authentication Service, compuesto por:
Auth Portal: orquesta el flujo OIDC4VP con la Wallet del usuario, mediando entre la aplicación cliente y el VerifierVerifier: verifica la validez de la VC presentada, consultando la Local Trusted Issuers List local y los servicios globales del dataspace (Data Space Participants Registry, Global Trusted Issuers List y Revocation List)Credentials Config Service: informa al Auth Portal de qué tipos de credenciales son aceptadas para cada recursoLocal Trusted Issuers List: registro local de los emisores de credenciales en los que confía este conector; el Marketplace escribe en él al aprovisionar el acceso de una organizaciónPolicy Management / Authorization Service, compuesto por:
APISIX · PEP (Policy Enforcement Point): API Gateway que intercepta toda petición entrante y delega la decisión de autorización en el PDPPDP (Policy Decision Point): evalúa la petición contra las políticas ODRL vigentes, consultando al PIP para datos de contexto y al PRP/PAP para las políticas aplicablesPIP (Policy Information Point): proporciona al PDP la información de contexto necesaria para evaluar la políticaPRP / PAP (Policy Repository / Policy Administration Point): almacena y gestiona las políticas ODRL; el Marketplace escribe en él al registrar o actualizar un productoCONNECTOR_CENTRAL (Nodo Central): Punto de entrada único al Backend EAC para todos los centros participantes. Su Authentication Service verifica las credenciales de Operadores e Investigadores; su Authorization Service aplica las políticas ODRL asociadas a cada producto del catálogo y registra cada transacción en el audit log.
CONNECTOR_CFP (cada Centro FP): Frontera de soberanía del dato de cada centro. Su Authentication Service verifica las credenciales de Docentes. Su Authorization Service controla el acceso a la Aplicación LTI y gestiona el tráfico de evidencias anonimizadas hacia el Nodo Central y de resultados en sentido inverso. Garantiza que ningún dato identificable abandona el perímetro del centro.
Ambos conectores incorporan además su propio VC Issuer (Keycloak), desplegado junto al conector como componente independiente: el del Centro FP emite StudentCredential y TeacherCredential; el del Nodo Central emite OperatorCredential y ResearcherCredential.
Funciones:
std_12345 → anon_abc123xyzPrincipio: CONNECTOR_CFP, CONNECTOR_CENTRAL y el Backend EAC nunca reciben ni procesan datos personales identificables. La reidentificación del estudiante para presentarle sus resultados ocurre únicamente en APP_LTI, dentro del perímetro del centro.
Alojados en el Nodo Central, son consultados por los Verifier de ambos conectores durante el proceso de autenticación:
Local Trusted Issuers List de cada conector.