Source-linked AI summary

LearnAdapt Praxis: Controlled AI Assistance and Evidence Traces for Adult Workplace Learning

Nizam Kadir

arXiv:2610.02699v1cs.CYcs.HC

TL;DR

A plausible AI-generated workplace artefact does not establish that an adult can explain or reproduce its reasoning. Praxis structures assisted work and an independent transfer attempt, then tests selected workflow and evidence properties. Its rehearsal passed the specified checks, but whether the arrangement improves independent judgement or transfer remains untested.

  • Problem

    A useful AI-generated workplace artefact does not by itself show that its adult user can explain or reproduce the reasoning behind it.

    Source: §1 · p. 1
  • Method

    Praxis structures workplace learning around an initial response, course material, a five-field specification, validation and a separate transfer response, with a coarse project-level withdrawal of assistance.

    Source: §1 · p. 1, §2.1 · p. 2
  • Results

    120 synthetic project episodes completed, all 3,990 recorded checks met expectations, and targeted authentication tests resolved a session-expiry defect.

    Source: §5.1 · p. 7, §6.4 · p. 12, §8 · p. 12
  • Takeaways & Limitations

    The results support the tested engineering properties of the recorded release, while improvement in adults’ independent judgement, transfer or workplace outcomes remains an empirical question.

    Source: §8 · p. 12

    Project-level transfer controls cannot prevent learners from recalling earlier content or using external tools, so they do not establish unaided performance.

    Source: §6.3 · p. 11

Abstract

from arXiv · show

AI can help adults produce plausible workplace artefacts while leaving their independent reasoning difficult to inspect. LearnAdapt Praxis addresses this design problem through a five-stage learning workspace: Frame, Learn, Build, Validate and Transfer. The application stores an initial response, versioned specifications, coaching records, validation observations, a separate transfer response and facilitator feedback. Project-level server controls restrict coaching, access to earlier work and learner export during an active transfer attempt; they do not establish that a learner avoided assistance outside the application. This technical report describes the implemented architecture and evaluates selected workflow, authority, failure-recovery and provenance properties. A reproducible synthetic rehearsal exercised 120 serial project episodes across three fictional workplace contexts and four injected provider conditions. All 3,990 recorded checks met their specified expectations. The resulting records contained 240 specification versions, 1,200 activity events and 60 stored synthetic hints; 60 injected provider failures produced no fabricated hints. Separate authentication regressions exposed and resolved a session-expiry defect, and limited staging and production checks verified account access and live model connectivity. The evidence supports the tested engineering properties of the recorded release. It does not establish learning gains, model-output quality, unaided assessment validity, population usability or production capacity. The contribution is an implemented arrangement for separating assisted work, project-level assistance withdrawal and inspectable evidence, accompanied by executable tests and an explicit account of what remains to be validated with adult learners.

1 Introduction

A plausible workplace artefact does not by itself show that an adult learner can explain or reproduce its reasoning. Praxis structures a project to make learner decisions visible, and the report evaluates selected engineering properties rather than learning effects.

1 Introduction

  • A polished workplace artefact may conceal unexamined assumptions, while identifying a limitation or rejecting automation can demonstrate judgement without an impressive prototype.The central problem is that artefact quality alone does not reveal the reasoning behind it.Source: §1 · p. 1
  • Praxis structures a project around an initial response, course material, a five-field specification, validation observations and a response to a different scenario.Facilitators configure learning conditions and review the resulting evidence.Source: §1 · pp. 1–2
  • The report asks whether the implementation preserves workflow and role boundaries, retains inspectable records through provider failures, and supports a bounded demonstration or pilot.It also asks what remains outside the tested scope.Source: §1 · p. 2
  • The study evaluates scripted project episodes through a system description, frozen executable rehearsal and release-specific verification record, not a human-participant experiment or learning-effect estimate.Individual assertions are nested within project episodes.Source: §1 · p. 2

2 Design rationale and related work

Praxis separates assisted activity from independent performance through a coarse project-level withdrawal point, while preserving traces that could be interpreted in future study. Its design draws on broader educational-AI work but remains a specific application, evaluated through its own reproducible rehearsal.

