Nex-OS Product Brief

Version: 0.4 — Sections 1–5 complete; founder-reviewed Date: 2026-05-07 Owner: Fadl Al Tarzi, Founder & CEO Status: In progress — sections added iteratively with founder review between each

Purpose: The single source of truth for Nexford's transformation into a fully AI-native university. Every domain, every initiative, every team member building within Nex-OS reads this first. This is not a strategy document — it is an operating manual for how Nexford is built from here.

Contents

1. Mission and Operating Model ✅
2. The Data Architecture ✅
3. The Domain Map ✅
4. Per-Domain Briefs ✅
5. The Integration Layer ✅
6. Build Governance — pending founder review of Section 5
7. 6-Month Build Sequence — coming

1. Mission and Operating Model

The mission

Nexford University exists to deliver superior learner outcomes at a fraction of the cost of traditional universities — enabling learners in North America and across the world equally to access world-class, employer-relevant education and join the global grid of work.

Nex-OS is how we get there at scale. It is not a technology initiative. It is a complete redesign of how the university operates — built from scratch around AI-first workflows, with the advantage of real customers, real data, and real learnings from years of operation.

We are not automating what we currently do. We are redesigning what we do, then automating it.

Nexford is a public benefit corporation. This initiative is not about corporate optimization — it is mission-critical. Growing the learner base means impacting more lives. Remaining operationally efficient means remaining affordable. These are the same goal. Every system built within Nex-OS exists in service of social and economic mobility — not in spite of it.

The design constraint that governs everything

The measure of success is not efficiency. It is metric movement.

Operating more efficiently without moving the core metrics delivers no value. Every system, every initiative, every AI workflow built within Nex-OS is evaluated against one question: did the metric move?

The northstar metric is number of active learners. It is a lagging indicator that can only move when the full customer lifecycle pipeline is working. It cannot be gamed by optimising one stage. Everything we build is ultimately in service of this number.

The current primary constraint on northstar growth is cost of acquisition. Nexford's current acquisition model is predominantly sales-led — human-intensive, expensive per learner, and structurally unable to scale to 10x active learners at acceptable CAC. The delivery side of the business has a clearer improvement path; the growth side is the harder problem. Nex-OS is designed to address both, but the acquisition model is the bigger unlock. The strategic answer is a shift from sales-led to predominantly product-led growth: the product itself — the learner experience, the outcomes it produces, the community it creates — becomes the primary acquisition engine. This is a design requirement that applies to every domain, not a marketing strategy.

The operating model

These are not guidelines. They are design constraints. Every workflow, every tool, every domain is built against them.

Before reading the constraints below: Nex-OS is designed to elevate human work, not replace it. As rule-based and routine decisions are progressively handled by AI, what remains for humans is the work that genuinely requires human judgment — complex context, relationship-critical moments, high-stakes calls where experience and empathy matter. A team operating within Nex-OS is not a smaller team doing the same work — it is a team freed from low-value execution and focused on decisions that actually require them. This is the design intent. Read the constraints below in that context.

1. AI acts first. Always. AI initiates the work. It takes the first action, makes the first assessment, executes the first communication, produces the first output. Humans do not initiate workflows that AI could initiate. If a human is doing something that could be triggered by a system, that is a design failure to be corrected.

This is not a constraint on human authority — it is a constraint on human time. When AI acts first, humans receive better information faster, and can direct their attention to the judgment call rather than the preparation for it.

2. Systems trigger humans. Humans do not manage systems. Human involvement is triggered by the system, not by the human deciding to check something. When a human is needed, the system surfaces exactly what they need to act — context, recommendation, decision options, and consequences. Human attention is a scarce resource. The system manages it.

3. Rules get codified. Binary decisions get automated. If a human is making a decision based on a fixed rule, that decision belongs to the machine. Binary decision-making — effectively if-then logic — is never a human task. This applies equally to the learner experience: learners are empowered to self-serve in real time rather than waiting for a human to execute a rules-based approval. A machine making the same decision faster, with perfect consistency, is a better outcome for the learner and a better use of human capacity. Human memory is a point of failure. Codified rules are not.

4. Human involvement phases down over time. Every domain starts with more human involvement and reduces it as the system validates. Short-term: humans cover what AI cannot yet do cost-effectively or reliably. Medium to long-term: humans hold judgment on what genuinely requires human insight — creative direction, complex context, relationship-critical moments, empathy-requiring escalations. Human involvement is triggered by systems and well-defined in scope — it is not open-ended. Where regulators or accreditors require documented human involvement, that involvement is designed as a lightweight, auditable checkpoint — not a process bottleneck.

5. Token-max, not headcount-max. The best measure of AI-nativeness is willingness to run an uncomfortably high API bill because it is replacing what would have cost far more in headcount. Nexford's competitive advantage is not a leaner org chart — it is an exponentially more capable operation at the same or lower cost. Design systems that maximise token usage in service of outcomes.

6. The data flywheel is the moat. Every interaction with every lead, learner, and graduate enriches the system. Every enrichment improves the next interaction. This is not a reporting layer — it is the central spine of the entire operation. Every domain is built to feed the flywheel and draw from it. The compound effect of this loop, sustained over time, creates an advantage that cannot be replicated by institutions not designed around it from the start.

7. Every touchpoint speaks with one voice. Brand tone is a system-level constraint, not an individual judgment call. Whether a learner receives an automated message, a system notification, a chat response, or a human-written communication — the voice, tone, and standards are consistent. This is enforced at the infrastructure level, embedded in every AI-generated communication, and audited as part of normal operations. Inconsistent communication is a brand failure and a trust failure.

8. Compliance is a design constraint, not a review step. Nex-OS operates within Nexford's full regulatory framework and is built to satisfy future requirements in advance rather than retrofit later. Current and anticipated frameworks:

• DEAC accreditation — current national accreditor
• Middle States Commission on Higher Education (MSCHE) — regional accreditation actively being pursued; systems are being built to MSCHE standards from the start, not updated when candidacy is granted
• DC Higher Education Licensure Commission (HELC) — US licensure
• Department of Veterans Affairs (VA) — Nexford is authorized to enroll US servicemembers funded by the VA; VA regulations apply specifically to that population and are treated as a distinct compliance layer that does not apply to the global learner population
• Applicable data protection regulations across the markets we serve

No domain goes live without a compliance assessment. Compliance requirements are identified at the design stage and built in — not added at the end. This protects learners, protects the institution, and protects the mission.

9. Design for the full lifecycle. Build in sequence. The system is designed for the full customer lifecycle — from the first marketing touchpoint to post-graduation outcomes. It is built domain by domain in a deliberate sequence, but each domain is designed from the start to integrate with the whole. Nothing is built in isolation. Nothing is siloed.

10. The product earns acquisition. The current acquisition model — predominantly sales-led, human-intensive, expensive — cannot scale to 10x at acceptable CAC. The target model is product-led: learners who achieve their goals refer others; employers who see outcomes recommend Nexford to their teams; alumni who advance their careers become the most credible proof point the business has. Every feature built and every course designed must be held against this question: does this create a condition where a learner tells someone else about Nexford? Product-led growth is not a marketing function — it is a product design requirement that applies to every domain building anything learner-facing.

11. Confidence scores gate autonomy. WorQ resolves all human work. Every AI decision in Nex-OS carries a confidence score. When the score exceeds the defined threshold for that decision type, AI acts autonomously. When it falls below, the decision is not made — it is escalated to a human. Every escalation, from every domain, across every system, routes into WorQ.

WorQ is the single central task management system for all of Nex-OS. No team member manages multiple tool-specific inboxes or checks individual systems for pending actions. Every triggered human task arrives in WorQ with full context: the AI's confidence score, its recommendation, the supporting data, and the consequence of each available action. The human's job is to judge — not to investigate.

Task assignment in WorQ is governed by user levels that reflect the skills required to take a given type of decision. Titles are a practical proxy at setup, but skill-based assignment is the underlying principle. A task requiring academic judgment routes to a different user level than a task requiring commercial or operational judgment. Multi-layer approval — where more than one human must approve before a decision is actioned — is available but reserved for decisions with high irreversibility risk or significant institutional consequence. It is the exception, not the default.

Confidence thresholds are set per decision type and per domain — a threshold for a marketing communication is not the same as a threshold for an admissions eligibility decision or an academic escalation. Thresholds are set by the domain champion and founder-approved; they are not inferred by the system. They are reviewed and tightened over time as the system accumulates outcome data and calibration improves.

12. The brief governs. Champions execute. Each domain has a champion who owns the build. The champion interprets this brief for their domain, proposes their architecture, and gets founder sign-off before building. The brief is specific enough that 80% of decisions are pre-made within it. Champions escalate deviations — they do not make unilateral calls on anything that touches the architecture or the operating model.

13. Tools are selected by AI analysis, not champion preference. When a domain requires tooling, the selection process begins with an AI-led audit of all tools currently in use across Nexford. The AI produces a structured analysis: which existing tools are fit for purpose and should be kept, which should be replaced, and — where gaps remain — a recommendation for what to add. Champions do not propose tooling from scratch. They review the AI recommendation, validate it against domain requirements, and bring a proposal informed by that analysis to founder sign-off. This applies to all tooling decisions — CRM, LMS, communications, analytics, engineering, and any new capability layer.

What this is not

This is not a project to automate existing processes. Existing processes will be examined only to the extent they reveal what is and is not working. The question is never "how do we automate this?" It is "what outcome is this trying to achieve, and what is the right way to achieve that outcome in an AI-native system?"

This is not a tool adoption initiative. Individual AI tools used by individual team members are not Nex-OS. Nex-OS is a connected operating system in which every domain feeds every other domain through shared data, shared infrastructure, and a shared view of the customer lifecycle.

The metric chain

The northstar is active learners. It is produced by the full pipeline working end to end. Every stage has a metric. A metric that does not move is not a reporting problem — it is a signal that a domain is failing its job and requires investigation.

All metrics are reported split by RoW and NAM. These are different markets at different stages of maturity. A blended metric hides the truth in both directions. NAM northstar conversion rate: TBD. RoW northstar lead-to-enrollment conversion rate: 4%.

Actual baseline numbers to be inserted once sourced. Placeholders retained so the architecture is designed around the correct metrics from the start.

2. The Data Architecture

What this is — and what it is not

The data architecture is the central nervous system of the entire operation and the single source of truth for every metric that matters. Every domain feeds it. Every domain draws from it. The system changes its own behaviour based on what it learns. Humans are surfaced insights and triggered into action by it — and when they are, they arrive with full context to act well.

This is not a passive reporting layer or a dashboard humans log into when they feel like checking something. But it is the place any person in this organisation goes when they need to understand a number, investigate a trend, or make an informed call. The goal is not to remove humans from decisions — it is to ensure every human decision is better than it would have been without the system. Humans do fewer things, but what they do is supported, contextualised, and high-leverage. Human involvement and data infrastructure are designed together: every human touchpoint is designed around the data that makes that touchpoint effective.

The flywheel works as follows:

This loop, sustained over time, creates an advantage that cannot be replicated by institutions not designed around it from the start. The data is the moat — not the AI models, which are available to everyone.

A critical paradigm shift: The goal of this system is not graduation. Graduation is a milestone. The goal is the learner's career advancement and the life outcomes they enrolled to achieve. This reframes everything. From the admissions process onwards — before enrollment is confirmed — the system captures the learner's current skills baseline, their stated career goal, and where they are trying to get to. This is not a post-enrollment onboarding task. Goal and skills data is collected during admissions so that the program fit can be validated before the learner commits, and so that goal-anchored communication begins from day one with no standing-up period. Every communication, every intervention, every academic nudge is anchored to that goal — not to course completion for its own sake. A learner who completes a module is not celebrated for completing the module; they are shown how that module moves them closer to where they want to be.

This requires the data infrastructure to hold labor market intelligence alongside learner data. The system must understand what skills lead to which roles in which markets, so it can make the connection between what the learner is learning today and the outcome they are working toward. Post-graduation, the same infrastructure tracks whether the outcome was achieved — and that signal feeds back into program design, content priorities, and how future learners in similar positions are supported.

Data domains

Data flows into the architecture from every stage of the customer lifecycle. Each domain owns its data and is responsible for its quality. All domains write to and read from the shared layer — there are no departmental silos.

1. Lead and marketing data

• Source attribution: which channel, campaign, ad, creative, and message produced each lead
• Demographic signals: nationality, age, gender, market (NAM / RoW)
• Behavioural signals: pages visited, content engaged, time on site, repeat visits
• Conversion outcome: did this lead apply, enroll, start — and how long did each transition take

2. Admissions and enrollment data

• Application content and completeness
• Conversion triggers and friction points
• Enrollment timing and program selection
• Communication touchpoints and their outcomes during the admissions journey

3. Learner goal and skills data (captured at enrollment, updated throughout)

• Stated career goal and target role at the point of enrollment
• Current skills baseline: self-reported and validated against assessments over time
• Skills gap relative to target role, derived from labor market domain (below)
• Goal progress signals: external milestones the learner reports (job change, promotion, new role)
• Goal revision history: if the learner's goals shift, the system adapts — it does not assume the original goal still holds

4. Academic and learning data

• Academic start behaviour and timing
• Assessment attempts, scores, retake patterns, and brute-force flags
• Module completion timing and sequence
• Canvas activity patterns (login frequency, content access, discussion engagement)
• Submission timing relative to deadlines
• Skill demonstration signals per assessment: which competencies are confirmed, which remain gaps

5. Learner success and support data

• All interaction logs (chat, voice, email, human advisor)
• Escalation patterns and outcomes
• Intervention type, timing, and effectiveness per learner profile
• At-risk signal history and resolution
• Context surfaced to the human advisor at every triggered touchpoint: the learner's goal, current progress, risk signals, and recommended action — so human involvement is always informed, never cold

6. Financial and operational data

• CAC, ARPL, CRC, LTV per cohort, market, program, and acquisition channel
• Payback period by segment
• Operational cost per function over time (measures efficiency gains as Nex-OS matures)
• WorQ operational metrics: escalation volume and rate by domain, resolution time by task type and user level, task type distribution, human override rate, backlog depth, and confidence score distribution at escalation — these collectively measure the efficiency of the human-AI operating model and its improvement over time

7. Graduate and alumni data

• Graduation timing and program completion path
• Employment outcomes: salary change, promotion, role achieved relative to stated goal at enrollment
• Goal achievement rate: did the learner reach what they came here for? This is the ultimate outcome metric
• Alumni NPS and referral behaviour
• Post-graduation engagement and continued skill development

8. Labor market intelligence

• In-demand roles by market and sector: what employers are hiring for across NAM and RoW
• Skills-to-role mapping: which competencies are required for which roles, validated from employer signals not academic assumption
• Salary and progression benchmarks by role, market, and experience level
• Emerging skills signals: which capabilities are growing in demand and are not yet reflected in current curriculum
• Program-to-outcome alignment: do Nexford graduates get the roles they targeted, and do employers value the skills they built?

This domain feeds two critical functions: (1) personalising every learner's journey around a goal that is grounded in real market data, not aspiration alone, and (2) keeping curriculum design responsive to what the market actually rewards.

The personalization layer

The data architecture makes true personalization possible — not segmentation, but individual-level adaptation. This applies across the entire lifecycle:

• Marketing and nurture: which message, channel, tone, and timing converts which lead profile in which market
• Learner communications: frequency, channel, and tone adapted to individual engagement patterns and cultural context — but the substance of every communication is anchored to the learner's stated career goal. A learner working toward a finance role in Lagos hears something different from a learner working toward a management role in Houston, even if they are in the same course, at the same point in the same module
• Success interventions: which intervention type is most effective for which learner profile at which point in their journey
• Academic support: tutor and advisor responses calibrated to the learner's academic history, current performance, skills gaps, and the specific goal they are working toward

