AurelinxHR data, analysis, and workflows.
I am building Aurelinx as an experimental workspace that brings workforce and candidate records, inspectable analytical methods, and human-reviewed operations into one application. The repository contains an executable web and desktop prototype with a FastAPI backend; its analytics and controls remain under research and are not validated for operational HR decisions.
The engineering question is whether imported HR data, transparent calculations, and permissioned workflows can share one reviewable surface without presenting exploratory outputs as established evidence.
The live preview is for demonstration and technical review with synthetic or non-sensitive data. Aurelinx is not ready for real personnel records, hiring, performance, retention, or other employment decisions.
Source inventory, with execution and release evidence separated.
Research alpha · active development · 31 tracked test files · source v0.2.9
The public main source snapshot at commit 62b0b147baa9d19be792e59560fcfb5eb12f14b4 was fetched and checked on 2026-10-21; main still pointed to this commit. Its tracked tree contains 31 test source files: 27 backend pytest files and four client test files. It also contains eighteen numbered Alembic migrations. The repository defines root scripts for running the client and server test suites, but those commands were not run for this portfolio update. The code and desktop metadata at this source snapshot declare version 0.2.9; GitHub published the v0.2.9 release on 2026-10-12.
27 backend pytest files and four client test files; no passing total claimed
Python pytest source files in the repository tree
Client test source files in the repository tree
Numbered Alembic versions at main 62b0b14
Tool operation names present in chat-tool source
Services declared in Compose configuration
Configured as a Compose service; server/requirements.txt does not declare a Qdrant SDK dependency
Version declared by package and desktop metadata at this pinned main snapshot
The test suites were not executed for this portfolio update
No current CI result is claimed for this write-up
v0.2.9 lists Windows .exe and Linux .deb / AppImage assets; no macOS asset is listed
EVIDENCE_NOTE:: Research alpha and active development describe the product lifecycle; GitHub does not mark the v0.2.9 release as a prerelease. The 31 test files are a source inventory, not a passing-test count. Test execution and current CI status were not re-audited for this case-study update. The Compose services are configuration, not proof of a live or production-ready deployment.
A connected workspace for HR data review.
HR teams often review workforce records, candidate profiles, analytical summaries, and routine follow-up in separate tools. Aurelinx explores a single workflow: bring those records into a scoped workspace, calculate visible summaries, let a person inspect the underlying evidence, then route any change through the applicable permission or approval path.
Decision support is an experiment.
The current code combines simple statistical summaries, hand-authored skill rules, graph algorithms, a candidate ranking heuristic, and optional language-model calls. These methods have different inputs and limitations. They have not been shown to predict employment outcomes or improve hiring decisions, so the product is presented for review rather than operational use.
The implemented application path.
This diagram follows the code and deployment configuration at the pinned source snapshot. The optional provider and vector-service boundaries are marked separately because their presence in configuration does not prove they are active in every request.
WEB WORKSPACE
Next.js route shell loads the React workspace; browser requests use the same-origin API proxy.
DESKTOP WORKSPACE
Tauri 2 and Rust wrap the web interface for desktop builds; the UI selects a configured API origin.
PRODUCT ROUTES
Authentication, employee and candidate records, analysis, intelligence, integrations, chat, privacy, and enterprise operations.
WORKFLOW BOUNDARIES
Permission checks, tenant filters on selected routes, audit records, tool calls, and approval records.
ANALYTICS SERVICES
Python methods calculate survival curves, role transitions, skill paths, team coverage, network metrics, and stored-field summaries.
BACKGROUND AND CONNECTORS
Redis and RQ support worker flows; a scheduler and provider adapters are declared in the application and Compose setup.
POSTGRESQL
SQLModel data access and numbered Alembic migrations hold application records and workflow state.
REDIS
Queue and cache service declared for asynchronous work; service availability is not measured by the health endpoint.
CONFIGURED PROVIDERS
Selected AI models and connected HR/productivity systems may receive requests according to the chosen workflow and adapter.
Qdrant is declared in production Compose. The audited server dependency list does not include a Qdrant client, so this case study does not claim that live application queries use it.
What the calculations actually do.
The methods below are implemented as distinct code paths. Equations summarize the current implementation; they do not imply that the underlying data, assumptions, or outputs have been validated for employment decisions.
Observed workforce survival
S(t) = ∏(1 − dᵢ / nᵢ), for event times tᵢ ≤ tINPUT · Positive employment duration plus an observed departure or censoring date/status.
A Kaplan–Meier product-limit curve is built from the cohort still at risk at each event time. The implementation adds Greenwood log-log 95% intervals and reports eligible, departed, and censored counts.
LIMIT · This describes the uploaded cohort. It is not an individual attrition prediction, and it depends on complete, consistently defined dates and outcomes.
Observed role transitions
Pᵢⱼ = Cᵢⱼ / Σₖ CᵢₖINPUT · Consecutive dated experience records grouped by person and role.
Transition probabilities are observed counts from role i to role j divided by all recorded exits from role i. Repeated steps multiply the empirical transition matrix; rows without observed exits become unmodelled probability mass.
LIMIT · A step means the next recorded role change, not a year or a promotion forecast. There is no smoothing or individual-level validation.
Skill graph matching
g(c,t) = min(1, level(c)/level(t)) / (1 + d_w(c,t))INPUT · Candidate or employee skill labels and levels compared with requested skills.
Aliases are normalized, then weighted shortest paths in a predefined skill graph provide a bridge score. An optional embedding score can raise a pair score when it clears the configured similarity floor and exceeds the graph score. A maximum-weight assignment avoids crediting the same source skill to multiple target skills in the detailed match.
LIMIT · The graph and level scales are designed rules, not a validated competency model. Optional embeddings require a configured provider and need a documented data-transfer review.
Budgeted team coverage
max Σsᵢⱼyᵢⱼ; x,y ∈ {0,1}; Σxᵢ = k; Σcᵢxᵢ ≤ B; Σᵢyᵢⱼ ≤ 1; yᵢⱼ ≤ xᵢINPUT · Active employees with positive, comparable compensation and recorded skills.
A mixed-integer program selects a fixed-size team under a hard budget and maximizes credited target-skill coverage. At most one selected employee is credited for each target skill; the solver uses a second cost tie-break after coverage.
LIMIT · This is a planning experiment driven by uploaded skill and compensation fields. It does not measure team performance, and the optimization objective is not a hiring or employment recommendation.
Collaboration network view
G = (V, E); EIᵥ = (externalᵥ − internalᵥ) / degree(v)INPUT · Imported employee-pair events within a selectable time window.
The API builds an undirected graph from deduplicated, in-scope event pairs. It calculates PageRank (damping 0.85), unweighted betweenness and corrected closeness, clustering, components, and department mixing; the client renders an interactive, filterable graph and selected-person evidence.
LIMIT · Centrality is relative to the graph sample. Event count is shown as tie strength, while centrality uses tie topology without that weight. The map is not a measure of performance, influence quality, or employee value.
Candidate ranking and AI explanation
2.6·skillHits + 2.1·roleHits + 1.3·deptHits + 1.0·sentiment + 1.8·matchScore*INPUT · A prompt, candidate profile fields, skill labels, and any existing stored score.
The current analysis route counts unique token overlap between the prompt and profile fields, computes a weighted score, keeps up to five profiles, then asks the selected provider to write an explanation. It is a heuristic retrieval step followed by generated text, not a learned ranking model.
LIMIT · The response confidence field is assigned from the number of returned profiles, not calibrated as a probability. A remote provider receives the top profile summaries, including identifying and job-related fields. Use synthetic or non-sensitive data in this alpha unless the provider and data handling have been explicitly approved.
The sentiment roll-up is not a sentiment model.
The reviewed service averages the stored sentiment_score field and counts stored is_at_risk flags. It also returns a fixed confidence value of 0.94 without calculating that confidence. Treat these as data roll-ups and an implementation issue, not measured sentiment, calibrated confidence, or a real-time risk model.
mean = Σ stored_score / nA running product surface with research-stage methods.
- Web and desktop shells, versioned API routes, database models, migrations, and configured deployment services are present in source.
- The Intelligence Center includes survival, skills, team, career-transition, and collaboration-network interfaces.
- Some read, update, create, and delete workflows are implemented; their permission and approval paths differ by operation.
From imported record to human-reviewed change.
INGEST
Create or import employee, candidate, skill, experience, or collaboration records; connector capabilities depend on provider configuration.
SCOPE
Authenticated routes pass a tenant identifier and apply explicit query filters in selected data paths.
CALCULATE
Python services transform the relevant stored fields into cohort, graph, skill, or optimization results.
INSPECT
The workspace renders curves, profile tables, summaries, or the interactive network graph for review.
APPROVE
The applicable user or admin can request a change; exact local deletions use an expiring approval record and audit event.
This describes the available implementation patterns, not a guarantee that every request follows the same path. External provider actions are only dispatched when a registered connector explicitly supports the action and the request is approved.
The current product areas.
Employee directory and profile records, with skills, experience, events, and stored workforce fields.
Candidate records and a rule-based first-pass ranking path, with optional language-model analysis.
Cohort survival estimates, observed role transitions, stored-score summaries, skills, and team-coverage exploration.
An interactive view of imported collaboration events, their represented ties, and graph measures for the shown sample.
A seven-operation chat tool boundary for search, read, modify, write, delete, analyse, and observe; external action support varies by connector.
Provider adapters, background job infrastructure, exports, and a Tauri desktop shell are present in the repository. Readiness is not implied by their presence.
What must be resolved before real HR use.
These are concrete engineering and research gates found by reading the source. The portfolio labels them as open work rather than implying the prototype has already passed them.
MODEL EVIDENCE
Add retrospective and time-based holdout evaluation, calibration where relevant, confidence intervals, subgroup analysis, and documented failure cases before describing any score as predictive.
DATA AND TENANT SAFETY
Remove development fallback authentication and default secrets from any public runtime; review browser token storage, verify every tenant filter, and decide whether database-enforced row isolation is required.
PROVIDER DATA FLOW
Document exactly which fields leave the application for each provider, add consent and retention controls, and isolate or repair the unused legacy screening helper before reuse.
OPERATIONS
Prove migrations, backup and restore, worker and queue health, rate limits, monitoring, and deployment configuration in a separate staging environment. The current health endpoint checks the primary database only.
The repository also contains an older semantic screening helper that is not referenced by the inspected API routes. If it is reused, it currently reads candidate rows without a tenant predicate and sends role, department, and skills text to OpenAI embeddings. That path needs tenant scoping and provider-data review before reuse.
Implemented controls need a deployment review.
Authentication. Argon2 password hashing and JWT code exist. The browser auth context stores access and refresh tokens in localStorage. In non-production mode, one common authentication dependency can fall back to a seeded development user; settings also contain development secret defaults. These patterns need review before real personnel data is used.
Tenant isolation. Many routes filter queries using tenant_id, but this source snapshot does not define PostgreSQL row-level security policies. Query-level checks need consistent coverage and isolation tests.
Chat redaction. The chat record serializer removes a defined set of sensitive columns before those rows enter that tool result. This does not make all provider calls data-minimizing; the separate analysis route sends top-ranked profile summaries to its selected provider.
Approval. Local deletion uses an exact payload, expiry and integrity hash, admin approval, and an audit event. Provider action execution is adapter-specific, and unsupported actions fail closed in the dispatcher.
A practical path to a credible preview.
- 01 / DEFINE DATA
Publish field-level provenance, synthetic-data boundaries, inclusion rules, missing-data behavior, and limits for every result. - 02 / TEST METHODS
Create reproducible datasets and baselines; evaluate time-based holdouts, uncertainty, ranking behavior, and subgroup error before making predictive claims. - 03 / HARDEN ACCESS
Remove demo fallbacks, rotate secrets, review token storage, verify tenant isolation across every route, and document provider data handling. - 04 / PROVE OPERATION
Demonstrate deployment, migration rollback, backup restoration, worker failure recovery, monitoring, and incident response in staging.
Open the source behind each claim.
Every code link below is pinned to the source snapshot used for this write-up, so reviewers can inspect the implementation even if main moves later.
FastAPI lifecycle, database startup, and registered versioned routes.
Cohort survival estimate, censor handling, and Greenwood log-log intervals.
Empirical transition counts, normalization, unknown probability mass, and validation status.
Weighted graph score, assignment, and mixed-integer team coverage.
Tenant-scoped imported event query and graph response.
Interactive graph view, filters, selection, and sample notes.
Sensitive-field serializer, exact deletion payload, expiry/hash checks, and admin approval.
JWT dependencies, non-production fallback behavior, and environment settings.
Declared API, web, worker, scheduler, database, cache, and vector service topology.
Aurelinx is an active research build, not a finished HR product.
My current work is to make the data path and methods inspectable, replace unsupported claims with evidence, and build the validation and security work needed for a responsible public preview.
AUDITED_MAIN::62B0B147 · SOURCE_DATE::2026-10-12 · REVIEWED::2026-10-21