Added section about alternatives
This commit is contained in:
parent
40bade6e1e
commit
e50714be85
1 changed files with 36 additions and 4 deletions
|
|
@ -61,9 +61,11 @@ User & j.thompson@example.com & password \\
|
||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{center}
|
\end{center}
|
||||||
|
|
||||||
\textit{Note: I will try to keep the public website available, but the GPU node runs on my home PC and may occasionally go offline. For reliable testing, I recommend running the system locally on a machine with a GPU.}
|
\textit{Note: I will try to keep the public website available, but the GPU node
|
||||||
|
runs on my home PC and may occasionally go offline. For reliable testing,
|
||||||
|
I recommend running the system locally on a machine with a CUDA-enabled GPU.}
|
||||||
|
|
||||||
Manager registration code (if required): \texttt{MANAGER2026}
|
Manager registration code (for signup): \texttt{MANAGER2026}
|
||||||
|
|
||||||
\section{Introduction}\label{introduction}
|
\section{Introduction}\label{introduction}
|
||||||
|
|
||||||
|
|
@ -268,6 +270,26 @@ APIs, supports offline or air-gapped environments, and aligns with
|
||||||
enterprise privacy requirements while maintaining acceptable inference
|
enterprise privacy requirements while maintaining acceptable inference
|
||||||
performance.
|
performance.
|
||||||
|
|
||||||
|
\subsection{Positioning Against Alternative
|
||||||
|
Approaches}\label{positioning-against-alternative-approaches}
|
||||||
|
|
||||||
|
Dynavera was designed against three practical alternatives. First,
|
||||||
|
human-only onboarding preserves expert nuance but does not scale well
|
||||||
|
and introduces recurring opportunity cost for senior staff. Second,
|
||||||
|
static LMS/document-first onboarding scales distribution but provides
|
||||||
|
limited adaptivity, weak context grounding during Q\&A, and little
|
||||||
|
operational traceability beyond completion events. Third, a single
|
||||||
|
general chatbot can improve interactivity, but it typically blends
|
||||||
|
curriculum, retrieval, assessment, and monitoring concerns into one
|
||||||
|
prompt surface, making governance and iterative improvement harder.
|
||||||
|
|
||||||
|
The Dynavera architecture chooses a middle path: specialized agent roles
|
||||||
|
within one orchestrated runtime, retrieval-grounded generation, and
|
||||||
|
persisted session state for reviewability. This trade-off accepts added
|
||||||
|
system complexity in exchange for improved modularity, clearer
|
||||||
|
responsibility boundaries, and stronger alignment between training
|
||||||
|
delivery and management oversight.
|
||||||
|
|
||||||
\subsection{Learning Origins}\label{learning-origins}
|
\subsection{Learning Origins}\label{learning-origins}
|
||||||
|
|
||||||
The design and implementation of Dynavera synthesize concepts developed
|
The design and implementation of Dynavera synthesize concepts developed
|
||||||
|
|
@ -560,8 +582,18 @@ During guided learning, module content generation, context retrieval,
|
||||||
and assessment output are coordinated in sequence. The curriculum phase
|
and assessment output are coordinated in sequence. The curriculum phase
|
||||||
determines structure, the knowledge phase builds role-grounded
|
determines structure, the knowledge phase builds role-grounded
|
||||||
instructional content, and the assessment phase constructs evaluative
|
instructional content, and the assessment phase constructs evaluative
|
||||||
checkpoints. Progress monitoring then summarizes current status using
|
checkpoints. Final assessment grading follows a mixed strategy: multiple
|
||||||
persisted session state and completed interactions. This keeps learning
|
choice responses are deterministically compared against configured
|
||||||
|
correct options, while non-multiple-choice responses are agent-graded.
|
||||||
|
Per-question grading outcomes are persisted in session state for review
|
||||||
|
and feedback rendering.
|
||||||
|
|
||||||
|
Progress monitoring then summarizes current status using persisted
|
||||||
|
session state and completed interactions. In the implemented UI path,
|
||||||
|
AI monitor inference is only triggered after onboarding completion;
|
||||||
|
before completion, the system presents a local progress summary.
|
||||||
|
When available, monitor judgements are informed by prior final-quiz
|
||||||
|
question/answer evidence and saved grading details. This keeps learning
|
||||||
flow adaptive without abandoning traceability.
|
flow adaptive without abandoning traceability.
|
||||||
|
|
||||||
Finally, workflow state is persisted throughout execution: user
|
Finally, workflow state is persisted throughout execution: user
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue