Mature open-source prior art covers most of the remaining Masters roadmap — and none of its operating loop

The largest finding is not a substitute

The single most consequential result is that several planned systems already have mature commodity layers that should not be rebuilt. Three discoveries change the likely implementation path rather than merely informing it.

Frappe Framework can cover a large part of the private institutional substrate. Its metadata-driven DocType model gives typed records, links, permissions, workflow states and transitions, and automatically exposed REST APIs over MariaDB, under an MIT-licensed core. That is most of the plumbing behind a qualification gate, a relationship model and an admission workflow.

docassemble is a serious substitute for much of the planned Guide runtime shell — adaptive interviews, conditional branching, document and report assembly, storage, email, API integration and background jobs, all MIT licensed. It does not replace the Masters evidence model or recommendation logic. It does mean a bespoke intake and report service must now earn its existence against a working alternative.

W3C PROV, the Wikibase statement model and RO-Crate already supply mature conceptual building blocks for stable claim provenance and an institutional self-model. Masters should not invent a provenance vocabulary from zero.

What each open system already has

Qualification and engagement acceptance

Frappe workflows, Flowable's BPMN/CMMN/DMN engine and the Apache KIE and Drools ecosystem all demonstrate human-task orchestration and explicit decision rules separated from application code. The conclusion is that no standalone custom rule engine is justified. What remains Masters-specific is the rubric, the evidence model, and the requirement that acceptance be an attributable human action whose facts, concerns, mitigations, open questions and rationale survive as first-class records rather than collapsing into one score.

Relationships and business development

Frappe CRM, SuiteCRM, Corteza, Dolibarr and Twenty all self-host, and all cover the lead, contact, activity and opportunity primitives. They differ on the axis that actually matters here:

The question is not which CRM has more features. It is which platform lets Masters own its relationship, provenance and decision model with the least long-term operational and semantic distortion.

Admission and continuing standing

Frappe HR covers recruitment, job applicants, interviews, interview feedback scored against defined skills, employee skill maps and appraisal. OpenCATS and OrangeHRM cover the conventional recruiting lifecycle. None of them demonstrates the Masters admission standard end to end: academic eligibility, credential verification, capability evidence, domain reasoning, consulting communication, operating fit, admission, availability, engagement match and continuing standing — with provenance and accountable human authority intact.

Generic applicant-tracking primitives should be reused. The admission standard should not be. And installing the full ERPNext and HRMS stack merely to obtain an applicant form is not a proportionate commitment.

Capability systems

This is where existing open source covers far more than a custom build should assume. Frappe HR supplies lifecycle, skills, proficiency, training links, appraisal and goals. Moodle supplies competency frameworks and learning plans. xAPI supplies an open interoperability specification for recording learning and work experience across systems, and Learning Locker supplies a compliant record store. CaSS, CASE and Open Badges cover competency definition, transfer and recognition.

The correct architecture is therefore not "a Masters LMS." It is a method layer over commodity systems, and what that layer must add is the part nothing here provides: the distinction between completion, observed performance, inference and managerial judgment; provenance; correction; comparable role-relevant standards; accountable human authority for advancement; institutional knowledge retention; and the management-burden economics of the whole arrangement.

Guide runtime

docassemble overlaps a surprising amount of the planned Guide plumbing, and its operational weight is real: the recommended production bundle is NGINX, uWSGI, PostgreSQL, Redis, RabbitMQ, Celery, cron and WebSockets. That is heavier than the small custom service concept, but it also replaces far more application code. SurveyJS Form Library is a lighter component-level alternative; Formbricks is a good survey primitive that does not approach docassemble's expert-system fit.

What docassemble does not replace is everything that makes the Guide a Masters artifact: the problem profile schema, per-field provenance, minimum-sufficient architecture decomposition, evidence snapshot logic, candidate technology rules, uncertainty handling, authority and continuity checks, the no-buy path, and the report semantics.