2.1 Assistance, feedback and independent performance

  • Praxis uses a coarse withdrawal point at the start of independent transfer, rather than estimating competence or adapting support through a psychometric fading model.The design responds to scaffolding’s distinction between scaffolded learning and performance with continuing distributed resources.Source: §2.1 · p. 2
  • The coach is prompted to provide a diagnostic question and limited scaffold, while facilitators provide review judgements; tests verify prompt delivery, not model compliance.Formative-feedback research motivates task-actionable feedback.Source: §2.1 · p. 2
  • The locked starting response preserves a trace for future interpretation alongside instruction, revision and transfer, but does not implement or replicate productive-failure intervention.Source: §2.1 · p. 2
  • A high-school mathematics study found AI consequences depended on tutoring arrangement, motivating separate assisted and unassisted outcomes but not supplying an expected effect for adult workplace design.Source: §2.1 · p. 2

2.2 Relationship to LearnAdapt and Critsly

  • Praxis is a specific LearnAdapt application with shared authentication and dedicated application components, not an integration of every LearnAdapt product or an operating system for all pedagogy [5].Source: §2.2 · p. 2
  • Praxis adopts Critsly’s distinction between operational readiness and educational effectiveness [6], using a new rehearsal whose inputs, check outcomes, exports and source fingerprint support recomputation.Critsly counts, classifications, timings and simulated learner observations are not reused as Praxis results.Source: §2.2 · p. 3

3 Application and system architecture

Praxis places authoritative workflow checks in a server-side service and records project conditions and learning evidence across a five-stage workflow. During transfer it restricts learner access to earlier project work and coaching, while provider-call handling preserves state on failure; these controls do not establish unaided authorship or model-output quality.

3.1 Deployment and authority boundaries

  • The browser submits commands while authoritative workflow checks run in the domain service; project records retain a course-configuration snapshot, though not complete model infrastructure or prompt history.Cohort owners may inspect and review associated projects but cannot overwrite learner submissions through learner commands; unrelated learners and facilitators cannot read them through the tested service methods.Source: §3.1 · p. 3

3.2 Five stages and a separate transfer state

  • During active transfer, learner responses omit earlier project material and coaching and export are rejected, while the assigned facilitator may still inspect the project.A sufficiently long, self-attested response completes the attempt and restores earlier records; those requirements do not measure competence or verify unaided authorship.Source: §3.2 · p. 4, Figure 2 · p. 4

3.3 Coaching and recoverable provider failure

  • Coaching uses project context and limited-scaffold instructions, while pending-request and revision checks govern saves and recover from provider exceptions or empty replies without fabricating a response.The controls manage application state, not every response’s semantic or pedagogical quality, or correctness under every multi-process race or provider timeout.Source: §3.3 · p. 5

4 Technical study methods

The technical study combines a scripted, release-specific rehearsal with separate authentication regressions and limited live checks. Its methods test specified workflow and recovery properties, not learner performance or production capacity.

4.1 Design, release and units of analysis

  • The rehearsal crossed three fictional workplace contexts with four injected provider conditions for 120 scripted episodes, while repeated transitions and nested checks do not represent independent learners or naturalistic behavior.The protocol was retained but not externally preregistered, and developer-led checks were informed by the implementation and executed with AI assistance.Source: §4.1 · pp. 5–6, Table 2 · p. 6

4.2 Episode procedure and outcome checks

  • Each episode exercised an authorized project path, negative access and workflow probes, provider failure and recovery checks, and comparisons of returned state and exports against expectations.All outcomes and one synthetic JSON export per episode were retained, with no failed episode or assertion excluded.Source: §4.2 · p. 6

4.3 Execution environment and timing

  • Serial in-memory SQLite episode timings excluded HTTP, sessions, browser rendering, network transport and real inference, so they are reproducibility diagnostics rather than latency or capacity estimates.The production service uses PHP 8.2 and a different database environment; no concurrent-user load test, prolonged soak test or browser-compatibility sample was conducted.Source: §4.3 · p. 7

4.4 Authentication and deployed checks

  • Separate authentication harnesses tested expiry and recovery paths, while staging and production checks exercised demonstration-role access, a temporary synthetic project path and an actual provider response.No password-recovery email was sent, leaving email delivery outside the verified scope.Source: §4.4 · p. 7

5 Results

The 120 scripted episodes completed the workflow, and all 3,990 recorded checks met their expected outcomes. Results also cover project-level transfer restrictions, provider-failure handling, session-expiry correction, and limited release verification.

