Artemis Intelligence

Artemis Intelligence is the set of AI-assisted capabilities implemented in Artemis and the integration contracts through which Artemis uses external EduTelligence services. This page identifies ownership and boundaries; the developer AI pipeline catalog records the Artemis control plane in more detail.

Ecosystem map

Component	Ownership and role	Artemis boundary	Learn more
Hyperion	Artemis-native AI-assisted authoring for programming exercises, FAQs, problem statements, checklists, quizzes, and staged code generation	Runs through Artemis services and Spring AI. Enablement and model-provider settings are Artemis configuration.	Hyperion setup, consistency-check architecture, Spring AI development
Atlas agents and orchestration	Artemis-native companion agents, competency orchestration, and tool callbacks	Artemis owns the course, competency, authorization, persistence, and tool contracts. artemis.atlas.atlasllm.enabled gates these paths and is off by default; competency orchestration additionally requires the Atlas agent feature.	Atlas agent setup, Developer AI pipeline catalog
Deimos	Artemis-native, instructor-triggered screening of programming exercise participations for malicious CI intent	Runs through Artemis services and its own dedicated Spring AI chat client, deliberately isolated from the shared Hyperion/Atlas endpoint. Requires both the artemis.deimos.enabled startup property and the Deimos runtime feature toggle. Sends student source code as diffs to the configured endpoint.	Deimos setup
Artemis Global Search	Artemis-native keyword and semantic search across Artemis entities	Artemis owns its Weaviate schemas, indexing/query flow, and authorization filters. It is independent of Iris RAG and lecture-answer retrieval.	Global Search & Weaviate setup, developer Weaviate setup
Iris / Pyris	External EduTelligence virtual-tutor service	Artemis creates typed requests and tracked jobs, receives authenticated callbacks, and delivers applicable results over WebSockets. Iris owns tutoring, ingestion, retrieval, and answer-pipeline internals.	Artemis integration catalog, Iris pipeline system, Iris RAG pipeline
Athena	External EduTelligence assessment service	Artemis selects/configures modules, forwards feedback and submission data, schedules applicable due-date work, and offers an authenticated repository-data boundary for authorized programming modules.	Artemis integration catalog, Athena module structure
AtlasML	Optional external EduTelligence ML service	Artemis has an optional, configuration-gated REST integration for competency-related calls and notifications. Selected user-facing paths additionally require the AtlasML feature. Artemis remains the owner of its competency data.	Artemis integration catalog, AtlasML pipelines
Logos	External model gateway/orchestrator	Logos is service-side infrastructure used only when a consumer is configured for it; this catalog makes no claim that Artemis integrates with Logos.	Logos source documentation
Weaviate	Shared vector infrastructure	Artemis Global Search and Iris can use one Weaviate instance with distinct collection namespaces. Their schemas and retrieval flows remain separate.	Global Search & Weaviate setup

Ownership and operational scope

The table deliberately separates Artemis-native capabilities from external service integration contracts:

• Artemis-native: Hyperion, Atlas agents/orchestration, and Artemis Global Search. Artemis owns their application-level workflows, authorization, and persisted Artemis data.
• External services: Iris/Pyris and Athena execute their own service pipelines. Artemis owns request construction, authenticated boundaries, callback handling, and client delivery where applicable.
• Optional integration: AtlasML is not a prerequisite for the Artemis Atlas module. Its client boundary is available only when Artemis configuration enables it; selected user-facing operations also require the AtlasML feature.
• Shared infrastructure: A shared Weaviate instance does not merge Artemis Global Search with Iris RAG. Keep their collection namespaces separate when sharing an instance.

Configuration versus implementation constraints

Feature flags and properties control whether Artemis loads or invokes these capabilities. They are not evidence of a particular deployment, model provider, endpoint, credential, capacity, or rollout state. For example, Hyperion and Atlas model access is configured through Artemis and Spring AI, while per-request AI-selection information can be forwarded at supported Iris boundaries.