The goal-anchored communication principle. Courses and programs are not the destination — they are the vehicle. All learner-facing communications are framed around progress toward the learner's goal, not completion of administrative milestones. "You're one module away from finishing this course" is the old model. "You're building the financial modelling skills that the role you're targeting requires — here's where you stand" is the new one. This requires the system to know the goal, understand the gap between where the learner is today and where they want to be, and connect each academic activity to that gap explicitly. The data infrastructure exists to make this connection possible at scale and at the individual level.

The cultural layer is non-negotiable. Nexford serves learners across more than 100 countries. Communication norms, expectations around formality, timing sensitivity, and relationship-building vary significantly across markets. The personalization engine accounts for this — it does not apply a single global voice to a globally diverse population.

Profiles update continuously. Every new signal refines the profile. There is no static learner record — only an evolving one.

Analytics — two consumers, two designs

The analytics layer serves two fundamentally different consumers and must be designed for both from the start.

Human-facing analytics Surfaces the metric chain in real time, split by NAM and RoW. Designed for decision-makers — not analysts. The question it answers is always: what needs my attention right now, and why? Alerts are pushed to humans when metrics move outside expected bounds. Humans do not log in to check dashboards — the system tells them when something matters.

When a human is triggered into action, the system does not just flag the issue — it surfaces the supporting data required to act well. A human advisor contacted about a at-risk learner sees the learner's goal, their engagement history, their skill signals, previous interventions and their outcomes, and a recommended action. They do not arrive cold. A human reviewing a conversion rate drop sees which segment broke, which campaigns were running, what changed, and what similar drops have looked like historically. The architecture is designed so that human judgment is applied on top of complete information — not in spite of incomplete information.

Key views:

• Northstar (active learners) and full metric chain, with trend and variance
• Domain health: is each domain moving its owned metric?
• Cohort tracking: where are specific enrollment cohorts in the lifecycle pipeline?
• Learner goal progress: across active learners, what proportion are on track toward their stated goals?
• Intervention effectiveness: which actions are working, which are not?
• Labor market alignment: are graduate outcomes matching the goals learners enrolled with, and matching what the market rewards?

AI-facing analytics Structured data feeds consumed by AI agents across the system to make decisions and trigger actions. This is not visualisation — it is queryable, reliable, low-latency data that agents read in real time.

Examples:

• At-risk detection agent reading persistence signals, attempt counts, and login frequency
• Marketing optimisation agent reading conversion outcomes by campaign and creative
• Success intervention agent reading escalation history and intervention effectiveness by profile

The distinction matters for how this layer is built. Human-facing analytics optimises for clarity and narrative. AI-facing analytics optimises for structure, freshness, and reliability.

Confidence scores

Every AI decision in Nex-OS produces a confidence score alongside its output. The score determines, at the moment of decision, whether AI acts autonomously or escalates to a human via WorQ. This is the mechanism that makes AI-first operation safe: autonomy is earned at the decision level, not assumed.

Confidence scores are not discarded after the decision is made — they are stored as data and feed back into model calibration over time. A high-confidence decision that produces a wrong outcome is a calibration failure; it is more valuable as a learning signal than a low-confidence wrong decision that was already flagged. Over time, the system learns where it is reliably right and where it is not, and thresholds adjust accordingly.

Two distinct thresholds exist per decision type:

• Autonomy threshold — above this, AI acts without human involvement
• Escalation threshold — below this, the decision routes to WorQ for human resolution

Decisions between the two thresholds can be handled with a lightweight human confirmation — a low-friction approval rather than a full review. This band narrows as the system calibrates.

Thresholds are set per decision type and per domain. An admissions eligibility decision has a different threshold than a marketing message personalisation decision. Thresholds are set by the domain champion and founder-approved; they are never inferred autonomously by the system. They are part of the domain's architecture proposal and are reviewed as the system matures.

Data governance principles

One source of truth per data type. No department maintains its own version of learner data, campaign data, or financial data. Every domain reads from the shared layer. Conflicts are resolved at the architecture level — not by teams maintaining parallel spreadsheets.

Quality is owned at the source. The domain that produces data is responsible for its accuracy. A downstream system consuming bad data is a symptom of an upstream ownership failure.

Privacy by design. Data collection, retention, and access rights are defined at the architecture stage — not added as a compliance review before launch. VA-specific data is handled under its own access and retention rules and is not commingled with global learner data. GDPR and applicable data protection regulations are treated as design constraints per market.

All metrics are split by NAM and RoW. A blended metric is not a metric — it is noise. Every report, every alert, every AI decision is market-aware. As Nexford expands into new markets, the architecture adds market segmentation without restructuring.

The baseline is established in Phase 1. Before Nex-OS can measure improvement, it must measure the current state. Establishing the baseline across the full metric chain is a Phase 1 deliverable — not a future state. Where current data systems do not capture a metric cleanly, sourcing it or instrumenting it is a prerequisite for that domain going live.

Two distinct baselines are being established. The first is the operational metric baseline — current conversion rates, persistence rates, CAC, and so on — which measures the starting point Nex-OS will improve from. The second is the learner goal and skills baseline — this data does not exist in current systems and is net-new infrastructure being built from scratch. It cannot be migrated or cleaned up from legacy records. It begins accumulating from the first cohort that goes through the new admissions process, and its value compounds over time as the system learns which goals, profiles, and skills patterns predict which outcomes.

3. The Domain Map

What a domain is

A domain is a discrete operational unit with a defined champion, a set of metrics it is accountable for moving, and a scope of AI and human workflows. Domains are not departments — they do not map to org chart lines. They are defined by the customer lifecycle and by what outcomes they own. A single person may run a domain at launch; a domain may eventually support a team. What defines it is metric ownership, data quality responsibility, and integration with the shared architecture.

Every domain in Nex-OS:

• Has a champion who owns the build — metric accountability may be assigned to the champion or held separately depending on how the operating model evolves; the two are not permanently tied at the domain design stage
• Contributes data to the central layer and draws from it
• Is designed to integrate with adjacent domains from the start — nothing is built in isolation
• Starts with higher human involvement and reduces it as the system validates
• Does not go live without a compliance assessment completed at the design stage

Domains are described in this section at the level of what they own and how they connect. Each domain's full operating logic — workflows, AI roles, human triggers, data contracts, and build plan — lives in Section 4.

The nine domains

Nex-OS comprises nine domains. Six are customer lifecycle domains, each owning a defined stage of the metric chain. Three are enabling domains that provide the infrastructure the lifecycle domains run on. No lifecycle domain operates without the enabling domains beneath it.

Customer lifecycle domains

Enrollment and Admissions are distinct domains because they are distinct functions. Enrollment (domain 2) is the sales function: it owns the lead relationship from first contact, captures career goals and skills baseline, drives the application submission, and converts admitted applicants into enrolled learners — accountable to CAC and commercial metrics. Admissions (domain 3) is an academic function: it is activated only when an application arrives via ApplyNXU, evaluates it against Nexford's accreditor-defined admission requirements, and returns a decision. The handoff between them in both directions is a defined integration point with a data contract, not an informal process.

Enabling domains

Product (domain 8) is not a pipeline stage — it does not own a conversion metric. It is the design intelligence layer that shapes every domain's learner-facing experience. Its role is intentional: before any feature is built or course is designed, Product ensures the design starts from what learners actually need to achieve their goals, not from what is operationally convenient. This principle applies equally to platform features and to courses, which are treated as products with user research, design iterations, and outcome measurement. Product is an enabling domain but one that must be involved early — design decisions made without it are harder and more expensive to correct later.

Product also carries the product-led growth mandate. Nexford's path to 10x active learners runs through the product, not through scaling a sales-led acquisition model that is too expensive at the volumes required. Product is responsible for designing the mechanics that turn learner success into acquisition: referral loops, employer advocacy pathways, alumni community, shareable outcomes, and the kind of learner experience that generates word of mouth without prompting. This is not separate from the quality mandate — it is the same thing. A product that genuinely helps learners achieve their goals creates the conditions for product-led growth. A product designed only for operational efficiency does not.

The primary metric for tracking PLG progress is learner referral rate — the percentage of active learners and graduates who refer at least one new learner. This metric must consistently increase over time. A flat or declining referral rate is a product signal, not a marketing signal: it means the experience is not generating the advocacy that product-led growth requires. One of Product's explicit objectives is to move this number.

How the domains connect

The lifecycle domains operate in sequence. Each stage depends on the stage before it delivering its output. A breakdown at any stage is visible in the metric chain and traceable to the responsible domain.

The dashed arrow from Graduate Outcomes back to Marketing is intentional. Graduate outcomes data — goal achievement rates, salary changes, employer sectors — feeds marketing positioning and the targeting of future leads. The system eventually knows which learner profiles achieve which outcomes, and acquires more of them. This is the long loop of the data flywheel.

Academic Operations (domain 5) sits alongside the lifecycle rather than within it. It does not own a pipeline conversion metric. It owns the quality of the academic product that the rest of the system delivers. When Learner Success detects that a cohort is underperforming on a specific module, Academic Operations is the domain that investigates content and assessment quality as the cause. When Graduate Outcomes finds that a CLO is not translating into job-relevant skills, Academic Operations is the domain that redesigns it.

The three enabling domains are not shown as separate nodes in the diagram above because they are not sequential stages — they underpin all six lifecycle stages simultaneously. Data & Intelligence is the central nervous system. Technology & Platform is the infrastructure. Financial Operations measures cost and value across everything.

The NAM / RoW dimension at the domain level

All six lifecycle domains operate differently across NAM and RoW. This is not a reporting distinction — it is a design constraint that applies inside each domain.

Marketing & Growth: The current acquisition model is predominantly sales-led — high human involvement, high CAC, limited scalability. This is the model Nex-OS is designed to move away from. The target state is predominantly product-led: acquisition driven by the quality of the learner experience, graduate outcomes, employer recognition, and alumni advocacy — with paid and sales channels retained as a secondary engine, not the primary one. This is a multi-year transition, not a switch. In the near term, paid and sales channels continue to run while the product-led infrastructure is built. The Marketing & Growth domain is accountable for managing that transition — reducing blended CAC over time as product-led channels mature, not simply optimising the existing model.

NAM and RoW are also different acquisition strategies with different channel mixes, content strategies, messaging, and partnership models. A blended marketing approach masks failure in one market behind success in the other. The PLG transition will also play out differently in each market and must be designed with that in mind.

Enrollment: Conversion dynamics differ. The RoW northstar lead→enrollment conversion rate is 4%. The NAM equivalent is TBD. Financial considerations, program pricing perception, and communication cadence vary significantly between markets. NAM and RoW enrollment workflows are treated as distinct funnels with distinct metrics, not as one blended pipeline.

Admissions: The eligibility requirements evaluated differ by market. NAM applicants are subject to different documentation requirements, credential evaluation norms, and regulatory obligations (including VA eligibility verification for servicemembers) than RoW applicants. The admissions workflow is market-aware by design — the compliance requirements it enforces are market-specific, not a single global standard applied uniformly.

Learner Success: At-risk signals, cultural communication norms, and intervention effectiveness vary by market. A message tone that works for a learner in Lagos will not land the same way for a learner in Toronto. The intervention engine is market and profile-aware — not globally uniform.

Graduate Outcomes: Nexford prepares learners for both local and global careers — a learner's physical location does not define the ceiling of their ambition or the market they are entering. Outcome measurement is anchored to the individual learner's stated goal captured at admissions, not to geography. A learner in Lagos targeting a global finance role is measured against that goal, not against local market norms. The graduate outcomes domain tracks goal achievement at the individual level; market context is one input to interpreting the data, not the primary frame.

The enabling domains are architecture-level market-aware by design: every data record carries market attribution, every AI decision is made in market context, every metric surfaces with a NAM and RoW split.

Domain ownership and the champion model

Each domain has a single champion. The champion:

• Interprets the brief for their domain and proposes the domain architecture
• Gets founder sign-off before building
• Owns the data quality produced by their domain
• Escalates deviations from the architecture or operating model — they do not make unilateral calls on anything that touches shared infrastructure or design principles

The brief is specific enough that 80% of decisions are pre-made within it. Champions are not interpreting an open brief — they are executing a constrained one and escalating the 20% that requires judgment.

No domain goes live without sign-off at three gates:

1. Architecture gate — domain design and data contracts reviewed before build begins
2. Compliance gate — regulatory requirements identified and built in, not added post-build
3. Launch gate — baseline metrics instrumented, integration points tested, human triggers verified

Build sequence preview

Domains are built in a deliberate sequence driven by two constraints: dependency order (a downstream domain cannot function without its upstream inputs) and impact priority (earlier stages have higher leverage on the northstar metric and are built first).

The full 6-month build sequence is in Section 7. The principle is: fix the pipeline before optimising any stage of it. A highly optimised retention system built on a broken acquisition pipeline does not move the northstar. Domains are built in lifecycle order, with the enabling domains established first as the foundation everything else runs on.

4. Per-Domain Briefs

WorQ — the human task layer

Every human trigger in every domain flows into WorQ. WorQ is the single central task management system for all of Nex-OS. Team members do not manage tool-specific inboxes or check individual systems for pending actions — they go to WorQ.

Every task in WorQ arrives with full context: the AI's confidence score, its recommendation, the supporting data, and the consequence of each available decision. The human's job is to judge — the system has already done the investigation.

How tasks are routed: User levels in WorQ reflect the skills required to take a given type of decision. An academic escalation routes to users with the relevant academic competency. A commercial decision routes to users with enrollment or financial authority. Titles are used as a practical proxy at setup. As the organisation grows and roles evolve, user levels are the stable assignment mechanism — not org chart position.

Multi-layer approval: Some decisions require sign-off from more than one user before they are actioned. This is available in WorQ but should be reserved for high-stakes, low-reversibility decisions. The default is single-user resolution. Approval chains are defined per decision type, not per individual task.

Confidence score context: Every escalated task shows the AI's confidence score alongside its recommendation. A score just below threshold (borderline escalation) is different from a score near zero (AI genuinely uncertain). Users in WorQ see this context — it calibrates the weight they put on the AI's recommendation versus their own judgment. Human decisions made in WorQ feed back into confidence model calibration over time.

WorQ as an audit and decision log. WorQ is not only a task queue for human escalations — it is the full decision log for the organisation. Every AI decision made across all domains is recorded in WorQ, whether it was resolved autonomously or escalated. Designated auditors can review any decision with filters including: decision type, domain, materiality and consequence level, confidence score range, learner or lead ID, date range, and decision outcome. This makes the system auditable, accountable, and improvable.

Specific team members are designated as auditors per domain. Their job is to conduct regular reviews of AI decisions — not just the ones that were escalated — to identify where the system is making sound calls, where calibration is off, and where a pattern of decisions should be codified into a rule rather than re-evaluated each time.

AI self-audit layer. Periodically and autonomously, the AI conducts its own analysis of its decision outcomes — comparing what it decided against what actually resulted. This is not reactive error correction; it is a structured self-assessment cycle. The output is shared with a pre-defined, limited group of humans who review the AI's own analysis and provide directional input. Their input feeds back into model calibration and threshold refinement. This is a deliberate data flywheel mechanism: the system improves not just from human corrections, but from its own analysis of where it was right, where it was wrong, and what the patterns suggest.

WorQ as an operational efficiency signal. The data produced by WorQ is not just a record of decisions made — it is a continuous indicator of how well the operating model is functioning. The following metrics are tracked and analysed:

