Professional Portfolio and Profile Compiler

A polished profile can still be false

A learner has five different kinds of profile material: a verified Open Badge with evidence, a self-written “expert” claim, an endorsed community contribution, an expired certificate, and a private project artifact. A naive profile builder flattens all five into the same list of “skills.” The result looks professional while hiding the evidence class, current status, provenance, and privacy boundary.

In this lesson you build Evidence-backed Professional Portfolio/Profile Compiler Contract v1. The compiler is read-only over governed source records. It preserves claim type, evidence, issuer/endorser, verification state, credential status, expiry/revocation, artifact hash, provenance, visibility/redaction, compiler version, and source snapshot hash. It emits a reproducible profile projection whose public claims are never stronger than the underlying evidence.

Core rule: compile a view; do not rewrite the truth. A self-asserted claim remains self-asserted unless stronger evidence exists. An endorsement remains an endorsement. An expired or revoked credential remains expired or revoked. A private artifact remains private unless an explicit visibility change authorizes a different projection.

For: learning-platform engineers, credential/profile architects, portfolio product engineers, QA, and governance reviewers. Not for: automatic hiring decisions, reputation scoring, silently changing learner records, inferring mastery from presentation quality, or treating cryptographic verification as proof of every profile statement.

Route orientation and ownership boundary

MKN-024 owns only the Professional Portfolio/Profile Compiler outcome. Its frozen prerequisites are hard prerequisite MKN-021 and soft prerequisite MKN-023. MKN-023 owns AI Tutor Grounding and Evaluation; MKN-025 owns Reputation Anti-gaming and Trust Signals. This lesson may consume their bounded evidence but does not absorb their outcomes.

Foundation learners receive a field map and a traceable baseline. Repair learners isolate the first broken dimension—claim type, status, evidence, provenance, visibility, source snapshot, or mutation. Experienced learners defend projection and precedence rules without hiding them in a single “profile score.”

Three checkpoints: F1 state the owned boundary and one non-goal; F2 reject one misleading compile shortcut by exact field/state; F3 recompile after changed visibility and a newly verified overlapping credential, then explain the deterministic diff.

Mental model: canonical evidence in, typed projection out

Reference flow:

governed source snapshot → typed evidence normalization → status + provenance checks → visibility/redaction policy → claim-strength rule → deterministic profile sections → diff + audit receipt

Keep four layers separate:

1. Canonical source records: learner-authored claims, assessments, credentials, endorsements, project artifacts. The compiler reads them; it does not edit them.
2. Evidence class and state: SELF_ASSERTED, OBSERVED, ASSESSED, ISSUED, VERIFIED, ENDORSED, plus CURRENT, EXPIRED, REVOKED, UNVERIFIED, or disputed states.
3. Projection policy: private/redacted/public visibility, section mapping, display order, explicit labels, and claim-strength precedence.
4. Compiled view: a reproducible output tied to compiler_version and source_snapshot_hash, with a diff against the previous compiled version.

A compiler can make a profile easier to read. It cannot make weak evidence stronger merely by rewording it.

Foundation contract: evidence identity, status, visibility, and immutability

Preserve at least the Bible dimensions: profile_version, learner_ref, source_record_ref, claim_id, claim_type, skill_or_achievement, evidence_ref, criteria_ref, issuer_ref, endorser_ref, credential_ref, verification_state, credential_status, issuance_date, expiry_date, revocation_state, alignment_ref, project_artifact_ref, artifact_hash, provenance_ref, visibility, redaction_rule, compiler_version, compile_timestamp, source_snapshot_hash, and unverified_label.

Eight invariants:

1. Canonical learner/source records are immutable from the compiler path.
2. Every public claim retains a source record identity and provenance reference.
3. Self-asserted, assessed, issued, verified, and endorsed claims remain distinguishable.
4. Expired or revoked credentials cannot be projected as current.
5. A private artifact cannot become public without an explicit authorized visibility change record.
6. A compiler may shorten or reorganize display text, but cannot detach the claim from evidence/criteria/issuer/status.
7. Unverified claims require an explicit label; omission is not verification.
8. The same source snapshot + compiler version + policy must produce the same projection and diff.

Deep explanation: what Open Badges and Verifiable Credentials prove—and what they do not

Open Badges 3.0. 1EdTech defines rich metadata for a verifiable achievement, including the earner, issuer, criteria, and possible evidence. Open Badges 3.0 also supports endorsements and aligns its credential model with the W3C Verifiable Credentials family. This gives a compiler structured credential evidence. It does not define MAKNOW section layout, visibility defaults, narrative wording, precedence rules, or a universal skill score.

Verifiable Credentials Data Model 2.0. W3C VC Data Model 2.0 is a Recommendation for expressing machine-verifiable, privacy-respecting credentials on the Web. Verification can establish properties about the credential and its proof. It does not make unrelated self-authored profile claims verified, prove present-day skill level in every context, or grant permission to publish private evidence.

Current standards state. VC Data Model 2.0 remains a W3C Recommendation. W3C also published a VC Data Model 2.1 Working Draft on 16 August 2026. Therefore this package pins claims to 2.0 Recommendation semantics and records the newer draft in freshness metadata instead of silently changing the lesson authority.

Local design authority. Claim precedence, section layout, redaction behavior, compile diff format, and visibility defaults are MAKNOW design decisions. External specifications are evidence mechanisms, not product-governance permission.

Worked examples

Example A — valid baseline compilation

The source snapshot contains:

• verified badge BADGE-DB-01 with issuer, criteria, evidence, and current status;
• self-asserted Distributed systems expert claim with no independent evidence;
• endorsed community contribution whose endorsement is authentic but distinct from mastery evidence;
• expired certificate CERT-LEGACY-01;
• project artifact PROJECT-X with visibility=PRIVATE and a stable artifact hash.