Conversely, source-level implementation choices such as Artemis Global Search schemas, callback routes, job tracking, and feature gates are part of the integration contract. Consult the developer AI pipeline catalog before changing an Artemis-side boundary, and use the linked service documentation for service-owned implementation details.

Lecture ingestion operations

Artemis keeps the queue and the state of lecture-unit ingestion; Iris runs the ingestion pipelines. A few operational rules apply when both sides are updated or tuned.

• Update both together. Artemis does not send jobs to Iris. The ingestion worker of Iris claims them from the Artemis queue. Update Iris and Artemis to compatible versions at about the same time. While Iris is on an older version or down, new jobs wait in the queue, and no work is lost. Runs that finish while Iris is still on an older version are confirmed without a fingerprint in the index; reconciliation detects this through the Iris census and ingests those units again.
• Ingestion worker. Iris must reach the Artemis server URL, and its ingestion_worker.enabled setting must stay on (the default). Iris learns the Artemis URL from the health checks that Artemis sends it.
• Which courses are ingested. Global search uses the ingested lecture content of every course, so ingestion does not depend on the course's Iris setting. That setting only switches off the Iris chat and the other interactive Iris features, including the Iris answer in global search, which uses only courses with Iris on. New uploads and edits are always ingested. The backfill and the reconciliation walk catch up on older content only for courses that are still running or ended within artemis.iris.ingestion.course-window (default P730D, two years). They start with the newest courses (running courses first, then by end date) and work backwards. For older courses, the walk only removes index rows of deleted units. FAQ ingestion still follows the course's Iris setting.
• FAQ reconciliation. Artemis synchronizes accepted FAQs asynchronously when they are created or edited, and only for courses with Iris enabled. FAQ deletion also runs asynchronously. These operations use the default FAQ ingestion variant independently of the course's chat variant. An Iris outage does not prevent saving or deleting FAQs. If the bounded synchronization queue is full, the immediate attempt is skipped and reconciliation recovers it. Every 10 minutes (artemis.scheduling.faq-ingestion-reconcile-time), the scheduling node compares the Iris FAQ census of this instance with the accepted FAQs of every course with Iris enabled. It sends FAQs that are missing, changed or stored twice. It deletes only FAQs that this instance stored in Iris for a course with Iris enabled and that no longer exist or are no longer accepted. FAQs of courses with Iris disabled, and older FAQ entries that do not name their Artemis instance, are left as they are. One run sends or deletes at most artemis.iris.faq-reconcile.max-actions-per-run FAQs (default 20). This also refills the FAQs after the vector store was replaced. When the census is unavailable (an older Iris without the census endpoint, an error, or a timeout), the run sends and deletes nothing.
• Reconciliation. artemis.scheduling.lecture-ingestion-reconcile-time starts a walk over all courses that compares the Iris census with the Artemis state (default every 15 minutes). Set it to - to disable the walk. While a walk is active, it takes its next step every artemis.iris.ingestion.reconcile.continuation-interval (default 30 seconds). artemis.iris.ingestion.reconcile.max-backlog (default 3) limits how many units the walk and the backfill keep open at the same time: queued, running, or with a retry that is due. A failed unit that waits for its retry time does not count, so a unit that keeps failing for its own reasons does not stop other work. The walk therefore adds units only as fast as Iris finishes them. When at least max-backlog units failed within artemis.iris.ingestion.reconcile.outage-pause-window (default 30 minutes) and no unit was ingested successfully in that time, the walk and the backfill pause, because Iris is probably down. Failures caused by the unit itself, such as an unreadable file or a video that cannot be loaded, do not count. artemis.iris.ingestion.census-timeout (default 60 seconds) bounds one census request.
• Video links. Iris transcribes YouTube videos, and TUM Live videos when artemis.tum-live.api-base-url is set. A unit whose only content is a link to another video page is marked as not processed. When TUM Live cannot resolve a TUM Live link (the course is not public, the recording is not uploaded yet, or TUM Live is down), Iris ingests the PDF and any stored transcript without the video. The walk tries the video again every artemis.iris.ingestion.reconcile.video-pending-recheck (default 6 hours). A unit with no other content than such a video fails and is retried later.
• Lost runs. A run lost to an Iris restart, a lapsed worker lease, or an abandoned claim is queued again without using its retry budget. After artemis.iris.ingestion.max-unsettled-attempts (default 3) such attempts in a row, the next attempt counts as a failure, so the normal retry limit stops a unit that keeps losing its runs.