5.1 Workflow, authority and evidence integrity

  • All 120 episodes completed the scripted path, and all 3,990 recorded checks met their expected outcomes with zero unexpected failures.Table 3 groups checks by the property exercised; these are scripted assertions, not population reliability estimates.Source: §5.1 · p. 7, Table 3 · p. 7
  • Final exports contained 240 specification versions and 1,200 events, but draft saves do not all append events, so counts are not a full interaction trace.Every export retained transfer submission and attestation, reviewer identity, timestamped source-labelled events, and notices separating activity records from learning-gain inference; the second read used the same in-memory database.Source: §5.1 · pp. 7–8
  • All 120 active-transfer coaching requests and learner exports were rejected, and responses passed redaction checks, while facilitators retained inspection access.Earlier material became available again after submission; the production screen documents application state, not verified independent performance or avoidance of outside assistance.Source: §5.1 · p. 8, Figure 4 · p. 8

5.2 Provider failures and overlapping changes

  • Valid and reentrant provider conditions each stored 30 synthetic hints, while 60 exception and empty-condition episodes stored none; the latter was the intended failure outcome.Across conditions, 120 callbacks were invoked and 60 hints retained; Figure 5 reports scripted outcomes, not real-model quality.Source: §5.2 · p. 8, Figure 5 · p. 9
  • All provider conditions preserved saved build fields and cleared pending markers; 30 reentrant saves and stale-revision writes were rejected as specified.These checks do not exhaust arbitrary interleavings, shared-session races, or distributed database failures; diagnostic in-memory episode times are not user-facing AI response times or evidence for class size.Source: §5.2 · pp. 8–9

5.3 Session-expiry defect and deployed verification

  • The authentication harness reproduced a prior session-expiry defect in which a renewed login form lacked a session token and the subsequent login failed CSRF validation.The recorded release establishes a fresh anonymous session after timeout and permits one retry for a public authentication request explicitly rejected for token expiry.Source: §5.3 · p. 9
  • Release-specific regressions passed 58 HTTP checks, 37 JavaScript assertions and 23 service checks; staging also confirmed submission from an old login tab after sign-out elsewhere.The tested container image was promoted by immutable digest. Two live coaching responses reported OpenAI and gpt-4o-mini, with token counts of 419 on staging and 428 on production; these single calls do not evaluate response quality or stability.Source: §5.3 · pp. 9–10, Table 4 · p. 9
  • Figure 6 shows production facilitator assessment controls, but its example feedback and selected rubric values are demonstration material, not independent human ratings.The application state therefore does not add human assessment results to the rehearsal evidence.Source: Figure 6 · p. 10

6 Discussion

The scripted workflow preserves a reviewable record alongside selected assistance boundaries, but provenance records do not establish educational validity. Transfer controls are project- and API-scoped, and further task, operational and governance evidence is needed before broader claims.

6.1 An inspectable separation of assistance and evidence

  • The service preserves selected boundaries and a reviewable project record, but its tests neither establish bug absence nor validate competence measurement.The tests passed against a frozen implementation and were written with knowledge of it.Source: §6.1 · p. 10

6.2 Provenance does not establish educational validity

  • Praxis records versions, events and actors, but its schema is not PROV-conformant and does not capture every interaction or a tamper-evident audit log.An authenticated learning-activity label describes application provenance, not a psychological finding; identical records can come from scripted users or adults.Source: §6.2 · pp. 10–11, Table 5 · p. 11

6.3 Limits of the independent-task boundary

  • Transfer controls cover the current project and tested API paths, not prior exposure, remembered hints or external assistance; starting and transfer scenarios are not established as equivalent forms.Score differences therefore would not automatically constitute valid learning gains; task design and independent scoring are needed for interpretable comparisons.Source: §6.3 · p. 11

6.4 Readiness, scalability and governance

  • Live checks support a bounded demonstration, not claims about capacity, accessibility, diverse devices or infrastructure recovery; human research also requires separate consent and governance arrangements.A session-expiry regression showed why readiness checks must exercise the path from an expired session to usable login, not just fresh login.Source: §6.4 · pp. 11–12

7 Future empirical evaluation

Future evaluation should first establish whether adults can use the workflow as intended, then assess independent performance under defined assistance conditions. The technical protocol and model evaluation also require broader testing.