• Escalation volume — total tasks entering WorQ per period, broken down by domain and decision type; a domain generating disproportionate volume is a signal that its AI is under-calibrated or its rules are insufficiently codified
• Escalation rate — % of all AI decisions that result in a human escalation. As AI calibration improves and binary decisions get automated, this rate decreases — not because human judgment matters less, but because Nexford can serve significantly more learners without proportional headcount growth. That capacity to scale is what makes high-quality, affordable education financially viable. A falling escalation rate is a mission metric, not a headcount metric.
• Resolution time — average and median time from task creation to human resolution, by task type and user level; long resolution times indicate a human capacity or routing problem
• Task type distribution — the nature of what is being escalated; if a particular decision type consistently escalates, the rule governing it should be examined for codification
• Human override rate — how often humans receiving an AI recommendation alongside an escalation choose to override it; a high override rate on a specific decision type signals that AI recommendation quality for that type needs attention
• Backlog depth — tasks unresolved beyond a defined SLA per task type; a growing backlog is an operational health flag, not a reporting problem
• Confidence score at escalation — distribution of confidence scores on escalated tasks; tasks consistently near-threshold suggest the threshold needs adjustment; tasks consistently near-zero suggest the underlying model needs work

Together these metrics measure the health of the human-AI operating model — not just whether decisions are getting made, but whether the system is getting better at making them autonomously over time.

They also measure something more important for the people involved: the elevation of human work. As rule-based and routine decisions are progressively automated, what remains in WorQ is the work that genuinely requires human judgment — complex context, relationship-critical moments, high-stakes calls where experience and empathy matter. A WorQ that trends toward lower volume but higher-consequence tasks is not a system that needs fewer people. It is a system where the people involved are doing more valuable work than before. This framing matters for adoption: team members who understand that Nex-OS is designed to remove the low-value decisions from their day — not remove them from the organisation — are far more likely to champion it.

Every human decision in WorQ trains the AI. This is a core architectural principle, not a feature. When a human resolves an escalated task — approving, rejecting, or modifying an AI recommendation — that decision is captured as a labelled training signal. The AI learns what the correct decision was, in what context, against what data. Over time, patterns of human corrections refine the confidence model for that decision type, raise the autonomy threshold where the AI is consistently right, and reduce the volume of escalations that domain generates. WorQ is therefore not just an operational queue — it is the primary mechanism by which human judgment is systematically transferred into AI capability. The more consistently humans use WorQ (rather than working outside the system), the faster and more accurately the AI improves.

WorQ is designed architecturally in Section 5 (The Integration Layer). Every "Human roles" section in the domain briefs below is understood to mean: these escalations route into WorQ, not into individual system queues or email inboxes.

How to read these briefs

Each brief defines what the domain does, what it owns, and how it operates. It is specific enough that a champion can design their domain architecture with 80% of decisions already made. The 20% that requires judgment is where the champion brings their proposal to the founder for sign-off before building.

Every brief follows the same structure: Purpose · Metrics owned · Core AI functions · Human roles · Data (in / out) · Integration points · Tooling · Compliance · Build phases.

Data (in / out) refers specifically to cross-domain data flows via the central layer — not all data the domain handles internally. Inputs are what this domain draws from other domains. Outputs are what this domain contributes to the central layer for other domains to use.

Tooling rule: Every tool listed in a domain brief must integrate with the central architecture — no approved integration point, no approved tool. Where a tool category is identified but the specific tool is not yet selected, it is marked "AI-led tool audit required" — the selection process follows Section 1, Operating Model principle 13: AI audits current tooling across Nexford, produces a structured recommendation, and the champion reviews it before bringing a proposal to founder sign-off. Champions do not propose tools from scratch. No domain operates tools outside this list. Dark areas — functions or data flows that exist outside the integrated stack — are a design failure.

1. Marketing & Growth

Purpose Marketing & Growth fills the top of the pipeline — generating the brand awareness and lead volume the rest of the lifecycle depends on. It owns both paid and organic acquisition and is accountable for managing the transition from the current predominantly sales-led model to product-led growth. CAC reduction over time is as important a mandate as lead volume growth.

This domain operates as two distinct sub-functions: NAM acquisition and RoW acquisition. Different strategies, different channel mixes, different conversion dynamics. They share infrastructure but run as separate operations with separate metrics.

Metrics owned

• Brand awareness: search volume, social engagement, follower growth
• Lead volume (NAM and RoW reported separately)
• Blended CAC trend over time
• Learner referral rate — primary PLG progress signal; must consistently increase

Core AI functions

• Marketing operations enforcement: Humans set the strategy — campaign cadence, ad review schedules, content calendars, budget allocation decisions. AI is the operations layer that ensures those decisions are actually executed. It tracks whether scheduled actions have happened, flags when they have not, ensures every action taken is substantiated by data, and surfaces accountability without requiring a human to manage the system manually. Humans decide; AI ensures it happens.
• Lead qualification — Nexa and voice agents: Nexford currently converts fewer than 3% of acquired leads in RoW. A core AI function is qualifying inbound leads before any human is involved. Nexa — a text-based conversational agent built on HubSpot — currently handles this for inbound leads. Voice agents are being deployed to extend the same function to call-based acquisition. AI qualifies leads against defined criteria (intent, program fit, market, financial readiness signals), and only routes qualified leads to a human. Humans speak only with qualified leads — dramatically improving the conversion rate achievable with the same headcount. Nexa optimisation and voice agent deployment are near-term build priorities for this domain.
• Campaign performance monitoring: AI reads conversion outcomes by channel, campaign, creative, and market in real time; flags underperforming campaigns; surfaces reallocation recommendations
• Content generation and personalisation: AI drafts channel-appropriate content variants, adapts messaging by market and lead profile, and tests at scale
• Referral attribution: AI tracks referral sources, links referred leads to the referrer profile, and measures referral conversion rates against non-referral acquisition
• Retention-informed campaign optimisation: AI surfaces correlation data between acquisition channels, campaign types, and learner retention rates — enabling campaigns to be optimised not just for conversion but for enrolling learners who persist. This signal is produced by the acquisition-retention stitching layer in Data & Intelligence (domain 9) and is a shared intelligence feed with Financial Operations (domain 11).

Human roles

• Campaign strategy: humans set strategic direction, budget allocation, and channel priorities — AI executes and optimises within those parameters
• Creative direction: humans approve brand-level creative; AI handles variant generation and personalisation below that level
• PLG transition decisions: when to shift budget from paid to product-led channels is a founder-level call surfaced by data, not decided by the system

Data Inputs: Graduate outcomes and alumni NPS (brand narrative and proof points); referral signals from active learners and graduates; labor market intelligence (employer partnership targeting); learner profiles (look-alike targeting) Outputs: Source attribution per lead; conversion outcome per campaign/creative/channel; referral rate by cohort and market; lead quality scores

Integration points

• Feeds qualified leads to Enrollment (domain 2) — the sales function that converts leads into applicants; Admissions (domain 3) only activates once an application has been submitted via ApplyNXU
• Draws referral and outcome signals from Graduate Outcomes & Alumni (domain 7)

Tooling

• HubSpot — CRM, lead management, email campaigns, marketing automation; primary system of record for leads
• JustCall — SMS and calling for outbound lead outreach
• Paid acquisition platforms (Meta Ads, Google Ads) — integrated via HubSpot for attribution
• Jira / Linear (under evaluation as replacement) — campaign and initiative tracking
• Confluence — playbooks, campaign briefs, brand documentation
• SEO, social scheduling, and content distribution tooling — AI-led tool audit required (Section 1.13), integration required

Compliance

• Marketing communications comply with applicable data protection regulations per market (GDPR, CAN-SPAM)
• Outcome claims (salary increases, career outcomes): compliance is enforced by AI at the point of content creation — any claim generated within Nex-OS is checked against verified graduate data before it leaves the system. This is not a human review step; it is a creation-level constraint. If content is created outside Nex-OS workflows (which should not happen), it is flagged at the approval stage before publication. The operating model only works if all content creation runs through the system — this is why tool governance matters.
• VA-targeted marketing is subject to additional restrictions on deceptive recruitment practices; AI-generated content for this audience is flagged for a mandatory human review checkpoint

Build phases Current state: Predominantly sales-led; paid digital channels driving the majority of leads; limited referral infrastructure; NAM strategy in early development Near term: Instrument referral rate as a baseline metric; build referral attribution; fully separate NAM and RoW reporting; establish PLG baseline Target state: Product-led channels (referral, employer advocacy, alumni network, organic) generating a growing share of leads; paid acquisition as a secondary channel optimised by AI; blended CAC declining year-over-year

2. Enrollment

Purpose Enrollment is the sales function. It owns the lead from the point Nexa or a voice agent qualifies them through to full enrollment confirmation and first payment. This includes preliminary goal and skills data capture, and program fit validation — all of which happen during the Enrollment relationship, not during Admissions. Deep career goal data is collected post-enrollment during the AI-driven New Learner Orientation. Enrollment is also the domain that drives the lead to submit an application via ApplyNXU, at which point Admissions takes over for the compliance review before handing back to Enrollment to close.

Human involvement in this domain is currently high — it is the most sales-intensive part of the operation — and reducing it over time as the system validates is an explicit goal.

Metrics owned

• Lead→application rate
• Application→enrollment conversion rate (NAM and RoW separately)
• Preliminary goal capture completeness (% of enrolled learners with goal data captured before enrollment)
• Time to touch: time from lead qualification to first human contact — a direct measure of how quickly the sales team engages qualified leads
• Sales conversion rate: % of conversations (human-to-lead) that result in enrollment — measures quality of human selling, not just volume
• Conversations per contact: average number of touchpoints before enrollment; fewer = more scalable; shared metric with Marketing — Marketing's job is to deliver leads educated enough to require minimal sales explanation
• Time to enroll: time from contact creation to enrollment confirmation; shared metric with Marketing — a measure of pipeline velocity across both domains
• Direct CAC · Blended CAC · ROAS

Core AI functions

• Preliminary goal and skills intake: AI captures the lead's career goal and an initial skills baseline during the enrollment journey — enough to personalise the conversation and confirm program fit, but deliberately limited to reduce friction. This is a commercial data point, not a deep onboarding record. Deep career goal and skills data is collected post-enrollment during the New Learner Orientation (NLO), which is a fully AI-driven process in which each learner is assigned a personalized AI coach — their guide throughout the learning journey.
• Program fit and conversion: AI cross-references the lead's stated goal against program curriculum and outcomes. Where the stated goal aligns, AI reinforces fit to drive conversion. Where it does not, AI suggests the closest matching program rather than surfacing a dead end — the objective is enrollment, not disqualification. Inquiries for programs that do not yet exist are captured as product development signals and routed to Product (domain 8).
• Nurture sequence: AI initiates and manages the lead communication sequence from qualification through to application submission and enrollment, personalised to the lead's market, goal, and engagement signals
• Friction detection: AI monitors leads who have stalled at any stage (pre-application, post-admission, post-offer), identifies the friction pattern, and executes targeted re-engagement autonomously
• Financial guidance: AI handles first-line questions about pricing, payment plans, and financial aid options; escalates complex cases
• Conversion timing: AI identifies the optimal moment to intensify outreach using real-time behavioral signals (e.g., a lead currently active on the Nexford website) combined with engagement history and historical conversion timing per profile type. Real-time signals trigger immediate contact — not a queued follow-up.

Human roles

• High-intent escalation: AI surfaces leads with strong conversion signals to a human enrollment advisor with full context — profile, goal, engagement history, recommended talking points
• Stalled conversions: AI handles stalled leads autonomously — re-engagement sequences, friction diagnosis, and alternative approaches are AI-managed. Human involvement in stalled cases is reserved for very high-value exceptions only, surfaced by AI with explicit justification.

Discounting framework Pricing flexibility within Enrollment operates in two phases:

• Phase 1: Finance pre-approves a monthly toolkit of available discounts and scholarships. Enrollment operates within that toolkit — no ad hoc exceptions, no deviation from approved terms.
• Phase 2: AI auto-generates monthly discount and scholarship recommendations for Finance, based on current financial targets, live conversion data, and retention correlation analysis. Finance reviews and approves the updated toolkit informed by this recommendation. This closes the loop that is currently missing: knowing not just which discounts drive conversion, but which ones correlate with learners who persist and graduate.