Atlas model configuration

The LLM-backed part of Atlas is off by default and is turned on with artemis.atlas.atlasllm.enabled. It covers the course chat agent, autonomous competency orchestration, the tool surfaces they call, and the Responses adapter, and it needs a chat model configured under spring.ai. Leaving it off keeps competencies, learning paths, and learner profiles available and loads none of those beans, so an installation without an LLM starts faster and runs neither the content-change scheduler nor the autonomous exercise event listener. It is separate from artemis.atlas.atlasml.enabled, which gates the external AtlasML service; either can be enabled without the other.

Set the flag in the configuration directory the server reads at startup, or as the environment variable ARTEMIS_ATLAS_ATLASLLM_ENABLED. Setting it in a copy of application-artemis.yml inside the deployed artifact has no effect, because the core profile is activated after artemis and the value in application-core.yml wins.

Autonomous competency orchestration uses gpt-5.6-luna with xhigh reasoning. Stateless Creator, Assigner, and Editor workers use the same model with high reasoning, as does narrative flavor stripping. Interactive Atlas chat has its own artemis.atlas.chat-model setting.

artemis:
    atlas:
        atlasllm:
            enabled: true
        flavor-strip-model: gpt-5.6-luna
        flavor-strip-reasoning-effort: high
        orchestrator:
            model: gpt-5.6-luna
            reasoning-effort: xhigh
            worker-model: gpt-5.6-luna
            worker-reasoning-effort: high
            responses-api-enabled: true

The Responses adapter uses the credentials, base URL, timeout, proxy, and HTTP customizers configured under spring.ai.openai. Configure a provider or gateway that supports /responses, the selected model/deployment, reasoning effort, function tools, and encrypted reasoning replay with store: false. For OpenAI or an OpenAI-compatible gateway, include /v1 in the base URL and disable microsoft-foundry; for Microsoft Foundry, use the provider-specific configuration described in Hyperion setup. Verify model/deployment availability on the chosen provider before enabling the feature. These settings do not provision a model deployment.

Responses is enabled by default for orchestration, its workers, and flavor stripping. Set artemis.atlas.orchestrator.responses-api-enabled: false to explicitly route all three through the shared Chat Completions client. Choose model/deployment identifiers supported by that endpoint; no automatic transport fallback occurs after an error. Leave flavor-strip-model empty to disable stripping. If stripping fails or its selected client is unavailable, Artemis retains the original text.

Each autonomous run has a fixed tool-call budget. A run that exhausts it, or ends without a verified result, ends as failed if it changed nothing and as partial otherwise, and Artemis does not retry it automatically. The developer AI pipeline catalog lists the exact limits.

Atlas agent

Enable the Atlas agent

The Atlas agent consists of the AI Competency Assistant, a chat in which instructors build competencies, relations, and exercise links and approve every change, and automatic competency updates, which change competencies and their exercise and lecture-unit links without prior approval. The instructor documentation describes both from the course perspective. Several switches have to be on, in this order:

