A public, candidate-facing version of the product and engineering workstreams a Founding Platform & AI Systems Engineer should be ready to own, review, or challenge.
These are not full internal specifications. They are public technical briefs that summarize the areas where a founding engineer should be able to reason clearly, make tradeoffs, and convert product requirements into safe, testable systems.
| Area | What we are evaluating | Why it matters |
|---|---|---|
| System boundaries | Can you keep child, parent, teacher, school, and internal roles separated? | Unsafe access patterns break trust before product-market fit can be tested. |
| AI safety | Can you design around guardrails, prompt attacks, model fallback, and output integrity? | Children should never become experimental edge cases for general-purpose AI. |
| Execution discipline | Can you move from PRD to Jira to build to QA without silently redefining scope? | Early-stage speed only works if product truth is preserved. |
Every session or request should enter the system through an identity and role boundary. A founding engineer should be able to design admission logic that validates user identity, role claims, session context, and authorization before any child-facing workflow proceeds.
Before messages reach AI services, the platform must screen for unsafe content, denied topics, personally identifiable information, and adversarial prompt behavior. The engineer should understand both safety UX and enforcement design.
JurneeGo’s child-facing AI output should be generated through a controlled pipeline. Curator notes, translation layers, and analytics may render or annotate the canonical response, but should not secretly rewrite it.
Shared learning means the child is not interacting with AI alone. The platform must synchronize session events across child, parent, and teacher views while preserving agency, visibility, and role permissions.
Learning analytics, reporting, and notification workflows should not slow the child-facing learning experience. A founding engineer should design asynchronous processing that is reliable, observable, and safe for sensitive data.
The platform needs rigorous handling of provider credentials, storage credentials, safety logs, model calls, access events, and operational telemetry. This is not optional infrastructure; it is part of trust.
JurneeGo’s internal operating rule is simple: product decisions and PRDs explain the work; Jira tracks execution. A founding engineer should be comfortable turning approved product requirements into Jira epics, stories, tasks, bugs, QA criteria, and completion evidence.
Understand the user role, safety constraint, product behavior, and non-goals before implementation.
Convert requirements into backend, frontend, AI pipeline, data, logging, QA, and release tasks.
Keep canonical AI output, curator annotations, and presentation layers separated unless an approved system-level process says otherwise.
Closed tickets are not enough; the feature must be tested, accepted, and evidenced.
Before applying, candidates may submit a short written response, diagram, or component breakdown answering:
Your design should consider system boundaries, role-based access, safety guardrails, AI orchestration, prompt context management, logging, monitoring, audit visibility, reliability, and deployment strategy.