Portfolio evidence and competence inventory — ferdo Paths
_Design artefact for DataAnnotation application preparation, 2026-11-15_
State: P1 desk research completed; personal contribution verification is still open. This public document defines an evidence method, not an assessment score, an application, or a claim that any participant can independently solve coding challenges.
1. Evidence taxonomy
- E3 — inspected source artifact: an actual code file, test or schema, independently read from the repo. This establishes the artifact, not independent human authorship or passing execution.
- E2 — documented project result: release notes, README or an acceptance report that describes checks; tests were not rerun solely by reading that document.
- E1 — candidate statement: self-reported education, work, languages, specific contribution or experience; corroborate if material.
- E0 — unmeasured: neither a reviewed artifact nor an independent skills demonstration yet. E0 means unknown, not deficient.
Do not convert a repository's presence, an LLM-written source file, a user-facing demo or a project acceptance report into a claim that an individual can code alone at assessment speed.
2. Reusable evidence ledger
| Field | Required input |
|---|---|
evidence_id | stable ID, source URL and date |
project_role | clearly bounded problem/feature |
source_class | E3, E2, E1 or E0 |
observed_function | behavior or specification verifiable in the source |
candidate_contribution | explicit human/AI-assisted division; don't guess |
runtime_status | source-only, documented test, independently executed, live verified |
transferable_skills | skill mapping tied to observed function |
limitations | unknowns and possible counterexamples |
future_validation | a single original diagnostic or explanation test |
The private candidate-specific inventory and reviewed repository links belong to Genel Merkez, not in this public plan.
3. Qualification skill gaps to check later
| Track | Typical portfolio evidence | Independent validation still needed |
|---|---|---|
| General | research protocols, critical analysis, documented source reasoning | timed English reasoning, claim checks, response comparison |
| Coding | JS/Python algorithms, tests, reproducible bug fixes | solo debugging, data structures, complexity, edge cases, AI-free work |
| Multilingual | translation and editorial case studies | semantic fidelity, register, cultural nuance |
| Data Science | R analysis, statistics, reproducible data processing | causal inference, SQL, pandas, data leakage handling |
| Backend/AI systems as separate long-term career goal | API code, authorization checks, deployment/CI evidence | production ownership, concurrency and security, end-to-end tests |
4. Evidence interview to run only after approval
For each artifact: Who designed the task? Which code was drafted by humans, by AI, or jointly? Which edge cases were found by independent debugging? Which tests were run personally? Which commands produce a reproducible result? What failed, and how was it fixed? Can the candidate explain the design and make an original change without AI assistance?
No credentials, personal addresses, client-provided materials, actual paid-qualification questions or private learning results will be published.
5. Controlled next steps
- ☑ Define the portfolio review method and skill-to-track mapping.
- ☑ Inspect a representative set of source artifacts and log private evidence with limitations.
- ☐ Verify author/contribution boundaries per artifact.
- ☐ Select at most two truthful case studies per candidate track.
- ☐ Draft the actual English application narrative later.
- ☐ Run original, independent skill diagnostics later.
- ☐ Begin a real DataAnnotation assessment only upon a separate explicit decision.
Status: Planning only, paths.ferdo.net not deployed as an app.
Private canonical record: Projects/Paths/DataAnnotation P1 Yetkinlik ve Portfoy Kanit Envanteri. This document intentionally excludes candidate-specific claims and personal details.