Switch	Where	What it unlocks
artemis.atlas.enabled	Server configuration	Competencies, learning paths, and the Atlas (Adaptive Learning) module.
artemis.atlas.atlasllm.enabled	Server configuration (see above for the core profile)	Loads the chat and the automatic updates. Without it, none of the Atlas LLM code runs. Shown as Atlas AI (LLM) on the Features screen.
Atlas Agent	Runtime toggle on the Features screen, off by default	Shows the AI Competency Assistant and Suggest competencies to instructors, and allows automatic updates.
Atlas Auto-Orchestration Enabled	Course edit form, visible only to administrators, off by default	Automatic competency updates for this course. Debounce Window Override (seconds) and Daily Run Limit Override change the defaults for this course. Turning it off discards the changes still waiting.
scheduling profile	At least one server node	Starts automatic runs. Manual Suggest competencies runs do not need it.

Turning off the Atlas Agent toggle hides the chat in the client and blocks Suggest competencies and automatic updates on the server, but the chat endpoint itself is not guarded by the toggle. To stop all Atlas calls to the language model, turn off artemis.atlas.atlasllm.enabled. Turning anything off never changes existing competencies, although a run that is already in progress still finishes.

Atlas sends course content to the configured model: problem statements, example solutions, quiz questions with their correct answers, lecture-unit text, and, for the chat, the course description and the instructor's messages. It sends no student submissions or other personal student data. The instructor documentation lists the data in detail.

AtlasML suggestions

artemis.atlas.atlasml.enabled connects Artemis to the external AtlasML service, and the Atlas Machine Learning runtime toggle (off by default) controls its use. The toggle gates the AI suggestions for competency links in the exercise forms and for relations in the relation form, which editors and instructors use; it also gates synchronizing competency changes to AtlasML and the similarity shortlist of automatic updates. The AI Competency Assistant calls AtlasML whenever the service is configured, independently of the toggle.

Chat and scheduling settings

Property	Default	Meaning
artemis.atlas.chat-model	gpt-5.4-mini	Model of the AI Competency Assistant.
artemis.atlas.temperature	0.8	Temperature of the AI Competency Assistant.
artemis.atlas.orchestrator.debounce-window-seconds	1800	How long a course's content must stay unchanged before an automatic run starts.
artemis.atlas.orchestrator.max-daily-orchestrations	10	Automatic runs per course and day. The count resets at midnight in the server's time zone.

The model and reasoning settings of automatic updates are shown in the YAML example above. Administrators can override the two scheduling values per course in the course edit form.

Costs and notifications

The defaults limit automatic runs, but they are no hard cost ceiling. Suggest competencies runs ignore the waiting time and the daily limit and do not count towards it, and the per-course Daily Run Limit Override has no upper bound. Artemis records the token usage of automatic updates and flavor stripping, which appears in token usage tracking once the model costs are configured under artemis.llm.model-costs. The chat conversation of the AI Competency Assistant is not recorded.

After each automatic run that changed something, stopped halfway, or failed, Artemis sends an email listing the changes (up to 50) to the instructors of the course and to all active administrators. Every recipient can turn it off per course in the course notification settings, under Automatic competency updates (instructors); there is no instance-wide switch.

Troubleshooting

Symptom	Cause and fix
Atlas AI (LLM) stays inactive although it is enabled	The value was set in a packaged application-artemis.yml, which application-core.yml overrides. Set it in the external configuration or as ARTEMIS_ATLAS_ATLASLLM_ENABLED.
Suggest competencies fails with "Atlas chat model is not configured"	No chat model is configured under spring.ai. Automatic runs then fail, are retried until the daily limit is reached, and send failure emails; the chat answers "Atlas Agent is not available. Please contact your administrator."
Automatic runs never start in any course	No server node runs the scheduling profile.
Instructors do not see the chat button	The Atlas Agent toggle or Atlas AI (LLM) is off, or the user is not an instructor of the course.

Related documentation

• Setup of extension services
• Atlas agent for instructors
• Hyperion setup
• Global Search & Weaviate setup
• Iris student documentation
• Developer AI pipeline catalog