Provenance, publication and the self-model

For stable claim provenance, PROV supplies entity, activity, agent and the derivation relationships between them; the Wikibase model supplies claim, qualifier, reference and rank — which map closely onto the Masters need to separate a source fact from a Masters interpretation, with date, scope, evidence, confidence and supersession; RO-Crate supplies portable packaging. The recommendation is to borrow the semantics and keep the runtime ordinary: Git-versioned JSON or YAML with stable Masters IDs, without adopting RDF and SPARQL merely because the standards can express them.

For the institutional self-model, Wikibase is the strongest general semantic runtime, Backstage demonstrates the Git-managed entity-envelope and typed relation pattern, and DataHub is appropriate only if the problem turns out to be substantially about data lineage. None of them should be deployed for a first version. Institution-as-code — Git-managed typed objects with stable IDs, explicit stewardship, provenance, visibility, supersession, a machine-readable schema and a proven export — tests the thesis without making the experiment depend on a graph runtime from day one.

For the specimen library, Quarto renders one governed source to HTML, PDF, Word, OpenDocument and EPUB, and should be tested before any custom multi-format compositor is written. For search coverage, Quepid's methodology — query cases, judgments, rated relevance, separated tuning and holdout sets — is worth borrowing even where deploying Quepid itself is not.

What should not be built next

Until bounded spikes are complete, Masters should not build a custom CRM CRUD stack, an applicant-tracking system, a learning management system, a proprietary learning-event format that has not been compared with xAPI, a custom BPM or rules engine, a knowledge-graph runtime, a provenance vocabulary invented from scratch, a custom multi-format document compositor for specimens before Quarto has been tested, the full Guide backend without a docassemble comparison, or a large local speech model to solve a dictation pause.

The sequence the review itself implied

The review's own conclusion was that it had still been too runtime-first, and it proposed this corrected order — own the contract before choosing the application:

1. Canonical contract. Draft a small Masters-owned neutral schema for organization, contact, source, relationship, evidence, problem hypothesis, qualification case and qualification decision. Evaluate LinkML as the schema source. Acceptance is that the same fixture validates independently of any runtime, with stable IDs, a clean export, and no runtime-specific field names in the canonical layer.
2. Substrate bake-off. Map that contract into a Frappe custom app, into Corteza, and into SuiteCRM as a CRM-native control, using the same records and the same qualification workflow. Compare semantic fidelity, permissions, record history, workflow clarity, API ergonomics, export and reimport round trips, backup and restore, patch burden and custom-code surface.
3. Guide bake-off. Build one real Guide specimen against the same intake and report contract in the existing lightweight pattern, in SurveyJS with a small backend, and in docassemble. Compare implementations, not mockups.
4. Capability interoperability map. Prototype no product. Map one role, competency and evidence workflow through CASE, xAPI, CaSS and an optional Open Badge, and identify exactly what Masters must add.

A note on ordering

The sequence above is what this prior-art review concluded, and it is recorded here as part of the result. It is not Masters' current execution plan.

Subsequent architectural refinement moved the Findings publication layer ahead of these technology spikes, so that each comparison produces a durable public record rather than ending as an internal note. The substantive prior-art conclusions below are unchanged by that reordering; only the order in which the remaining work is done has moved. This record's job is to report the prior-art result, not to serve as the roadmap.

Final judgment

There is substantial mature open-source prior art for nearly every commodity layer in the remaining Masters roadmap, and no demonstrated substitute for the combined operating loop that runs from signal through relationship and provenance, qualification, problem model, governed evidence and method, required expertise, verified professional, engagement, artifact, outcome and institutional learning.

The implication is not to build it all. It is the opposite.

Own the institutional model, the methods, the provenance, and the authority and continuity boundaries. Reuse replaceable open-source runtimes for CRUD, workflow, recruiting, learning, guided interviews, publishing and graph infrastructure wherever they earn their place.