7 Future empirical evaluation

  • A first adult-learning study should test workflow understandability and usability while distinguishing workplace-problem difficulties from interface difficulties.Facilitator preparation, activity duration and acceptable AI help should be specified rather than inferred from application events.Source: §7 · p. 12
  • Compare course-defined assistance conditions where practicable, using clearly defined supervised tasks, prespecified rubrics and independent assessment.Delayed transfer may suit retained-reasoning questions; trained raters should report agreement, while traces remain explanatory process measures rather than outcome scores.Source: §7 · p. 12
  • Expand technical tests to conflicts, interruptions, timeouts, network loss, recovery and device accessibility, and separately evaluate model outputs on diverse adult-learning prompts.The current rehearsal supports no sample-size, power, effectiveness or commercial-readiness claim.Source: §7 · p. 12

8 Conclusion

LearnAdapt Praxis implements a structured workplace-learning workflow, and its synthetic rehearsal and targeted checks support selected engineering properties of the recorded release. Whether it improves adults’ independent judgement, transfer or workplace outcomes remains untested.

8 Conclusion

  • LearnAdapt Praxis implements controlled AI assistance, versioned artefacts, a project-level transfer boundary and facilitator review.The workspace structures an adult workplace-learning project.Source: §8 · p. 12
  • 120 episodes and 3,990 specified checks support the exercised engineering properties of the recorded release.Targeted authentication tests also identified and resolved a session-expiry defect; limited live checks verified account access and model connectivity.Source: §8 · p. 12
  • Whether the arrangement improves adults’ independent judgement, transfer or workplace outcomes remains an empirical question.Source: §8 · p. 12

Declarations

The report uses synthetic content and demonstration accounts, with no recruited participants or participant outcome data. The author reports a direct development interest, AI assistance, and a prepared companion bundle without a claimed public archival DOI.

Declarations

  • The evaluation used scripted synthetic content and demonstration accounts, with no recruited participants, outcome data or independent human rubric ratings.Human-participant research and any associated ethics approval remain future work.Source: Declarations · p. 12
  • The author has a direct interest in the system, and the evaluation is developer-led rather than an independent certification.Source: Declarations · p. 12
  • Codex assisted with code, protocol, testing, aggregation, reference verification and manuscript preparation; synthetic responses and facilitator feedback were scripted fixtures.Actual model replies were used only for separate live connectivity checks.Source: Declarations · pp. 12–13
  • A companion bundle includes the frozen service, rehearsal records, regression harnesses and analysis code, but no public archival DOI is claimed.Credentials and private deployment secrets are excluded.Source: Declarations · p. 13

A Reproduction and audit trail

The companion materials provide commands and requirements for rerunning the audit checks, alongside design-specific aggregate expectations. The study is tied to a recorded application commit and frozen domain-service fingerprint.

  • The study identifies application commit 40bf7134f5c73b72d671f67517954e1c8d3e07f9 and frozen domain-service SHA-256 fingerprint 44bae32e94a1602859f286ab2b5644eab093122818f4b35381657e8d3b473c07.Source: A Reproduction and audit trail · p. 13
  • The companion Study directory provides commands to rerun the rehearsal, analyse results, and run authentication and service tests.Source: A Reproduction and audit trail · p. 13
  • Local checks require PDO SQLite and Node.js for specified tests, use Python’s standard library for analysis, and need no live credentials or model API key.The authentication HTTP harness uses disposable credentials and a temporary file-backed database, then removes its temporary directory.Source: A Reproduction and audit trail · p. 14
  • The frozen protocol expects 120 episodes, 3,990 checks, 120 provider callbacks, 60 hints, 240 specification versions, and 1,200 events.These are design-specific expectations, not targets for editing results; unexpected failures should be retained and investigated.Source: A Reproduction and audit trail · p. 14

B Screenshot provenance

The figures document fictional content in the production application, not participant sessions or educational outcomes. Their provenance and analysis are separate from the synthetic rehearsal outputs.

  • Figures 3, 4, and 6 are browser captures of the production application at the canonical /praxis/ route on 26 September 2026, showing fictional demonstration content.Source: B Screenshot provenance · p. 14
  • The screenshots are interface evidence analysed separately from synthetic rehearsal outputs, not captured participant sessions or measured educational outcomes.Source: B Screenshot provenance · p. 14
  • The September 28 release changed session recovery but did not alter the depicted learning workflow.Source: B Screenshot provenance · p. 14
Loading 2610.02699v1…