Capability Portfolio

Use with Chapter 23. Keep one evidence table for a stated domain. The canonical level names come from the TFIS homepage; the columns and checks below are book-developed practice. This is not an official certificate, validated score, or a new maturity framework.

Blank reusable portfolio

Portfolio ID, owner, date, and working domain:

Current task, allowed actions, and consequential limits:

Current instruction route and actual version:

Relevant source/permission boundary:

Help used: manual work, assistant, agent workflow, other reviewer:

Next operation I want to rely on:

Leave unsupported cells empty or write “not demonstrated.” Preserve the actual input, supplied context, first output, review, correction, and relevant repeat result behind a claim. Identify constructed examples and planned tests as such. Do not turn a supplied answer into an observed result.

The Functional Life uses Manual Operator, Tool User, Workflow Builder, and Loop Engineer at L0, L1, L2, and L4 respectively; L3 and L5 share the homepage names. Its closed-feedback emphasis informs the book’s verdict checks. The variants are descriptions within TFIS’s sources, not additional levels.

Challenge one claim

Claim selected and exact supporting record:

What another reviewer could establish from that record alone:

What required an unstated memory, missing source, or assumption:

Revised claim:

Demonstration needed to restore a broader claim:

Input and expected properties prepared before the attempt:

Actual first result, review, repair, and relevant repeat result:

What remains unresolved:

Review conditions

Check the existing TFIS pillars without producing a weighted score. Agency: what can proceed under the stated limits? Clarity: whose task and acceptance criteria govern? Competence: can you explain and diagnose the work? Accountability: where is the judgment, and what state was actually verified? Security: what access, permission, portability, and recovery conditions apply?

Conditions that should trigger re-review: Changed instruction, model/setup, source format, tool permission, material task scope, or discovered defect. Identify which prior evidence each change affects.

Worked sample: fictional Himura Inc.

Portfolio: capability-portfolio-v1.

Domain: Source-faithful action-list examples and a reviewable thirty-minute workshop-design pack. The current selector reaches instructions-v3. The rationale explains its history; it is not a second selector.

The records below are demonstration resources from the fictional case. They are authored teaching specimens, not actual user runs or advanced-level certificates. A reader who performs a corresponding exercise should fill the table with their own observed evidence. The portfolio does not give Audy an independently verified overall rank.

Evidence routes already available

L0 — direct task understanding: Start with the capability baseline, literal workshop practice set, and inquiry brief. They show what the activity is intended to elicit and how review can expose a missing performance. A reader’s next evidence is an actual unaided attempt and explanation, with time and repair recorded under a consistent standard.

L1 — useful assistance: The Chapter 7 two-pass packet supplies v1/v2, exact sources, the flawed Wednesday date, migration diagnosis, and changed-input specimen preserving “soon.” The Chapter 16 demonstration adds the case where current v3 is supplied but a suggestion is promoted into an agreement. These are distinct diagnoses. Keep actual assisted first attempts to determine which occurs in your own work; the source’s suggested trial count is not a validated threshold.

L2 — connected workflow: Use the operating manual and delegated workflow practice to inspect the sequence and handoffs. The relevant evidence is a complete observed input→extraction→candidate→source comparison→bounded repair→review packet. If the human supplies each step, record that help rather than calling it independent execution.

L3 — bounded supervision: The delegation contract defines the permitted sequence, return, and escalation. The review policy and review practice show withdrawn acceptance and repaired review of a candidate that merged distinct objects. A policy file is a prerequisite; an actual executor’s trace and the supervisor’s observed response are still needed for an operational claim.

L4 — architecture and retained judgments: The system contracts make source/candidate identity and role completeness inspectable at the join. V13-01 shows a scoped correction that must preserve both imprecise and explicitly supplied timing. A complete operational claim needs the actual architecture used, observed role handoffs, the approved stored verdict, write verification, and a later attempt that reads and applies it. The book’s constructed records do not supply those runtime observations for the reader.

L5 — meaningful replacement and recovery: The portability drill and synthetic package provide a no-code rehearsal of context reconstruction, missing input, and stale authority. The enterprise runbook adds operating capacity and recovery responsibilities. File access in another editor is distinct from observed behavior on another model/provider. The portfolio records which was actually tested, plus the dependencies that remain.

Commercial context alongside the levels: The product experiment contains three constructed discovery conversations, two proposals, one agreed USD 300 pilot, and a revised pack accepted for rehearsal. The unit-economics model tests financial assumptions. Neither buyer agreement nor a favorable scenario proves an SSA-CMM level; no payment receipt or learner outcome is supplied by these teaching records.

E23-01: repair an overstated verdict claim

Candidate claim: “L4 complete: the verdict ledger is implemented and next-run improvement is verified.”

Attached material: The Chapter 13 authored packet: Input A, bad output, V13-01, reviewed correction, Input B, and expected properties. It explains the operation but is not a receipt of an actual write or agent execution.

Revised claim: “I can explain and rehearse scoped verdict review using this specimen. Durable write and changed-input use in my actual configured workflow remain to be demonstrated.”

Next demonstration: Within authorized practice records, review one actual candidate, save the approved verdict to its intended location, reopen it, and follow the maintained route into a later attempt. Use a changed source that explicitly supplies a date. Inspect whether the output retains that date while respecting the earlier correction against invented precision.

What would fail: A saved file that contains different wording; a pointer resolving to history; an alleged retrieval that cannot identify the relevant record; a new output copying the old answer or erasing the explicit date. Name which happened, repair that dependency, and repeat the affected check. Do not declare success merely because the expected behavior is described here.

E23-02: narrow an unsupported provider claim

Candidate claim: “Provider independence passed.”

Attached material: A record of opening the selected Markdown working set in another location/editor. No second-provider output is included.

Revised claim: “Selected files are readable and their context can be reconstructed under the recorded local conditions. Provider behavior remains untested.”

Next demonstration if relevant: Supply only authorized task/source material to an available different assistant, retain the exact configuration information you can observe, and run both the precision/uncertainty and conflict cases. Keep the answer key separate until review. Record any adaptations. A substantive instruction change creates a different procedure whose earlier cases need appropriate rechecking.

No second provider available: Keep the narrower claim and continue the useful local recovery practice. The exercise does not require purchasing access or inventing a comparison.

Historical-version inspection

Follow run-02, then the current selector. The specimen belongs to v2; current main-case work uses v3. A valid historical link does not make the specimen a test of a version it did not use. Preserve the historical record and ask for a fresh current-version observation before making the broader execution claim.

Acceptance criteria

• A bounded domain, task, help used, and current authority are explicit.
• Claims link to actual evidence, and constructed resources remain distinguishable from observed performance.
• An input, supplied version, first output, review, repair, and relevant repeat can be inspected where the claim depends on them.
• Manual rehearsal alone is not described as deployed agent supervision, multi-agent coordination, verified runtime learning, or provider interchangeability.
• The five pillars expose specific gaps without hiding them in a numerical average.
• One defensible claim and one corrected overstatement lead to an appropriate next demonstration.
• A change in conditions triggers review of the affected claim without rewriting valid history.
• Commercial assumptions, income, and capability claims retain their separate meanings.

Common failures and repairs