Data Inputs: Qualified lead profile from Marketing & Growth (source, engagement signals, market, Nexa/voice qualification data); admission decision from Admissions (domain 3) once application submitted Outputs: Learner career goal and skills baseline (first population of the learner goal record — this is Enrollment's most important data output); program fit assessment; enrollment event; payment method and plan; conversion timing and full touchpoint history

Integration points

• Receives qualified leads from Marketing & Growth (domain 1)
• Routes applicants to Admissions (domain 3) when application is submitted via ApplyNXU; receives admission decision back to complete enrollment
• Hands enrolled learners to Academic Start & Onboarding (domain 4) with full profile
• Feeds CAC and conversion data to Financial Operations (domain 11) and Data & Intelligence (domain 9)

Tooling

• HubSpot — enrollment pipeline management, nurture sequences, conversion tracking; primary commercial system of record
• JustCall — human advisor calling and SMS for high-intent and stalled conversions
• Jira / Linear (under evaluation) — enrollment team task and exception tracking
• Confluence — enrollment playbooks, objection handling guides, market-specific processes
• Enrollment agreement / e-signature tooling — AI-led tool audit required (Section 1.13), must integrate with HubSpot

Compliance

• VA learners: enrollment documentation and certification requirements under VA regulations apply; handled as a distinct workflow layer
• MSCHE: enrollment communications must not make misleading claims; outcome statements grounded in verified data
• Financial regulations: payment processing, refund policies, and financial aid handling subject to applicable consumer protection and higher education financial regulations per market

Build phases Current state: High human involvement; significant manual outreach; CAC elevated; limited personalisation of nurture sequences Near term: Build AI nurture infrastructure; instrument conversion funnel with full attribution; separate NAM and RoW funnels completely Target state: AI-first enrollment with human involvement triggered only for high-value conversion moments; stalled leads fully AI-managed; discounting framework Phase 2 operational — discount toolkit driven by retention-correlation analysis; CAC declining as personalisation improves and PLG channels mature

3. Admissions

Purpose Admissions is an academic function with a specific, compliance-driven scope: it evaluates submitted applications against Nexford's admission requirements and makes the admit or deny decision. It is activated when an application is submitted via ApplyNXU — not before. It does not engage with leads, does not capture career goals, and does not assess program fit in a commercial sense. Its job is to determine whether the applicant meets the academic and regulatory eligibility criteria to be admitted.

Admissions is distinct from Enrollment (domain 2). Enrollment owns the relationship with the lead from first contact through to enrollment confirmation, including goal capture, skills baseline, and program fit — Admissions only processes the formal application once submitted.

Metrics owned

• Application→admission rate
• Application processing time (time from submission to decision)
• Admissions compliance completeness (are all required documents and eligibility checks completed per market requirements)

Core AI functions

• Application review: AI reads submitted applications, checks completeness against admission requirements, validates that required documentation is present, and produces an admissions recommendation with supporting rationale
• Credential verification: AI validates submitted academic credentials against expected standards per market; flags anomalies or unrecognised institutions for human review
• Applicant communications: AI handles all applicant-facing communications during the review process — acknowledgement, document requests, decision notification — in market-appropriate tone
• VA eligibility check: for NAM servicemember applicants, AI runs the VA eligibility workflow as a distinct compliance layer
• Application funnel analysis: AI tracks where applicants drop out of the ApplyNXU process — which document types cause abandonment, which steps have the highest drop-off rate, which credential types generate the most friction, and which markets or institution types produce incomplete submissions. These patterns are compiled into structured signals and routed continuously to Product (domain 8) as primary input into the ApplyNXU product roadmap.

Human roles Admissions follows a deliberate three-phase model for human involvement:

Phase 1 (current): Humans approve all admissions decisions. AI prepares the full review, surfaces the recommendation and supporting evidence, and presents it in WorQ — but every decision is confirmed by a human before it is actioned.

Phase 2: Humans approve specific document types only. AI is granted autonomy on lower-complexity verification tasks (e.g., identity documents, standard credential types) while humans retain approval on higher-complexity assessments (e.g., transcripts, credential equivalency judgments). This is document-level, not application-level — different components of the same application can have different approval thresholds.

Phase 3 (target): Autonomous AI decisions across the majority of standard applications, with human involvement reserved for genuine exception cases.

All human decisions in Admissions are made through WorQ and automatically become training data. When an admissions officer approves, rejects, or overrides an AI recommendation, that decision is captured as a labelled signal that refines the AI's confidence model for that decision type. The more consistently humans use WorQ, the faster the system learns and the sooner Phase 2 and Phase 3 become achievable.

Specific escalation types:

• Credential equivalency: applications where the applicant's academic credential requires an equivalency judgment — Nexford sets its own admission standards per accreditor requirements (DEAC, HELC, IACBE and future accreditors); some credentials from certain markets may not be deemed equivalent to a US 3-4 year bachelor's degree, and applicants may be required to top up. This is Nexford's academic standards decision, not the applicant's home country's regulatory requirement.
• Unusual or unverifiable credentials: flagged by AI for human review with full context
• VA eligibility: US servicemember applications run through the VA eligibility workflow as a distinct compliance layer with a human checkpoint

Data Inputs: Submitted application from ApplyNXU (academic credentials, eligibility documentation, market); VA eligibility data where applicable Outputs: Admissions decision (admit/deny); credential verification result; compliance documentation; admission record handed to Enrollment (domain 2) to complete the commercial enrollment step; application funnel data (dropout points by step, document types presented, credential sources, completion rates by market and institution type) — routed to Product (domain 8) and Data & Intelligence (domain 9)

Integration points

• Activated when an application is submitted via ApplyNXU — Admissions does not receive leads; it processes applications that arrive after Enrollment has converted a lead into an applicant
• Returns admission decision to Enrollment (domain 2) to complete the commercial enrollment step
• Feeds admissions data to Data & Intelligence (domain 9)
• Feeds application funnel data to Product (domain 8) — dropout patterns, document types, credential sources, and step-level completion rates are primary inputs into the ApplyNXU product roadmap; every ApplyNXU feature PRD must be grounded in this data

Tooling

• HubSpot — application pipeline tracking, applicant communications, status management
• JustCall — voice and SMS for applicant outreach and follow-up
• Jira / Linear (under evaluation) — admissions process tracking and exception management
• Confluence — admissions standards documentation, market-specific requirements
• Document verification tooling — AI-led tool audit required (Section 1.13), must integrate with HubSpot
• VA eligibility verification tools — AI-led tool audit required (Section 1.13); separate workflow integration required

Compliance

• Nexford is a US-based institution; admission requirements are set by its accreditors — currently DEAC, HELC, and IACBE, with MSCHE being pursued. Admission standards are Nexford's own, informed by accreditor requirements. They are not the regulations of the applicant's home country.
• Credential equivalency standards are Nexford's academic judgment, applied consistently per accreditor expectations — not determined by the applicant's country of origin
• VA eligibility verification is a distinct mandatory workflow for US servicemember applicants
• MSCHE: documented evidence of a fair, consistent admissions process is a standards requirement — AI workflow logs, human decisions recorded in WorQ, and escalation records constitute this evidence trail. Artifact design requirement: every application record must be designed from the start to produce a complete, retrievable accreditor artifact — the AI's recommendation, the supporting evidence reviewed, the human decision, and the outcome, all in a structured format that can be pulled for any applicant at any point. This is a system design constraint, not a reporting layer added after the fact.
• Data collected during the admissions process is subject to applicable data protection regulations per market; consent and retention rules defined at architecture stage

Build phases Phase 1 (current build): AI prepares full application review and recommendation; all decisions confirmed by a human in WorQ. Instrument processing time, admission rate, and compliance completeness as baseline metrics. Fully separate NAM and RoW workflows. All human decisions feed back into AI training via WorQ. Phase 2: Introduce document-level autonomy thresholds — AI approved on lower-complexity verifications (identity, standard credentials), human approval retained on equivalency judgments and complex cases. Thresholds set by champion and founder-approved. Architecture constraint — Phase 2: document-level decisions must not be treated as independent. An identity document that verifies cleanly can still belong to an application where the transcript raises concerns — the combination matters, not the components in isolation. The Phase 2 system must hold document-level approvals in a pending state until the full application picture is assembled, and re-evaluate the aggregate before any decision is finalised. A naive sequential approval model that processes documents as they arrive will miss cross-document signals and is not an acceptable design. Phase 3 (target): Autonomous decisions across the majority of standard applications; human involvement reserved for genuine exception cases; processing time minimal; full compliance documentation generated automatically.

4. Academic Start & Onboarding

Purpose Enrollment does not guarantee a start. Academic Start & Onboarding owns the gap between enrollment confirmation and the learner's first substantive academic engagement — a known drop-off point. The job is not to close an administrative gap. It is to make the learner feel that Nexford knows exactly who they are and where they are trying to go — and that Nexford is here to support them specifically in achieving that career goal.

If a learner arrives without a clearly defined career goal, Nexford does not proceed as if one exists. The system explicitly partners with the learner to define it — because without a goal, every subsequent communication is generic, and generic does not retain learners.

Orientation is not an administrative checklist. It is the first moment Nexford demonstrates that this is a personal relationship, not a transactional one.

The three persistence drivers — design requirements for the first 60 days

Extensive research identifies three factors that predict learner persistence and graduation more than any other:

1. Self-confidence — the learner believes they have a genuine chance of succeeding. The first 30 days must be designed to produce early wins, provide visible scaffolding, and build the belief that success is achievable for this specific person.
2. Community and connection — the learner feels they are part of something, not studying in isolation. The platform must create conditions for peer connection, cohort belonging, and a sense that other people are on this journey with them.
3. Career connectedness — the more viscerally the learner believes this program will help them achieve a tangible career outcome, the more likely they are to persist through difficulty. Every touchpoint in this domain is anchored to their goal — not to the program, not to modules, but to the specific career outcome they named.

These are not aspirational outcomes. They are the measurable design requirements for this domain. If the system is not producing all three in the first 30 days, the design has failed.

Metrics owned

• Academic start rate (% of enrolled learners who begin their first module within a defined window)
• Month 1→2 persistence rate (NAM and RoW) — shared with Learner Success (domain 5); this domain's design directly determines the starting conditions

Core AI functions

• New Learner Orientation (NLO): the AI-driven orientation experience that begins immediately on enrollment confirmation. Each learner is assigned a personalized AI coach at this stage — the coach that will accompany them throughout their learning journey. The NLO is not a one-size-fits-all sequence. It is a structured AI-driven conversation that builds the learner's profile, surfaces their career goal in full, maps the program to that goal explicitly, and establishes the foundations of the coaching relationship.
• Goal definition partnership: for learners who arrive with a vague or undefined career goal, the AI coach does not assume one. It guides the learner through a structured goal-definition process — surfacing their current role, aspirations, and interests — and helps them articulate a specific career goal that the program can be anchored to. A learner with a defined goal is a fundamentally different engagement challenge than one without.
• Goal anchoring: at every touchpoint in the onboarding period, AI connects the learner's immediate action (their first module, their first assignment) to their specific career goal. The framing is always: "this builds [skill], which is directly relevant to [their stated role/goal]." Not program-level messaging — personal-level.
• Self-efficacy activation: AI surfaces early evidence that the learner is capable — acknowledging prior knowledge, highlighting what they already know, designing early interactions to produce visible progress. The goal is to shift the learner's self-belief in the first 30 days.
• Community connection: AI facilitates introductions to cohort peers with relevant profiles, surfaces shared goals or backgrounds as connection prompts, and creates conditions for the learner to feel they are part of a community. The social architecture of early onboarding is a product design requirement, not an optional feature.
• Platform orientation: AI guides learners through the platform, surfaces the most relevant starting point given program and goal, and answers first-contact questions
• Start monitoring: AI tracks time-to-first-module for every enrolled learner and initiates re-engagement sequences before the learner goes cold — not after

Human roles

• Non-starters: the first intervention lever is the product. The NLO, goal-anchoring sequences, and community features are designed to make starting feel personally meaningful and accessible — human outreach is the fallback, not the primary mechanism. When a human does reach out, they follow a specific goal-anchored script: the conversation is about the learner's career goal and how Nexford can help them get there. The current approach — communicating urgency or consequences — is not an acceptable substitute. The human's job is to re-establish the learner's belief that this program is the right path for their specific goal, and that starting now is in their interest.
• Goal definition support: for learners who remain stuck on defining their goal after the AI-guided process, a human career advisor can be triggered — but this should be rare; the AI process is designed to handle the majority of cases.

Data Inputs: Full enrolled learner profile from Enrollment (goal, preliminary skills baseline, market, program, AI coach assignment); Canvas login signals Outputs: Deep career goal record (the definitive goal profile, established during NLO); academic start event and timing; self-efficacy baseline signals; community connection signals; onboarding friction signals; Month 1→2 persistence leading indicators

Integration points

• Receives enrolled learners from Enrollment (domain 2)
• Hands started learners to Learner Success (domain 5) with full onboarding context including AI coach assignment and deep goal record
• Feeds Canvas activity data and goal record to Data & Intelligence (domain 9)
• Routes community connection architecture requirements to Product (domain 8) — social connection is a product design problem, not just an AI communication problem

Tooling

• Canvas — LMS; primary learner platform; first login and module access data feeds start rate tracking
• HubSpot — goal-anchored onboarding communication sequences
• JustCall — human outreach for persistent non-starters, following goal-anchored scripts
• Anthropic API — AI coach; NLO conversation; goal definition partnership; goal anchoring and personalisation throughout
• Confluence — onboarding process documentation, human outreach scripts, orientation design standards
• Community and social connection tooling — AI-led tool audit required (Section 1.13); must be embedded in the learner platform experience, not a separate app or tool

Compliance

• VA learners: academic start must be reported to the VA; start date documentation is a compliance requirement
• MSCHE: documented onboarding process and orientation completion rates are evidence of a structured learner support system

Build phases Current state: Standard welcome communications; limited personalisation; start rate monitoring manual; no goal-definition partnership for undecided learners; no structured community connection features; human non-starter outreach focused on urgency/consequences rather than goal connection Near term: Build the AI-driven NLO with AI coach assignment; instrument academic start rate and Month 1→2 persistence as live metrics; build goal-anchoring communication sequences; instrument community connection features as a product priority; redesign human non-starter outreach scripts Target state: Every learner exits onboarding with a defined career goal, an active AI coach relationship, at least one peer connection, and a clear belief that this program is the vehicle for their specific career outcome; start rate and Month 1→2 persistence improving measurably; human involvement reserved for genuine exceptions

5. Learner Success

Purpose Learner Success owns two interconnected mandates: persistence and career enablement. These are not separate functions — they are the same function. A learner who believes they are on a path to a tangible career outcome persists. A learner who loses the connection between the program and their career goal churns. Career support is not an add-on; it is a persistence mechanism.

The persistence mandate is not to react to learners in crisis — it is to prevent crisis from occurring. The strategic orientation is prevention over remediation: a learner who never becomes at-risk costs nothing to retain; a learner pulled back from the edge is expensive and never certain.

Month 1→2 and Month 2→3 are the most critical persistence windows — the periods where most learner loss occurs and where the returns on proactive intervention are highest. But the system does not go silent after month 3. The nature, intensity, and cadence of engagement is phase-based and calibrated to where the learner is in their journey. A learner in month 8 needs a fundamentally different kind of support than a learner in month 1. The system knows the difference and responds accordingly.

The domain's impact on the northstar metric (active learners) is direct and mechanical: Nexford operates on monthly terms — learners can start on the first of every month, and graduates exit the active learner base every month. Net active learner growth only occurs when the rate of new enrollments consistently exceeds the combined rate of graduates and churned learners. The single largest driver of unintended churn is financial dismissal — learners who fall behind on payments and are dismissed before they have a chance to catch up. This is both the most common cause of churn and one of the most preventable.

This is the most data-intensive domain in the lifecycle. The quality of at-risk detection and intervention depends directly on the richness of the learner profile built through onboarding and ongoing academic activity. The system is only as good as the data feeding it. Benchmark persistence data by program will be used to calibrate high-risk period thresholds per program — these will be specified once baseline data is available.

Metrics owned

• Month 1→2 persistence rate (NAM and RoW) — shared metric with Academic Start & Onboarding (domain 4); onboarding design determines the starting conditions, Learner Success owns the ongoing intervention
• Month 2→3 persistence rate (NAM and RoW)
• Full-journey persistence rate through graduation (NAM and RoW)
• Financial dismissal rate — the primary preventable churn signal; tracked separately from voluntary withdrawal
• Retention rate
• CRC (Cost of Retention per Cohort)
• Career readiness progression — skills-to-role alignment score tracked across the learner's journey; a leading indicator of both persistence and post-graduation goal achievement
• In-program career engagement rate (% of learners actively engaging with career support features)

Core AI functions

• Phase-based engagement: the system maintains an active relationship with every learner from first module to graduation — but the nature of that relationship changes by phase. Early phase (months 1–3, the high-risk window): high-frequency, goal-anchored reinforcement of the three persistence drivers established in onboarding. Mid-phase: cadence reduces but AI continues monitoring signals and reinforcing career connectedness at key moments (module completion, assessment results, milestone events). Late phase: motivation anchored to proximity to graduation and career outcome. The system never defaults to silence.
• Prevention-first at-risk detection: AI monitors a continuous stream of signals — login frequency, assessment attempts, submission timing, support interactions, engagement patterns, payment status — against expected behaviour per learner profile and program phase. The goal is to identify drift before it becomes disengagement, not to identify disengagement after it has occurred.
• Financial dismissal monitoring and data generation: AI monitors payment status via Chargebee for every active learner and initiates proactive outreach when a learner approaches dismissal — framed around their goal and available options, not administrative consequences. Financial dismissal is the #1 cause of unintended churn and currently happens without analysis. What is missing is not the dismissal event itself but the analytical layer: every dismissal is captured with the learner's full commercial profile (acquisition channel, discount applied, enrollment date, program, market) so that correlations can be identified. Hypothetically: learners given a discount above 20% who enrolled in the final week of the month may be 80% more likely to churn within 30 days — that kind of pattern, currently invisible, must become an operational input into the discount toolkit and marketing decisions. The data generation and correlation work lives in Data & Intelligence (domain 9) and Financial Operations (domain 11); this domain generates and feeds the signal.
• Intervention selection: when a learner is flagged at-risk, AI selects the intervention type based on profile, risk signal pattern, journey phase, previous intervention history, and what has worked for similar profiles. Not every at-risk learner gets the same response.
• Intervention execution: AI initiates first contact via the appropriate channel — for RoW learners, WhatsApp is the primary channel; email response rates are insufficient for timely intervention. Channel selection is part of the intervention logic, not an afterthought. Messages are framed around the learner's career goal, not administrative urgency.
• Escalation: where AI-initiated intervention produces no response, or where signal severity requires human judgment, the case is escalated to WorQ with full context.
• SAP monitoring: Satisfactory Academic Progress is a compliance requirement across all accreditors (DEAC, HELC, IACBE, MSCHE). SAP calculation is a complex formula currently codified in Nexford's systems. AI monitors SAP status for every learner continuously and flags concerns proactively — both to trigger appropriate support and to ensure compliance documentation is maintained. SAP data is a subset of the broader at-risk signal set, not a separate process.
• Effectiveness tracking: every intervention is logged — type, channel, timing, outcome — and feeds back into the intervention selection model. The system improves as it accumulates outcome data.
• Career coaching: AI provides personalised career support throughout the program — anchored always to the learner's specific career goal established in NLO. This includes resume development, LinkedIn profile guidance, skills-to-role mapping as the learner progresses through modules, interview preparation, and job search support. The career coach is the same AI coach assigned in onboarding — continuity of relationship is the design.
• Career milestone surfacing: at key academic achievements (module completion, assessment pass), AI explicitly connects the accomplishment to the learner's career goal: "you have now demonstrated [skill], which is directly relevant to [target role]." Every academic milestone is framed as a career milestone. This is not motivational copy — it is the mechanism by which career connectedness is maintained through the program.
• Skills-to-role mapping updates: as the learner's skill profile builds, AI updates the mapping between their demonstrated competencies and their target role, surfacing the gap that remains and what completing the next module achieves. The learner always knows where they stand relative to their goal.

Human roles

• High-severity at-risk: learners with multiple compounding risk signals, unresponsive to AI intervention, or in circumstances requiring empathy and judgment (personal hardship, academic difficulty beyond the standard pattern) are escalated to a human advisor with the full profile, risk signal history, what AI has tried, and a recommended approach
• Systemic flags: where a risk signal pattern traces to a course design issue rather than an individual learner issue, this is flagged to Academic Operations (domain 6)
• Complex career coaching: where a learner needs more than the AI coach can provide — significant career pivots, unusual circumstances, employer introductions — a human career advisor is triggered via WorQ with the learner's full profile and career readiness history
• 1:many learner events: recurring human-hosted events — welcome calls, cohort community sessions, milestone celebrations — where one person creates connection, belonging, and human presence for many learners simultaneously. These are not scaled-down 1:1 interactions; they are a distinct format designed for community-building at scale. AI handles all logistics (invitations, scheduling, reminders, follow-up), so human time is spent entirely in the room, not managing the process. The principle that governs this domain's human design is: reduce 1:1 interactions, which do not scale; preserve and invest in 1:many interactions, which do. A human advisor spending an hour on a welcome call with 30 learners creates exponentially more value than 30 individual calls.

Data Inputs: Full learner profile including AI coach assignment and deep goal record from Academic Start & Onboarding (domain 4); Canvas activity data; assessment data including learner risk scores derived from graded submission quality (pillar scores, attempt velocity, submission timing — computed at grading time and stored in learner_risk_scores per learner per course); payment status from Financial Operations (domain 11); support interaction logs; intervention effectiveness history; program-specific high-risk period benchmarks (to be loaded as available) Outputs: At-risk flags and severity ratings; financial dismissal risk flags; intervention log (type, channel, timing, response); persistence events by phase; CRC per cohort; SAP status per learner; systemic flags to Academic Operations

Integration points

• Receives started learners from Academic Start & Onboarding (domain 4) with AI coach assignment and deep goal record
• Receives payment status signals from Financial Operations (domain 11) for financial dismissal prevention
• Flags systemic academic issues to Academic Operations (domain 6)
• Feeds intervention effectiveness data and persistence signals to Data & Intelligence (domain 9)
• Feeds career readiness progression and in-program career engagement signals to Graduate Outcomes & Alumni (domain 7) — career readiness at graduation is the leading indicator of post-graduation goal achievement

Tooling

• Canvas — engagement monitoring; login frequency, activity, submission timing, and assessment data feed the at-risk model
• HubSpot — intervention communication sequences; interaction log
• WhatsApp Business API — primary intervention channel for RoW learners; email response rates are not sufficient for timely at-risk intervention in these markets
• JustCall — human advisor calls and SMS for high-severity escalations (NAM primary)
• Supabase — learner interaction and support data (pending architecture decision: Nexford currently uses Azure services; the long-term database architecture — Supabase vs. Azure-native vs. other — is an open decision that must be resolved before this domain's data layer is built; this is a critical dependency)
• Chargebee — subscription management; payment status, billing cycles, dismissal events; primary source of payment health data for at-risk monitoring
• Anthropic API — intervention selection, personalisation engine, SAP monitoring
• Power BI — current state only: learner persistence and at-risk data currently housed here; this data must be extracted and integrated into the central AI-native data layer; Power BI is not an approved long-term tool for this domain — migration to the central data architecture is a near-term build requirement
• Jira / Linear (under evaluation) — escalation and case tracking for human advisors
• Confluence — intervention playbooks, escalation protocols by risk type

Compliance

• SAP (Satisfactory Academic Progress): required under all current and anticipated accreditors — DEAC, HELC, IACBE, and MSCHE. The SAP formula is complex and is currently codified in Nexford's systems; the AI monitoring layer must integrate with this existing calculation, not replace it without accreditor approval. All SAP flags, documentation, and outcomes are recorded as part of the compliance audit trail in WorQ.
• MSCHE: documented learner support processes, intervention records, and persistence data are evidence requirements for regional accreditation
• Accreditation artifact design requirement: every learner record must be designed from the start to produce easily accessible, demonstrable artifacts for accreditor review. This is not a reporting layer added later — it is a system design constraint. Every AI-initiated intervention, every at-risk flag, every human decision, every SAP assessment, and every career coaching interaction must generate a stored, retrievable record. When an accreditor asks for evidence of learner support, the system must be able to produce a complete, structured record for any learner at any point in their journey — not reconstruct it from logs. This follows the same principle codified in the assessment platform, where a final PRD and SPEC are saved alongside every assessment as a permanent audit trail. The equivalent here is a learner support record: a structured document per learner that captures the full history of support interactions, at-risk events, interventions, and outcomes in an accreditor-readable format.
• Privacy: learner risk profiles and intervention records are sensitive; access controls and retention rules defined at architecture stage

Build phases Current state: At-risk identification partially manual; intervention selection ad hoc; effectiveness tracking limited; learner persistence data siloed in Power BI; WhatsApp not deployed; financial dismissal monitoring reactive; career support not systematised — no in-program career coaching, no skills-to-role mapping, no career milestone tracking Near term: Build at-risk detection model with initial signal set; instrument full-journey persistence; integrate Chargebee payment signals for financial dismissal monitoring; deploy WhatsApp as the RoW intervention channel; extract learner data from Power BI into the central data layer; build career coaching layer within the AI coach established in NLO; instrument career readiness score Target state: Prevention-first system operating across the full learner journey; phase-calibrated engagement running continuously; career coaching integrated seamlessly with academic progress tracking; every learner exits the program with a clear skills-to-role record; financial dismissal rate materially reduced; CRC declining as both persistence and career connectedness improve

6. Academic Operations

Academic Operations is the internal academic infrastructure domain. It covers five sub-functions: Curriculum Development, Registrar, Faculty, Compliance, and Institutional Effectiveness. Together they ensure that what Nexford offers is academically sound, properly credentialed, operationally documented, consistently compliant, and demonstrably effective — the foundation that makes every learner-facing domain credible.

The Learning Design Application (the internal platform the LXD team operates) and the assessment platform are the furthest advanced. The Registrar, Faculty, Compliance, and Institutional Effectiveness sub-functions are currently less systematised and represent significant near-term build priorities.

Metrics owned

Curriculum Development:

• CLO coverage rate across active courses
• Course completion rates (per course and program)
• Learner NPS — course-level satisfaction
• Course development and update timelines (time from initiation to live)
• Assessment integrity (brute-force flags, anomalous submission patterns)
• Curriculum currency (% of courses with industry context updated within 12 months)
• Course health score per course and assessment — a WAM-derived measure of how well current content maps to live employer demand; published externally by Product (domain 8); owned and maintained by Curriculum Development
• Program Learning Outcome (PLO) achievement rate — CLOs map up to program-level outcomes; PLO achievement measures whether learners who complete the program have demonstrated the competencies the program is designed to produce. Tracked at individual level (per graduate) and aggregate level (per program and cohort). This is both an accreditation requirement and the definitive measure of curriculum effectiveness.
• Shared accountability for learner outcomes — Curriculum Development is a co-owner of graduation rate, PLO achievement rate, and goal achievement rate alongside Graduate Outcomes & Alumni; what learners learn determines what they achieve

Registrar:

• Credit transfer processing time (NAM — a critical enrollment-stage dependency; NAM applicants frequently arrive with prior credits)
• Graduation certification processing time
• Learner record completeness and accuracy rate

Faculty:

• Faculty credentialing compliance rate — 100% of active faculty credentialed per DEAC and MSCHE requirements at all times; this is binary, not a target
• Learner NPS — faculty and course delivery quality as rated by learners
• Teaching quality signals (grading timeliness, learner feedback response rate)

Compliance:

• Accreditation filing deadlines met — missed deadlines are institutional risk events, not operational metrics
• Policy review completeness (all active policies reviewed on the required cycle)
• Compliance labour efficiency: as accreditation requirements and regulatory scope increase over time, the compliance function must scale coverage without proportional headcount growth. The target metric is compliance workload covered by automation — growing regulatory burden managed by the same or smaller team through better systems.

Institutional Effectiveness:

• Institutional reporting completeness and timeliness (all required reports submitted accurately and on time)
• Automation coverage ratio — % of required institutional reports and analyses generated automatically from the central data layer; target: near-100%
• IE headcount cost — traditional universities dedicate entire teams to this function; the target for Nex-OS is zero dedicated IE headcount, achieved through architecture

Core AI functions

Curriculum Development:

• Diagnostic analysis: Nexus analyses uploaded course content against CLOs, generates alignment reports, identifies gaps, and produces a full diagnostic package (P02–P06) per course
• Gap-fill drafting: where CLO gaps are confirmed, Nexus drafts content to address them, drawing from the WAM registry of vetted sources
• Assessment generation: Nexus generates assessment specifications and question pools grounded in CLOs and Bloom's taxonomy targets, at the rigour tier appropriate for the course's position in the learning path
• Grading — AI + Faculty Review (GWorQ): AI grades written submissions against a rubric with pillar-level scoring (Domain · Reasoning · Contribution), with full rationale per band, at the moment of submission. Where an assessment is marked faculty_review_required, the Nexus recommendation routes to a human evaluator via GWorQ (internal.aios.nexford.edu/worq/grade) rather than being written directly to the grade record. This flag can be set on any assessment across the programme — module-level or final — not only capstone phases. The evaluator reviews the submission alongside the Nexus recommendation, confirms or adjusts scores and feedback, and submits. Faculty can audit evaluator quality via the GWorQ audit view with a Nexus agreement rate metric.
• Grading data pipeline (grading-method-agnostic): every confirmed grade — AI or human — feeds the same downstream pipeline regardless of how it was graded. graded_by ('ai' | 'evaluator' | 'faculty') is the only structural difference. The pipeline writes: (1) learner_capability_evidence — one row per WAM capability demonstrated, linking submission to capability, pillar scores, Bloom's level, and overall score; (2) learner_risk_scores — a per-learner per-course risk signal recomputed on every submission, drawing on pillar scores, attempt velocity, and submission timing. Schema live; writes being wired in Phase 2. These records are the raw material for the learner capability profile that feeds faculty coaching, the AI Coach, and career services — and for the accreditation evidence layer that links every assessed submission to a specific programme-level outcome.
• Systemic signal contribution: assessment data (attempt patterns, score distributions, retake rates) is flagged when it indicates a course design issue, not an individual learner issue
• WAM-powered relevance monitoring: the WAM (Workplace Alignment Model) registry is the continuous intelligence feed that keeps curriculum mapped to employer demand. Nexus checks WAM before generating any content. As WAM data updates, AI flags courses and assessments whose health scores have degraded — surfacing them for LXD review before the gap widens. Product (domain 8) builds and maintains the connectors that expose this health score externally.
• PLO mapping and achievement tracking: AI maintains the mapping between CLOs and Program Learning Outcomes for every program, tracks PLO demonstration per learner across their full course history, and generates the aggregate PLO achievement reports required by accreditors. A learner's PLO record is completed at graduation and feeds into Graduate Outcomes & Alumni (domain 7) and the Institutional Effectiveness sub-function.

Registrar:

• Degree audit monitoring: AI maintains a live degree audit for every enrolled learner — tracking completed courses, credits accumulated, and remaining requirements; flags learners at risk of not graduating on their expected timeline
• Graduation eligibility: AI identifies learners approaching completion, compiles the graduation eligibility evidence package, and routes for human sign-off
• Credit transfer processing: AI evaluates NAM credit transfer applications against defined equivalency criteria and produces a recommendation; flags edge cases for human decision
• Record integrity: AI monitors for discrepancies or gaps in learner records and surfaces them for correction

Faculty:

• Credentialing monitoring: AI tracks faculty credentialing status against DEAC and MSCHE requirements, flags renewals and gaps well in advance, and ensures no active course is taught by an uncredentialed instructor
• Teaching quality signals: AI monitors grading timeliness, learner feedback patterns, and course engagement data; surfaces alerts when signals fall outside expected ranges
• Learner capability profile (Phase 2): once learner_capability_evidence is fully populated, faculty have access to a structured per-learner view of which WAM capabilities have been demonstrated, at what level, across the programme. This profile surfaces areas of strength and persistent gaps — grounding coaching conversations in evidence rather than impression, and providing the structured data the AI Coach needs for personalised learning recommendations

Compliance:

• Accreditation calendar: AI manages the full accreditation filing calendar across DEAC, HELC, IACBE, and MSCHE — surfaces upcoming deadlines, tracks submission status, and flags risk well in advance of due dates
• Regulatory monitoring: AI monitors for regulatory changes across all markets in which Nexford operates and surfaces potential compliance impacts for human review
• Policy gap detection: AI cross-references current policies against accreditor standards and flags gaps or outdated policies

Institutional Effectiveness:

• Automated institutional reporting: AI pulls from the central data layer and generates all required accreditor reports, annual institutional effectiveness reports, and program reviews automatically — no manual data compilation. Every metric required by DEAC, HELC, IACBE, and MSCHE is drawn from the live data layer and formatted for submission. This is achievable at near-100% automation only if the underlying data architecture is built correctly; the architecture is the prerequisite, not the reporting tool.
• Outcome assessment aggregation: AI aggregates learning outcome data across all courses and programs and generates the institutional assessment of student learning required by accreditors
• Institutional trend analysis: AI surfaces trends in enrollment, persistence, graduation, and outcomes data and generates insights for strategic planning and accreditor self-studies
• Self-study preparation: AI compiles and drafts accreditor self-study documentation, drawing from evidence artifacts generated across all domains; humans review and finalise

Human roles

Curriculum Development:

• Pedagogical and learning science framework (Phase 1): Learning design professionals determine the pedagogical approaches and learning science theories that govern how AI builds content and assessments. This includes decisions on instructional sequencing, cognitive load management, Bloom's taxonomy targeting, formative vs summative design philosophy, and the evidence-based models underpinning assessment design (e.g. constructive alignment, spaced retrieval, scenario-based learning). AI does not infer these frameworks — they are defined by humans and encoded as constraints within which AI operates. In Phase 1, this framework is established explicitly before AI build begins; in later phases, AI may propose updates to the framework, but human LXD sign-off remains required before any change is adopted.
• LXD review: learning design professionals review and approve all AI-generated content and assessment specifications before they go live. AI produces; humans approve.
• PRD sign-off: every new or redesigned assessment requires a Product Requirements Document approved by LXD before build begins
• Escalation response: when Learner Success flags a systemic academic issue, the Academic Operations team investigates course design as the likely cause

Registrar:

• Graduation certification: final sign-off is a human decision — AI compiles the eligibility evidence and recommendation
• Credit transfer decisions: edge cases where equivalency judgment is required are human decisions
• Record corrections: data integrity issues are investigated and resolved by humans

Faculty:

• Hiring and performance decisions: all faculty engagement, development, and dismissal decisions are human
• Credentialing approvals: final credentialing sign-off is human
• Course change approval: faculty are required by accreditors to be involved in approving changes to courses they teach. This involvement is designed to be the minimum required to satisfy accreditation standards — not an open-ended review process. Course change approval tasks are routed via WorQ to the relevant faculty member (user role: faculty), who resolves the task with a decision. The design constraint: faculty involvement is a compliance requirement; it should not be a bottleneck.

Compliance:

• Accreditor relationships: all direct communications with accrediting bodies are human-managed
• Regulatory filings: submissions to regulatory bodies are human-approved before submission
• Policy decisions: new and updated policies are human decisions informed by AI-surfaced gaps

Institutional Effectiveness:

• Report sign-off: AI-generated institutional reports are reviewed and approved by a human before submission to any accreditor or regulator — AI drafts, human certifies
• Strategic interpretation: institutional trend data is reviewed by leadership to inform planning decisions; the system surfaces; humans decide what to act on

Data Inputs: CLOs and program structure (program_courses database); WAM registry; assessment submission data; learner enrollment and grade data (Admin/NXU OS); credit transfer applications (from Enrollment, NAM); at-risk signals from Learner Success where systemic patterns are detected; graduate outcomes data (CLO-to-skill-to-outcome correlation); faculty credentialing records; regulatory and accreditor requirement updates Outputs: Diagnostic reports per course; assessment specifications and question pools; grading results (pillar scores, CLO demonstration flags, feedback); graduation records; credit transfer decisions; faculty credentialing status; compliance calendar status and accreditation evidence packages; curriculum health data; institutional effectiveness reports (automated); outcome assessment aggregates; accreditor self-study documentation

Integration points

• Feeds assessment quality data to Learner Success (domain 5)
• Receives systemic at-risk flags from Learner Success (domain 5)
• Feeds CLO-to-outcome correlation data to Graduate Outcomes & Alumni (domain 7)
• Feeds graduation records to Graduate Outcomes & Alumni (domain 7) and Financial Operations (domain 11)
• Draws labor market intelligence from Data & Intelligence (domain 9) for curriculum relevance
• Receives credit transfer applications from Enrollment (domain 2) for NAM applicants; returns decision
• Draws learner record data from Admin/NXU OS

Tooling

Curriculum Development (live or in active development):

• Learning Design Application — internal platform; primary operational interface for the LXD team
• Nexus / Anthropic API — AI learning design assistant; diagnostic pipeline, gap-fill drafting, assessment generation, grading
• Canvas — LMS; course content delivery and assessment integration
• Vercel / Next.js — learner-facing assessment platform
• GitHub + GitHub Actions — diagnostic pipeline automation
• Supabase — learner submissions, grades, comments
• Neon / Vercel Postgres — course, program, and CLO data

Registrar and Faculty:

• Admin / NXU OS — primary SIS; all enrollment records, transcripts, grades, credit transfer records, graduation records, and faculty credentialing data
• DegreeSight — third-party credit transfer evaluation tool; used to assess NAM credit transfer applications against equivalency standards
• Canvas — grade and teaching activity data
• HR/people management tooling — AI-led tool audit required (Section 1.13) for faculty credentialing and performance tracking

All sub-functions:

• Confluence — academic policy documentation, compliance documentation, LXD design standards, PRD and SPEC templates
• Jira / Linear (under evaluation) — academic operations task and initiative tracking
• WorQ — compliance audit trail; all human decisions in this domain are captured here

Compliance

Curriculum Development:

• DEAC: assessment integrity, CLO coverage, and grading consistency are core accreditation requirements
• MSCHE: competency-based assessment evidence, regular curriculum review, and learning outcome assessment processes are MSCHE standards requirements — built in from the start
• VA: assessment integrity and academic progress standards apply to enrolled servicemembers

Registrar:

• FERPA: US learner records must be handled in compliance with FERPA; access controls and disclosure rules apply
• DEAC/MSCHE: records retention and transcript accuracy are accreditation requirements
• Credit transfer: NAM credit transfer evaluations must comply with applicable state authorization and transfer credit policies

Faculty:

• DEAC: faculty qualification requirements define minimum credentials per course type; zero tolerance for gaps — this is a non-negotiable accreditation compliance item
• MSCHE: faculty qualification standards are a core candidacy requirement; systems are built to these standards from the start

Compliance sub-function: The compliance sub-function owns the operational relationships with DEAC, HELC, IACBE, and MSCHE; manages all filing calendars and submission processes; and is responsible for ensuring every domain's compliance design remains current as accreditor requirements and regulations evolve.

Artifact design requirement — applies across all Academic Operations sub-functions: every process that accreditors may request evidence for must be designed from the start to produce retrievable, structured artifacts. Graduation records, credit transfer decisions, faculty credentialing status, curriculum review evidence, and accreditation filing histories must all be stored in a format that can be pulled on demand — not reconstructed. This is the same principle applied in the assessment platform (PRD and SPEC saved permanently alongside every assessment) and in Learner Success (learner support record per learner). Compliance evidence is not a reporting problem — it is a system design requirement.

Build phases

Curriculum Development:

• Live now: Learning Design Application, Nexus diagnostic pipeline (Phase A + Phase B), assessment platform (BAN2100, ECO2150, FIN6160, ACC6050, OPM6090), WAM registry, grading engine with rubric scoring
• In progress: Remaining Wave 1 course assessments; PRD/SPEC workflow formalisation; retake policy implementation
• Target state: Full diagnostic coverage across all active courses; assessment platform live for all courses in all programs; Nexus operating autonomously on content currency updates with LXD reviewing, not initiating

Registrar:

• Current state: Most registrar functions manual or semi-manual; degree audits not automated; credit transfer evaluation manual; graduation certification not systematised
• Near term: Build degree audit monitoring in Admin/NXU OS; build NAM credit transfer workflow with AI evaluation and human decision on edge cases; automate graduation eligibility detection
• Target state: Fully automated degree auditing; graduation certification routed to human sign-off by AI; credit transfer processing time for NAM materially reduced

Faculty:

• Current state: Faculty credentialing tracked manually; teaching quality monitoring limited
• Near term: Build credentialing compliance monitoring with automated alerts well in advance of renewal deadlines; instrument teaching quality signals via Canvas
• Target state: Zero credentialing gaps at all times; teaching quality signals feeding faculty development decisions continuously

Compliance:

• Current state: Accreditation calendar managed manually; regulatory monitoring ad hoc
• Near term: Build compliance calendar in WorQ with automated deadline tracking and advance flagging; establish regulatory monitoring workflow
• Target state: Full accreditation calendar managed by AI with human review and approval; no missed deadlines; regulatory changes surfaced proactively before they become compliance issues; compliance workload covered by automation growing without headcount growth

Institutional Effectiveness:

• Current state: IE reporting done manually or not done systematically; no dedicated IE function; reports compiled ad hoc for accreditor visits; data pulled from multiple siloed systems
• Near term: Map all required institutional reports across DEAC, HELC, IACBE, and MSCHE; build automated data pulls from the central data layer for each; instrument automation coverage ratio
• Target state: Near-100% of required institutional reports generated automatically from the central data layer; human role limited to review and sign-off; zero dedicated IE headcount required; accreditor self-study documentation generated on demand

7. Graduate Outcomes & Alumni

Purpose Graduate Outcomes & Alumni closes the loop. It tracks whether learners who completed the program achieved the goal they enrolled with — and feeds that signal back into every upstream domain. This is not a post-program afterthought. It is the domain that validates the entire proposition.

The measurement frame is goal achievement, not graduation. Graduation is a milestone, but a graduate who did not achieve their career goal is not a success outcome. This domain tracks against the individual's stated goal captured at admissions.

Metrics owned

• Graduation rate
• Goal achievement rate (% of graduates who achieved or made measurable progress toward their stated goal within a defined post-graduation window)
• Salary change at 6 and 12 months post-graduation
• Promotion rate
• Alumni NPS
• Referral contribution (% of alumni who refer at least one future learner)

Core AI functions

• Post-graduation surveys and check-ins: automated surveys currently go out via Survey at defined post-graduation intervals. AI optimises survey timing, question sets, and follow-up sequences based on response rates and outcome signal quality. Survey data is processed immediately on receipt — not stored for manual review.
• Outcome reporting and shareable assets: AI generates two types of output from graduate survey data: (1) structured reports for Institutional Effectiveness (Academic Operations domain 6) — aggregated outcome data in the format required by accreditors; (2) shareable marketing assets — compelling, data-backed summaries of graduate outcomes (salary uplift, promotion rates, goal achievement) that Marketing (domain 1) can publish as credibility proof. These are generated automatically and refreshed as new data arrives.
• Alumni engagement: AI manages ongoing alumni community communications, surfaces relevant opportunities, and maintains relationship continuity
• Outcome attribution: AI connects graduate outcomes back to specific CLOs, PLOs, program design decisions, and intervention history — providing the feedback signal that Academic Operations needs to continuously improve curriculum and assessment design
• Referral activation: AI identifies alumni with high satisfaction signals and initiates referral prompts at the optimal moment

Human roles

• Outcome verification: where goal achievement claims are significant and will be used in marketing, a human verifies the data
• Strategic alumni relationships: employer partnerships, advisory roles, and ambassador programs are managed by humans

Data Inputs: Full graduate profile (original goal, program path, CLOs demonstrated, intervention history); labor market data (benchmark outcomes) Outputs: Goal achievement data; salary and promotion outcomes; Alumni NPS; referral events; CLO-to-outcome correlation fed back to Academic Operations; outcome proof points fed to Marketing & Growth

Integration points

• Feeds outcome data back to Marketing & Growth (domain 1) — graduate outcomes are the most credible acquisition proof point
• Feeds CLO and PLO-to-outcome correlation to Academic Operations (domain 6) — including aggregate PLO achievement data for accreditation and IE reporting
• Feeds goal achievement data and referral events to Data & Intelligence (domain 9)
• Feeds structured outcome reports to Academic Operations Institutional Effectiveness (domain 6) for accreditor evidence packages
• Feeds shareable outcome assets to Marketing & Growth (domain 1)

Tooling

• HubSpot — alumni communications, post-graduation check-in sequences, outcome data collection
• Survey — current tool for automated post-graduation outcome surveys; must integrate with the central data layer so survey responses feed directly into outcome reporting and IE
• Anthropic API — check-in conversation management, referral activation, outcome attribution analysis, shareable asset generation
• Jira / Linear (under evaluation) — alumni programme and initiative tracking
• Confluence — alumni engagement playbooks and outcome documentation standards
• Alumni community platform — to be evaluated via AI analysis of available options; must integrate with HubSpot and Data & Intelligence

Compliance

• Outcome claims used in marketing must be sourced from verified, statistically sound graduate data — not cherry-picked
• Alumni contact and data retention must comply with applicable data protection regulations per market

Build phases Current state: Automated post-graduation surveys running via Survey; outcome data not fully connected to individual learner goals; shareable reports for marketing not systematically produced; survey data not feeding Institutional Effectiveness Near term: Optimise survey sequences (timing, question sets, follow-up); integrate Survey data into central data layer; build automated shareable outcome asset generation for Marketing; establish structured outcome report feed to IE Target state: Continuous alumni engagement maintained by AI; PLO achievement tracked per graduate and reported in aggregate for accreditors; goal achievement rate tracked as a primary institutional metric; shareable outcome assets generated automatically and refreshed continuously; outcome data feeding every upstream domain in real time

8. Product

Product is the design intelligence layer for everything Nexford builds that a learner or prospective learner touches — platform, tools, communications, community infrastructure, and the mechanics that turn learner experience into acquisition. It ensures Nexford builds what learners actually need, not what is operationally convenient.

Product owns two distinct mandates:

1. Learner experience across all platforms. Courses are one part of the learning experience — the non-curricular experience (platform navigation, community, tools, progression visibility, career support features) is equally important and currently underdeveloped. Product owns the full experience across every platform a learner touches: myNXU, the LMS (Canvas/Learn), the assessment platform, and any community or social learning infrastructure. Product partners with the Learning Design team to provide the tools and features that complement course content — not just a better LMS, but a genuinely richer environment where social learning, peer connection, and community are possible. Canvas is notably weak at social learning; Learn's capability in this area is unproven. It is likely that purpose-built or third-party community infrastructure will be required.

2. Product-led growth. Learner referral rate is the primary PLG metric. Product also owns the public preview experience — giving prospective learners a genuine taste of the Nexford learning experience before they enroll. A compelling preview converts without sales. This is not a marketing asset; it is a product feature that sits at the top of the acquisition funnel and must be designed to be intrinsically compelling.

Design thinking is not a process Product applies in isolation — it is a constraint Product embeds across every domain's build decisions. Product is involved early in every domain building anything learner-facing, and this brief is the governance framework that makes deviation from that principle structurally difficult.

Metrics owned

• Learner referral rate — primary PLG metric, must consistently increase; a flat or declining rate is a product signal, not a marketing signal
• ApplyNXU application completion rate — applications started vs. applications submitted; a material growth lever requiring no additional acquisition spend (Q1 baseline: 14,667 started, 1,051 completed)
• Preview-to-application conversion rate — % of prospective learners who engage with the preview experience and go on to start an application
• Learner NPS (platform and course experience — broken out by platform where possible)
• Feature adoption rate (proxy for whether new features solve a real problem)
• Community engagement rate — % of active learners participating in social or peer-learning features
• Course health score (average across active courses and assessments) — a published metric; its improvement over time is both an operational goal and a PLG signal
• Learning wrap share rate — % of learners who share their periodic learning wrap asset externally

Core AI functions

• Cross-journey weakness analysis: AI proactively analyses the full learner and applicant journey for points of friction, dropout, disengagement, and underperformance — across every platform Nexford operates (ApplyNXU, myNXU, Canvas/LMS, the assessment platform, and community tools). This is not reactive reporting; AI surfaces patterns before they become metric movements, and translates them into prioritised product requirements. No platform is excluded from analysis.
• Learner feedback synthesis: AI analyses all structured and unstructured feedback signals — NPS surveys, course ratings, support interactions, in-app signals, community activity patterns — and identifies themes that should inform the product roadmap. Survey responses and qualitative feedback are not read ad hoc; they are continuously processed and surfaced as product intelligence.
• ApplyNXU funnel optimisation: AI analyses application dropout data surfaced by Admissions (domain 3) — by step, document type, credential source, and market — and translates patterns into prioritised product requirements. Every ApplyNXU feature PRD must begin with this data.
• Behavioural analytics: AI processes heatmap, session recording, and interaction data (via Hotjar or equivalent) to identify UX friction that survey data alone would not reveal — where learners hesitate, abandon, or loop back on any platform.
• Design validation: AI analyses feature usage and learning outcome data to assess whether new features are achieving their intended effect; surfaces underperforming features for review
• Referral mechanics: AI identifies learners with strong positive signals and initiates referral prompts at the optimal moment in their journey
• WAM connectors and course health scoring: Product builds and maintains the connectors between the WAM (Workplace Alignment Model) and course and assessment content — enabling AI to continuously calculate a health score for every course and every assessment by comparing current content against WAM labor market data. The score measures how well Nexford's curriculum maps to what employers actually require from workers in the relevant roles, and updates automatically as the labor market data in WAM updates. This applies to course content and assessments equally — both carry a health score.
• Public course health score: the health score is published externally — showing prospective learners, employers, and the world in real time how relevant Nexford's curriculum is, alongside the labor data sources used to calculate it. No other institution publishes this at a course and assessment level. This is a PLG play grounded in credibility and transparency: the score is evidence, not marketing copy. AI maintains the publication layer and keeps it current without manual intervention.
• PLG product ideation: AI continuously analyses learner behaviour, engagement patterns, social sharing signals, and competitive landscape to generate PLG product ideas for the CPO and team to evaluate. Product is responsible for originating mechanics that turn learner progress into organic acquisition — for example, a periodic learning wrap (analogous to Spotify Wrapped) where each learner receives a social-shareable asset summarising what they have learned, which skills they have built, and how those skills map to their career goal — shareable on LinkedIn and other platforms. AI generates the concepts and the personalised content; Product designs the format and the sharing mechanic.
• Product and engineering operations: AI owns the operational layer of product and engineering — sprint planning, release scheduling, bug backlog management, productivity monitoring, and progress tracking against milestones. This mirrors the model in Marketing: humans set direction, AI ensures execution happens and surfaces deviations before they compound. The CPO manages the function; AI manages the process. Sprint hygiene, velocity tracking, and release coordination are not manual CPO tasks.
• Bug fix and feature request triage: AI evaluates all incoming bug reports and feature requests — from learners, internal team members, or AI-generated signals — produces a severity, impact, and priority assessment, and surfaces a ranked recommendation to Product. Product humans decide what gets built and when; AI ensures nothing falls through the cracks and provides the analytical foundation for those decisions.

Human roles

• All design decisions are human-led, informed by AI-surfaced signals. Product does not design by AI — it designs for humans, with AI providing the evidence base.
• Chief Product Officer approves all significant product decisions — new features, platform changes, major experience redesigns, community infrastructure choices, and the product roadmap. The CPO is the primary decision authority for this domain.
• Founder sign-off is required for decisions that are large in scope, set a strategic direction, or involve commitments with significant lock-in (e.g., selecting a community platform, major LMS decisions, building vs. buying social learning infrastructure). This brief is the governance framework — decisions that conform to it can move faster; decisions that deviate require explicit founder review.
• Product partners with the Learning Design team on all tools and features that complement course content — this is a joint function, not sequential handoffs
• Product is involved early in every domain's build that has a learner-facing component — proactive involvement, not reactive review

Data Inputs: Learner NPS and satisfaction signals from all domains; feature usage and behavioural data across all platforms (Hotjar + product analytics); referral attribution; learner goal and outcome data; support interaction patterns; application funnel data from Admissions (domain 3); community engagement data; preview experience conversion data; WAM labor market data (for course health scoring); bug reports and feature requests from all sources Outputs: Product roadmap and prioritisation rationale; design decisions with supporting evidence; referral rate tracking; feature outcome assessments; cross-domain experience requirements; community infrastructure specifications

Integration points

• Cross-cutting: Product is an input into every domain building anything learner-facing
• Receives application funnel signals from Admissions (domain 3); ApplyNXU roadmap governed by this data
• Partners with Academic Operations (domain 6) on tools and features that complement course content
• Feeds referral rate data to Marketing & Growth (domain 1) and Data & Intelligence (domain 9)
• Feeds preview experience conversion data to Marketing & Growth (domain 1)

Tooling

• Figma — design and prototyping for platform features and learner experience
• Hotjar (or equivalent) — behavioural analytics; heatmaps, session recordings, and interaction data across learner-facing platforms; critical for identifying UX friction that quantitative data misses
• Jira / Linear (under evaluation) — product roadmap, sprint planning, feature tracking
• Confluence — product documentation, design decisions, research findings
• Asana (under evaluation for replacement by Linear) — currently used for cross-team project coordination
• Product analytics tooling (PostHog, Mixpanel, or equivalent) — AI-led tool audit required (Section 1.13); must integrate with the central data layer, not create a parallel analytics silo
• Community and social learning platform — AI-led tool audit required (Section 1.13); Canvas is insufficient for social learning; Learn's capability in this area is unproven; purpose-built or third-party community infrastructure is likely required; must integrate with the learner platform and the central data layer
• User research tooling — AI-led tool audit required (Section 1.13)

Compliance

• Accessibility: learner-facing features must meet accessibility standards appropriate for a globally diverse learner population
• Privacy: features that collect new data types (behavioural analytics, community interaction data) require a privacy assessment before build; Hotjar-type tools involve session data and must comply with applicable data protection regulations per market

Build phases Current state: Product decisions made domain by domain without a unified design function; referral rate not instrumented; no systematic feedback loop across platforms; ApplyNXU completion rate tracked (Q1: 14,667 started, 1,051 completed) — significant optimization headroom; social learning features absent; no public preview experience; Hotjar or equivalent not deployed; CPO-governed roadmap process exists but basic Near term: Align Product function under unified CPO mandate with clear domain accountability per this brief; instrument learner NPS and referral rate as live metrics; deploy Hotjar across learner-facing platforms; instrument ApplyNXU funnel with step-level dropout tracking; build WAM connectors and launch course health score (internal first, then public); begin community platform evaluation; design and launch preview experience as a PLG lever; launch first learning wrap cycle Target state: Full product-led design process embedded across all learner-facing domains; ApplyNXU completion rate materially improved; course health score published publicly and updated continuously; learning wrap driving measurable social sharing and referral lift; referral rate trending consistently upward; community features driving genuine peer connection and social learning; preview experience converting a measurable share of prospective learners without sales involvement; PLG channels accounting for a growing share of acquisition

9. Data & Intelligence

Purpose Data & Intelligence is the central nervous system. Its full architecture is defined in Section 2. This brief describes its operational scope as a domain.

Data & Intelligence does not produce the data — every other domain produces data and is responsible for its quality. This domain aggregates it, maintains the shared schema, runs the personalization engine, and provides both human-facing analytics and AI-facing decision feeds. It is the domain that makes every other domain more effective than it would be in isolation.

Metrics owned

• Data quality per domain (completeness, freshness, accuracy — each domain owns its upstream data; Data & Intelligence monitors and flags quality issues)
• Personalization engine performance (are AI decisions improving over time as profiles enrich?)
• Analytics uptime and freshness
• Internal adoption rate — % of team members actively querying and using the analytics layer; a data platform that isn't used is not an asset. The system must be designed for ease of use: any team member should be able to query in natural language without technical assistance. If adoption is low, the interface has failed, not the users.

Core AI functions

• Real-time profile enrichment: every interaction across every domain updates the learner and lead profile immediately
• AI decision feeds: structured, low-latency data feeds consumed by AI agents across all domains
• Anomaly detection: AI monitors the data layer for quality issues, anomalous patterns, and metric movements outside expected bounds — surfaces alerts to humans without requiring them to look
• Acquisition-retention stitching: AI correlates acquisition source, campaign type, discount or scholarship applied, enrollment timing, and other commercial inputs against downstream outcomes — financial dismissal, persistence, and graduation. Financial dismissal is the primary outcome variable: it is the #1 cause of unintended churn, currently happens without any pattern analysis, and is where the highest-value correlations are likely to be found. The outputs are specific, actionable patterns (e.g., discount above a threshold combined with late-month enrollment correlating with materially higher financial dismissal rates) rather than directional trends. These are consumed by Marketing (domain 1) for campaign and targeting decisions, and Financial Operations (domain 11) for monthly discount toolkit design. This intelligence layer does not currently exist and is a near-term build priority.

Human roles

• Architecture decisions: schema changes, new data types, and integration decisions require human sign-off — this is shared infrastructure
• Alert response: humans are notified when metrics move outside expected bounds; the system surfaces the relevant data and a recommended investigation path

Data This domain is the data layer itself. Its inputs are the outputs of all other domains. Its outputs are the intelligence every domain draws from.

Integration points Integrated with all 11 domains by definition.

Tooling

• Neon / Vercel Postgres — primary operational database; course, program, diagnostic, and metric data
• Supabase — learner submissions, relational data, RLS-governed access
• Admin / NXU OS — internal SIS; all learner records, enrollment status, academic history, and Chargebee account links; a primary data source that must be integrated into the central data layer; currently a somewhat siloed system
• Chargebee — subscription and billing data; financial dismissal events; payment status per learner; required for CAC per active learner and CPG calculations
• Anthropic API — AI decision engine and personalization layer across all domains
• Business intelligence / analytics layer — AI-led tool audit required (Section 1.13); must serve both human-facing (clarity, narrative) and AI-facing (structure, freshness, low-latency) consumers as defined in Section 2; replaces Power BI as the analytical layer over time
• Data pipeline and ETL tooling — AI-led tool audit required (Section 1.13); must integrate Admin/NXU OS, Chargebee, Canvas, HubSpot, and all domain outputs into the central schema
• WorQ — decision log and audit trail; all AI decisions and human escalations flow here

Compliance

• Privacy by design: data collection, retention, and access rights defined at architecture stage per Section 2 governance principles
• VA data isolation: VA learner data handled under separate access and retention rules, not commingled with global learner data
• Data protection scope: Nexford operates under two regulatory frameworks — US regulations (including FERPA for learner records) and GDPR (for learners in EU/EEA jurisdictions). These are the two frameworks the data architecture is designed and maintained against. No additional market-specific data protection layers are applied beyond these.

Build phases Phase 1: Instrument the full metric chain; build the shared learner profile schema including goal and skills baseline; establish NAM/RoW split across all metrics; establish both operational and learner goal baselines (these are distinct — see Section 2) Target state: Full personalization engine operating in real time; AI-facing feeds consumed by agents across all domains; human-facing analytics surfacing alerts proactively; labor market intelligence integrated

10. Technology & Platform

Purpose Technology & Platform is the infrastructure domain. It owns the technical stack every other domain runs on, manages integrations between systems, and ensures internal tooling supports the operating model. It does not design the learner experience — that is Product. It provides the reliable infrastructure that makes every other domain's workflow possible.

Current stack

• HubSpot — CRM and marketing automation; primary system of record for leads and the enrollment pipeline
• JustCall — calling and SMS infrastructure for human outreach
• Canvas — LMS; primary learner-facing academic platform (future LMS: Learn, in evaluation)
• myNXU — learner portal; the primary interface for enrolled learners to access their program, account, and communications; receives data feeds from Chargebee and Admin/NXU OS
• Admin / NXU OS — Nexford's internal SIS (Student Information System); stores all learner records including enrollment status, academic history, and Chargebee account links; the operational source of truth for learner data across domains
• Chargebee — subscription management; billing cycles, payment status, dismissal events; feeds myNXU and Admin/NXU OS
• PayNXU — learner-facing payment platform; the point at which learners transact via multiple payment options; integrates with Chargebee
• Vercel / Next.js — learner assessment platform (built within this project)
• Supabase — learner submissions, grades, and comments (pending architecture decision — see note below)
• Neon (Vercel Postgres) — course, program, and diagnostic data
• Anthropic API — Nexus (AI learning design assistant), grading engine, all domain-level AI workflows
• Internal tooling — Learning Design Application, diagnostic pipeline (GitHub Actions)

Team The engineering team is 6 engineers and 1 QA specialist. The Product team works alongside this group. All software development is AI-led — engineers work with AI coding tools as a core part of every build workflow, not as optional assistance. QA is likewise AI-led: testing, coverage analysis, and regression checks are driven by specialized AI QA tooling, with the QA specialist focused on judgment calls the AI cannot make. This team, together with the Product function, operates on Linear as the single tool for sprint management, issue tracking, and product roadmap.

Metrics owned

• Platform uptime and reliability per system
• Integration health (data flows between systems operating correctly)
• API latency (learner-facing and internal)
• Engineering velocity (cycle time, deployment frequency)
• QA coverage and defect escape rate

Core AI functions

• Integration monitoring: AI monitors data flows between systems and flags failures before they impact operations
• Incident detection: anomalous patterns in platform usage or performance are flagged automatically
• AI-assisted development: all code produced with AI coding tools embedded in the engineering workflow
• AI-led QA: automated test generation, coverage analysis, and regression detection via specialized AI QA tooling

Human roles

• Architecture decisions: technology choices with significant lock-in implications (new systems, LMS migration path) require founder sign-off
• Incident response: system failures or data flow breakdowns are escalated to a human with full diagnostics
• QA judgment: AI QA tooling handles coverage and regression; the QA specialist focuses on edge cases, accreditation-sensitive flows, and scenarios requiring human assessment

Tooling

• Vercel — deployment, hosting, and serverless functions
• GitHub + GitHub Actions — version control, CI/CD, automation
• Linear — sprint management, issue tracking, and product roadmap for the engineering and product team (replacing Jira/Asana)
• HubSpot — CRM layer; Marketing, Admissions, Enrollment, and Learner Success integration point
• JustCall — communications layer; integrated with HubSpot
• Canvas — LMS; integrated with assessment platform via Canvas AGS (grade passback)
• Anthropic API — AI capability layer consumed across all domains
• Supabase — database; learner-facing application data
• Neon / Vercel Postgres — database; operational and program data
• Confluence — technical documentation, architecture decisions, integration specs

Compliance

• All systems handling learner data must meet applicable security standards; third-party vendors assessed at the point of integration
• FERPA: US learner records handled in compliance with FERPA requirements

Build phases Open architecture decision — database layer: Nexford currently uses Azure services as the primary cloud infrastructure, and Supabase as the current learner-data database. The long-term database architecture — whether to consolidate onto Azure-native services, continue with Supabase, or adopt another platform — is an unresolved decision with significant lock-in implications. This must be resolved by the Technology & Platform champion with founder sign-off before any new domain data layers are built. Until resolved, Supabase references throughout the brief are marked as pending this decision.

Current state: Stack is functional; some integrations are incomplete or involve manual steps; internal tooling built but not fully integrated with CRM and LMS; database architecture decision unresolved Near term: Resolve database architecture decision (Azure vs Supabase vs alternative); tighten HubSpot↔Canvas integration for seamless enrollment→start data flow; instrument full API health monitoring; evaluate Learn as future LMS Target state: Fully integrated stack with no manual data transfer between systems; all domain workflows running on reliable, monitored infrastructure; database layer consolidated on the chosen platform

11. Financial Operations

Financial Operations measures the economics of everything. It does not make product or academic decisions — it provides the financial intelligence that informs them. Its job is to ensure that CAC, LTV, CRC, and payback period are tracked, understood, and trending in the right direction across every cohort, market, channel, and program.

A second and equally important role is financial translation: when any domain proposes a policy change, product feature, or operational decision, Financial Operations provides the financial impact assessment that is otherwise invisible. If a policy change is likely to result in a higher proportion of learners finishing slower — or faster — what does that mean for monthly revenue, cohort LTV, and payback period? If a new discount structure is proposed, what is the modelled retention impact and its revenue consequence? These connections are currently not drawn systematically. In Nex-OS, Financial Operations closes that gap — ensuring that every significant decision, regardless of which domain originates it, is assessed against its financial consequence before it is made.

Financial Operations also identifies financial goals that are at risk before they are missed, not after — surfacing trend signals early enough for corrective action to be meaningful.

Financial Operations also handles billing, payment plans, and financial aid — the operational finance layer that directly affects a learner's ability to stay enrolled.

Standard financial reports (revenue, cost, margin, payback, cohort economics) are produced automatically on defined cycles. Report generation is not a manual task — it is a system output.

Metrics owned

• LTV:CAC ratio (NAM and RoW)
• CAC payback period per cohort and channel
• CAC per active learner — acquisition cost divided by learners who remain active past the high-risk window; a more honest measure of acquisition efficiency than raw CAC, because it accounts for early churn. A low enrolled-learner CAC with high early churn produces a high CAC per active learner — which is the number that actually matters. Currently not tracked.
• CPG (Cost Per Graduate) — total lifecycle cost (acquisition + retention + operational support) divided by graduates produced; the ultimate unit economics metric for an education business. Requires cohort-level tracking from enrollment through graduation. Currently not tracked.
• Monthly ARPL (Average Revenue Per Learner)
• CRC (Cost of Retention per Cohort)
• Financial dismissal rate (primary preventable churn signal; tracked via Chargebee)
• Billing health: payment failure rates, financial aid utilisation

Core AI functions

• Financial monitoring: AI tracks the full financial metric set in real time; surfaces alerts when ratios move outside targets — early enough for corrective action, not as a post-mortem
• Financial impact translation: when a domain proposes a policy, feature, or operational change, AI models the financial consequence. Inputs can come from any domain — a proposed change to progression pace, a new discount policy, a shift in enrollment timing. AI outputs the modelled revenue impact, LTV effect, and payback period movement. This makes the financial dimension of every significant decision visible before it is made, not after.
• Automated financial reporting: standard financial reports (revenue, cost, margin, cohort economics, payback period) are generated automatically on defined cycles. No manual compilation required. Reports are available to the relevant stakeholders immediately on schedule.
• Payment failure detection: AI identifies learners at risk of lapsing due to payment failure and triggers proactive outreach before the failure event
• Financial aid matching: AI identifies learners who may qualify for financial aid or alternative payment plans and surfaces this proactively — reducing financial friction as a dropout cause
• Discount and dismissal correlation: AI tracks which specific discounts, scholarships, enrollment timing patterns, and acquisition inputs correlate with financial dismissal and retention outcomes — and generates the monthly discount toolkit recommendation that Finance reviews and approves. The analytical outputs are specific: not just "discount X correlates with lower retention" but "discount above Y% combined with enrollment in the final week of the month produces a financial dismissal rate Z% higher than baseline." These patterns are currently completely invisible. Making them visible directly informs the discount toolkit, enrollment team incentives, and marketing campaign targeting. This intelligence layer is a shared output with Data & Intelligence (domain 9) and Marketing (domain 1).

Human roles

• Financial strategy: pricing decisions, financial aid policy, and payback period targets are human decisions informed by AI-surfaced data
• Payment exception handling: payment disputes, refund requests, and financial hardship cases are handled by humans with full account context

Data Inputs: Enrollment data (revenue); learner persistence and retention data (LTV calculation); CAC data from Marketing & Growth and Enrollment; operational cost data per domain Outputs: LTV:CAC by cohort, market, program, and channel; CAC per active learner; CPG per cohort and program; payback period tracking; CRC per cohort; financial dismissal rate by acquisition input; financial metric alerts to founder-level dashboards; monthly discount toolkit recommendation (inputs: financial targets + conversion data + financial dismissal and retention correlation)

Integration points

• Draws revenue data from Enrollment (domain 2)
• Draws retention and graduation data from Learner Success (domain 5) and Graduate Outcomes (domain 7)
• Draws CAC data from Marketing & Growth (domain 1)
• Feeds all financial metrics to Data & Intelligence (domain 9)

Tooling

• HubSpot — revenue and billing pipeline data; enrollment-to-payment handoff
• Chargebee — subscription management system; billing cycles, payment status, dismissal events; primary source for financial dismissal data and LTV calculation
• PayNXU — learner-facing payment platform; the point at which learners pay through multiple payment options; integration with Chargebee and the central data layer required
• Jira / Linear (under evaluation) — financial operations task and exception tracking
• Confluence — financial process documentation, billing policies, market-specific pricing rules
• Payment processing tooling — AI-led tool audit required (Section 1.13); must integrate with HubSpot and the central data layer
• Accounting and financial reporting tooling — AI-led tool audit required (Section 1.13); must feed financial metrics to Data & Intelligence, not create a parallel reporting silo

Compliance

• Consumer financial protection regulations apply to payment plans, refunds, and financial aid communications per market
• VA: specific billing and refund regulations apply to VA-funded learners; handled as a distinct compliance layer

Build phases Current state: Financial metrics tracked but partially manual; LTV:CAC calculation not fully automated; financial aid matching not systematic; CAC per active learner and CPG not tracked; financial dismissal pattern analysis does not exist; Chargebee data not fully integrated into the analytical stack Near term: Instrument full financial metric set with automated calculation; build CAC per active learner and CPG as live tracked metrics; integrate Chargebee data into the central data layer; build financial dismissal pattern analysis; build payment failure detection and proactive outreach; fully separate NAM and RoW financial reporting; build the discount-dismissal correlation layer (requires acquisition-retention stitching in Data & Intelligence) Target state: Real-time financial intelligence across all metrics; payment friction proactively managed; monthly discount toolkit driven by AI-generated retention-correlation analysis; automated financial reporting live on defined cycles; financial impact translation active — every significant cross-domain decision assessed against modelled financial consequence before approval; LTV:CAC improving as PLG channels reduce CAC and retention improvements extend LTV

5. The Integration Layer

What this section defines

The integration layer is the technical architecture that makes Nex-OS a unified operating system rather than a collection of connected tools. It defines: how domains communicate, how data flows between them without duplication or contradiction, how AI decisions are scored and surfaced, how human triggers arrive with complete context, and how the system learns from its own operation over time.

Every domain brief references this section for the technical implementation of its integration points. Champions design their domains against these specifications — they do not invent their own integration patterns.

Design principles

1. One source of truth per data type. Already stated in Section 2 as a data governance principle — it is also an integration constraint. No domain writes a canonical data type that another domain already owns. Ownership is defined and exclusive; shared read access is universal.

2. Publish, don't push. Domains publish state changes to the central event bus. They do not push data directly to other domains. A domain that needs to react to another domain's state change subscribes to the relevant event. This keeps domains independently deployable and prevents tight coupling.

3. Every cross-domain flow has a defined data contract. An integration point is a defined contract specifying: what data is shared, who owns it, in what format, at what latency, and what downstream systems may do with it. Contracts are defined at the architecture gate before build begins. A domain is not permitted to consume another domain's output without a ratified contract.

4. No dark areas. The system must be able to see everything — not just what it generates, but everything that produces operational data about Nexford. This principle has two parts.

Part A — no unregistered data flows. Every data flow between systems must be registered in the integration layer. A shared spreadsheet that serves as the working record for a domain, a manual export used to feed one system from another, a direct database connection that bypasses the event bus, a webhook not in the architecture — these are all dark areas. Dark areas undermine the data flywheel, create compliance risk, and make the system unauditable. Where a dark area exists, the correct response is to build the integration, not to legitimise the workaround.

Part B — files are views, not flows. Files will always exist — reports downloaded for analysis, exports prepared for a meeting, working documents. These are permitted as read-only outputs for human consumption, not as data flows or systems of record. A file becomes a dark area when it is used as a handoff mechanism between systems or teams (replacing an integration that should exist), or when decisions made through it are not recorded back in the central layer. The governance rule is: a file may be the output; the decision it informs must re-enter the system.

The positive requirement — every tool feeds the flywheel. Beyond preventing bad data flows, this principle requires that every tool generating operational data — including tools primarily used for human collaboration — must have a registered ingestion path back into the central architecture. This applies without exception to: AI note-taking tools deployed across meetings (decisions, action items, and context captured must be ingested against the relevant record); AI agents operating within communication platforms such as Teams or Slack (interactions logged and accessible to the system, not siloed in the platform); and any AI tool adopted by any domain (ingestion path is a condition of adoption, not a future task). The data flywheel only compounds if it captures everything. A meeting where a key decision was made, or a Teams conversation where a lead was discussed, represents context the system needs — whether or not it was generated by the system in the first place.

5. Humans arrive in context. Every human-triggered task carries the full context required to act. The integration layer is responsible for assembling that context — not leaving it to the human to investigate. A task arrives in WorQ with: the triggering signal, the relevant record, the AI's recommendation, the confidence score, prior relevant history, and the consequence of each available action. Context assembly is a system responsibility.

6. The system learns from every resolved decision. Every human decision made in WorQ — approve, reject, override, comment — is captured as a labelled training signal and routed back to the relevant AI confidence model. This loop is not optional and not configurable per domain. Every domain's escalation history is a training asset.

The central schema

The central schema is the shared data layer. Every domain reads from it and writes to it according to its defined data contract. No domain maintains a canonical record for a data type it does not own.

Schema ownership by domain:

Record lifecycle — the canonical transfer model. A record has one owner at any point in time. When a lifecycle stage completes, the record is transferred — not duplicated — to the next domain. The previous domain retains read access. The transfer is an event published to the event bus; downstream systems subscribe to it.

The lead→learner record transition is the most consequential transfer in the system. At the point of enrollment, the full context accumulated by Marketing and Enrollment — source attribution, goal data, program fit assessment, engagement history, conversion touchpoints — is transferred to the learner record. Nothing is lost. Every downstream domain receives a learner with a complete history, not a blank record starting from enrollment. This is the data continuity principle in practice.

The event bus

Domains communicate through a central event bus. A domain publishes an event when its state changes. Downstream domains subscribe to events and react accordingly. No domain calls another domain directly.

Why events, not direct calls. A domain does not need to know which other domains care about its state changes — it publishes, and subscribers self-select. Adding a new domain that needs to react to existing events requires no changes to existing domains. Events are the natural model for a lifecycle system: "lead qualified," "application submitted," "learner enrolled," "payment failed," "assessment passed" are all state transitions that multiple downstream systems need to react to independently.

Core event types by domain:

Event schema standard. Every event must include: event_type, domain, timestamp, record_id (the canonical ID of the subject — lead, learner, application), confidence_score (where AI-triggered), market (NAM / RoW), and payload (event-specific data). Events are immutable once published. They are stored in the event log and available for replay, audit, and model retraining.

Identity and context threading

A person interacting with Nexford begins as an anonymous visitor, becomes a lead, becomes an applicant, becomes a learner, and eventually a graduate and alumni. At every stage the system knows who they are, where they came from, what they are trying to achieve, and what the system has done for them. This continuity requires a defined identity threading model.

The canonical identifier. Every person in the system has a single canonical ID assigned at lead creation. This ID travels through every domain. The lead record, the application record, the learner record, and the graduate record all reference the same root identity. Every event published by every domain references this ID. No domain creates a parallel identity for the same person.

The context object. Alongside the canonical ID, every record carries a context object — a structured document that accumulates throughout the lifecycle. It is not a log of everything that has happened (that is the event log). It is the current-state summary that an AI agent or human needs to act without investigation: stated career goal, current skills assessment, program fit score, engagement signals, academic performance, intervention history, financial status, and risk flags. The context object is updated by events — each domain writes to its own namespace within it. No domain writes to another domain's namespace.

Where the context object lives. The context object is stored in the central data layer — not in the CRM. HubSpot owns the commercial record (pipeline stage, communication history, enrollment status) and holds a reference to the canonical person ID. During the pre-enrollment phase, HubSpot reads the slice of context it needs for sales workflows — goal, program fit, enrollment status — but it does not own or store the context object itself. Once a person becomes a learner, HubSpot's role in the lifecycle diminishes further; the context object continues to grow in the central layer as academic, success, and financial data accumulates. Treating the CRM as the store for the context object would make HubSpot a de facto central data layer by accident and create an architectural dependency on a commercial tool that should not carry that responsibility.

The specific database platform for the central data layer is an open architecture decision (noted in domain 10, Technology & Platform) — the choice between Supabase, Azure-native services, or another platform is pending founder sign-off. That decision does not change this principle: wherever the central layer is built, the context object lives there, not in the CRM.

When a human task arrives in WorQ, the context object is what the system surfaces alongside the AI's recommendation and confidence score. The human does not investigate — they judge.

WorQ — technical architecture

WorQ is a domain-agnostic task layer that sits above the event bus. Any domain can create a WorQ task. Every task follows the same schema. Every resolution feeds back into the originating domain's confidence model.

Task creation. When an AI decision falls below its autonomy threshold, the AI publishes a worq.task_requested event to the bus. The WorQ service consumes this event and creates a task record with: task type (action / decision), domain, decision type, AI recommendation, confidence score, the full context object for the subject record, consequence description for each available action, user level required, priority, and any blocking dependencies.

User levels. WorQ routes tasks by user level, not by job title. User levels are defined per domain and represent the skills required to resolve a specific task type. Titles are used as a proxy at setup. User levels decouple task routing from org chart changes — a team restructure does not require reconfiguring routing. Multi-level approval is available for high-stakes, low-reversibility decisions and is configured per decision type, not per individual task.

Resolution and the feedback loop. When a user resolves a task — approve, reject, complete, dismiss, comment — WorQ publishes a worq.task_resolved event. This event carries: the original task, the AI recommendation, the human decision, the resolution note, the user level that resolved it, and time-to-resolution. Data & Intelligence consumes this event and updates the confidence model for the originating domain's decision type. The feedback loop is automatic — no manual retraining step is required for human override signals to influence future AI behaviour.

The audit layer. Every WorQ event is immutably logged. The audit interface allows filtering by: domain, decision type, confidence score range, user level, outcome, date range, subject record ID, and override flag. Designated auditors per domain have access. The AI self-audit cycle reads from this log. The log is never modified — corrections are new events, not edits to existing ones.

Confidence score infrastructure

Every AI decision in Nex-OS produces a confidence score. The infrastructure for generating, storing, consuming, and learning from these scores is a shared service — not implemented independently per domain.

Score generation. Confidence scores are produced by the AI agent making the decision and processed through the shared scoring service, which handles: score normalisation (all scores on a 0–1 scale regardless of the underlying model), threshold lookup (autonomy threshold and escalation threshold for the specific decision type), and routing logic (act autonomously / create WorQ task / no action).

Threshold governance. Thresholds are stored in a configuration layer owned by Data & Intelligence. Initial thresholds are set by the domain champion and founder-approved before the domain goes live. Threshold changes require the same approval. Thresholds are never changed autonomously by the AI — even when calibration data would support a higher threshold. The rate at which autonomy is extended is a founder-level decision, not a system-level optimisation.

Calibration. Every AI decision — whether autonomous or escalated — is logged with its confidence score and its outcome (from the event bus or WorQ resolution). Data & Intelligence runs calibration analysis on a defined schedule and surfaces recommended threshold adjustments to the domain champion and founder for sign-off. The system recommends; humans approve.

Integration standards

Every domain must implement the following to connect to the central architecture. These are verified at the architecture gate before build approval.

1. Event publication. The domain must publish the events defined in its domain brief to the central event bus in the standard event schema, in real time — no batch publishing.

2. Data contract compliance. The domain must read and write only the data types it owns or is authorised to consume, in the schema defined in each integration point's contract. Schema changes require a contract amendment and architecture review.

3. Context object compliance. The domain must write only to its own namespace in the context object. No domain reads from or writes to another domain's namespace.

4. WorQ compliance. Every human trigger must route through WorQ. Direct communication channels (WhatsApp, email, HubSpot sequences) are initiated as outputs of WorQ task resolution — not in parallel to it. A domain is not permitted to maintain a shadow queue — Slack channel, email inbox, shared spreadsheet — where human decisions are made outside the system.

5. Confidence score compliance. Every AI decision that could result in a WorQ task must produce a confidence score through the shared scoring service. No bespoke escalation mechanisms.

6. Audit log compliance. Every domain action — AI-initiated or human-initiated — must be logged immutably. No action is permitted to be unlogged.

7. Tool ingestion compliance. Every tool adopted by the domain that generates operational data — including AI note-taking tools, agents embedded in communication platforms, and any AI tool used in team workflows — must have a registered ingestion path into the central architecture. The ingestion path is defined at the architecture gate as a condition of tool approval. A tool without an ingestion path is not an approved tool.

8. File output governance. File exports and working documents are permitted as read-only outputs for human consumption. Any decision made through a file-based workflow must be recorded back in the system against the relevant record. Files must never serve as handoff mechanisms between systems or teams where an integration should exist.

9. Market attribution. Every record, event, and WorQ task must carry market attribution (NAM / RoW). Market-agnostic records are not permitted.

What is not permitted

• Direct domain-to-domain API calls that bypass the event bus. All domain communication is event-driven.
• Parallel data stores maintained by individual domains outside the central schema.
• Shadow WorQ queues — Slack channels, email inboxes, manual tracking — where human decisions are made outside the system.
• Tool integrations not registered in the architecture. A tool used by any domain that is not connected to the central architecture is a dark area. It must be integrated or decommissioned. This includes AI note-taking tools, agents in communication platforms, and any AI tool used in team workflows — ingestion path required as a condition of adoption.
• Files used as system handoffs or parallel records. An export that substitutes for an integration that should exist, or a spreadsheet that is the working record for a domain, is a dark area regardless of how widely it is used. The fix is always to build the integration.
• Confidence scores set to 1.0 by default. Autonomous actions taken without a genuine confidence calculation are a compliance and quality failure.

Section 6 — Build Governance: pending founder review of Section 5.