The valid public projection includes the badge as VERIFIED_CURRENT, the self-claim as SELF_ASSERTED / UNVERIFIED, the contribution as ENDORSED, the expired certificate only in a clearly expired/history representation if policy allows it, and no bytes or sensitive description from PROJECT-X. The compiler records source_snapshot_hash, compiler_version, and the exact redaction decisions.

Example B — wrong shortcut

A template says “expert” and an unrelated endorsement exists. The compiler upgrades the self-asserted claim to VERIFIED. This fails because endorsement and verification are different evidence classes and the evidence does not bind to that claim.

Example C — privacy leak

A learner recompiles a profile and a private project becomes public because the UI default changed. Without a visibility-change record, the compiler must HOLD; presentation defaults do not override governed source visibility.

Failure modes and minimal repairs

Repair the smallest invalid dimension; do not redesign the whole profile unless evidence shows the architecture itself is wrong.

Alternatives and trade-offs

Compile on read minimizes stale public views but can make audit/debugging harder unless every compile stores version and snapshot identity. Materialized profile versions improve reproducibility and diffing but require explicit refresh and invalidation rules. Credential-first profiles are conservative but can underrepresent valuable project evidence. Narrative-first profiles are readable but are dangerous if summaries are allowed to outrun source evidence.

Do not collapse these trade-offs into one weighted score. State which fields are decisive, what becomes advisory, and what forces HOLD, redaction, or human review.

Architecture bridge for experienced engineers

A production-quality compiler usually separates:

• source adapters for learner records, assessments, credential stores, and artifact registries;
• normalization into typed claim/evidence/status records;
• policy for visibility, redaction, precedence, and labels;
• projection builder that cannot write back to source systems;
• deterministic diff between profile versions;
• audit receipt binding output to policy version, compiler version, and source snapshot hash.

A useful property test is: if you replay the same frozen snapshot through the same compiler/policy version, the projection hash must match. A second property is monotonic evidence strength: changing wording cannot promote a claim to a stronger evidence class.

Guided and independent practice

Guided. Load the baseline fixture. For each source record, classify claim type, evidence, issuer/endorser, verification, credential status, expiry/revocation, artifact hash, provenance, visibility, and redaction. Compile the public view and explain every omission or label.

Repair. Run the expired-credential mutation. Identify the exact invalid dimension: credential_status was dropped while the projection still says current. Repair only the status binding and rerun.

Independent. Run the self-assertion promotion and private-artifact leak fixtures without reading baseline output. Explain why both must fail even if the final profile would “look better.”

Experienced. Execute the transfer: revoke public visibility for one project, import a newly verified credential that overlaps an existing self-asserted skill, recompile from a new snapshot, preserve both provenance chains, and produce a deterministic diff. Do not reuse the baseline decision as an oracle.

Verification: what the offline lab proves

The lab uses synthetic JSON only—no network, wallet, issuer private key, production learner profile, or real project artifact. Twelve producer tests cover: valid baseline compilation; expired-as-current; self-claim promotion; private-to-public leak; canonical-source mutation; missing snapshot identity; revoked-as-current; detached evidence; endorsement-as-mastery; artifact hash mismatch; missing unverified label; and changed-context transfer with deterministic diff plus rejection of baseline-oracle reuse.

The lab proves contract consistency for this synthetic compiler. It does not prove that a real learner possesses a skill, that a real credential is authentic on a live network, or that a public profile is appropriate under every legal/privacy regime.

Assessment and transfer

S1 Retrieval: explain MKN-024’s owned boundary and one adjacent non-goal. S2 Application: build the complete Evidence-backed Professional Portfolio/Profile Compiler Contract for the baseline. S3 Diagnosis: an expired credential is rendered as current because credential_status was omitted. Name the invalidated state, consequence, and minimal repair. S4 Transfer: public visibility for one project is revoked and a newly verified credential overlaps an existing self-asserted skill. Recompile from the new snapshot, preserve provenance, update evidence class/visibility, and produce a deterministic public-profile diff.

Blocking dimensions are identity/contract, exact evidence binding, negative evidence, bounded projection, and transfer. A response fails if it mutates source records, launders expired/revoked status, upgrades claims without bound evidence, leaks private artifacts, or copies the baseline output after the source snapshot changed.

References, freshness, and claim boundaries

1EdTech — Open Badges https://www.1edtech.org/standards/open-badges Bounded FACT: Open Badges represent verifiable achievements with defined metadata such as earner, issuer, criteria, and possible evidence; Open Badges 3.0 supports endorsements and aligns with Verifiable Credentials conventions. Boundary: the standard does not define MAKNOW profile layout, visibility defaults, narrative precedence, or skill scoring.

W3C — Verifiable Credentials Data Model v2.0 https://www.w3.org/TR/vc-data-model-2.0/ Bounded FACT: VC Data Model 2.0 is a W3C Recommendation for machine-verifiable, privacy-respecting credential claims. Boundary: verification of a credential does not verify unrelated profile claims or authorize publication.

W3C — VC Data Model series status https://www.w3.org/TR/vc-data-model/all/ Freshness note: v2.0 remains a Recommendation; v2.1 is a Working Draft dated 16 August 2026. This lesson remains pinned to v2.0 semantics until governed requalification.

Official sources were rechecked on 2026-09-13. Recheck evolving credential practice by 2027-01-15 or earlier after material specification change. Projection precedence, redaction rules, compiler diff format, public visibility defaults, and narrative generation remain MAKNOW DESIGN.