Chapter 23: The SSA-CMM Ladder
Assemble evidence of what you and your systems can do in one stated domain, identify the next missing demonstration, and improve it without treating a chapter, a tool, or a sale as a maturity certificate.
A sale does not tell Audy which level she has reached
Audy has a larger collection than the one she began with. It contains source-linked examples, current instructions, verdicts, a recovery practice, delegation and review procedures, system contracts, and a product experiment. The fictional case has also reached one agreed paid pilot and a revised pack accepted for rehearsal. The economics exercise has made the owner’s workload visible.
She could arrange those records into a persuasive story of progress. She could also attach a high SSA-CMM label to that story and stop asking what the records actually demonstrate. The danger is especially clear after a buyer agrees to pay. Commercial agreement changes the evidence about that particular offer; it does not establish that a memory write survived, a delegated workflow escalates correctly, or a replacement provider preserves behavior.
This chapter asks Audy to make a capability portfolio. It is an ordinary evidence table with links, scope, observations, and the next repair. It brings the book’s work together without adding another maturity framework. A portfolio is useful when someone can inspect a claim and find the conditions under which it held, including what happened when an important condition changed.
The case’s examples remain authored fiction and constructed teaching specimens. Their literal inputs and outputs help you learn to judge evidence. They are not receipts of real model runs, customer transactions, or observed learner effects. Your portfolio must contain your own demonstrations when you claim an operational capability. Copying Audy’s successful rows would preserve the lesson while inventing your result.
Bring the capability-portfolio artifact, your earlier practice records, and one recurring task you understand well enough to review. Begin by asking what claim those records can bear, rather than which title would look best above them.
Keep the actual ladder visible
The main TFIS homepage names six levels: L0 Task Operator, L1 AI-Assisted Operator, L2 Workflow Orchestrator, L3 Agent Supervisor, L4 Multi-Agent Architect, and L5 Sovereign Architect. Those are the canonical names used in this book. The model expresses TFIS’s proposed capability progression; it is not presented here as a validated psychological test or an independently certified professional standard. (The Future Is Solo, n.d.-b)
The Functional Life uses different names for four positions: Manual Operator at L0, Tool User at L1, Workflow Builder at L2, and Loop Engineer at L4. L3 and L5 retain the same names. Its treatment particularly emphasizes preserving judgments and verifying their durable use as the loop closes. The difference is disclosed because “Multi-Agent Architect” and “Loop Engineer” direct attention to related but distinct aspects of a system. (The Future Is Solo, n.d.-a)
The diagram is a navigation aid. Its text alternative is the sequence just given, moving from direct task operation through assistance, workflows, supervision, multi-agent architecture, and sovereignty. The book’s evidence checks explain how to investigate those capabilities in practice; they do not turn the illustration into a certification procedure.
A level should help you choose the next useful demonstration. If it becomes a way to avoid examining a weak dependency, it has stopped helping. A well-understood manual procedure can be a better current choice than a fragile automated one, even while you develop the ability to delegate more of the work.
State the domain before the claim
“I can supervise agents” is too broad to inspect. Supervising a bounded draft from synthetic notes differs from supervising a system that can spend money, communicate externally, or change a production database. The task, inputs, permitted actions, review requirements, and consequences determine what the claim needs to establish.
Audy chooses a narrow domain for this portfolio: preparing and reviewing action-list examples and the associated workshop-design pack. Her current source-representation instruction remains instructions-v3, reached through learning-loop-v1. The paid pilot adds delivery and buyer-review evidence within the story. It does not silently broaden that instruction into permission for customer communication or deployment.
Write the claim as an operation with conditions. “Given these authorized notes and the current instruction, I can produce a source-linked proposed action list, preserve the specified uncertainty, and identify when clarification is needed” can be challenged. It names the input, useful output, and an important limit. “I am good with AI” leaves all three open.
Then identify how much help the performance required. Did you choose each next step? Did an assistant execute a bounded sequence? Did you supply the expected answer? Did another person diagnose the failure? Those forms of support can all be useful, but hiding them makes the portfolio less informative about what you can repeat.
You may have strong evidence in one domain and little in another. Keep that unevenness visible. The ability to review a familiar workshop example does not transfer automatically to a medical claim, a legal agreement, or an unfamiliar software system. A portfolio earns its value by locating the boundary of your judgment as well as its strength.
L0: make direct work inspectable
At L0, begin with the work you perform directly. Select a recurring task, describe its input and useful result, and record what happens when you do it. The objective is to make the task and its cost visible enough that later assistance can be compared with something meaningful.
Audy’s early baseline asked her to notice where workshop design required research, interpretation, drafting, and review. The most useful observation was not that a document took a certain number of minutes. It was that a credible workshop brief needed an activity producing participant work she could inspect. That understanding gave later outputs a criterion beyond speed or polished wording.
Your evidence can be a modest packet: the original input, your unaided attempt, a note about the decisions you made, and the criteria used to review it. When you make a mistake, preserve it with the correction. A baseline consisting only of your best final answer leaves no account of the work a tool might genuinely change.
Do not make the baseline artificially difficult to create a dramatic comparison. Use comparable material and the same completion standard when you later evaluate assistance. Include review and repair in both conditions where they are part of completing the task. A faster draft that leaves essential checking for later has not yet demonstrated faster completed work.
The next practical move is small: select a recurring part whose desired input and output you can explain, and prepare a saved instruction for assistance. If you cannot say what a good result preserves, returning to direct work and domain learning is an appropriate repair. The baseline helps you find that missing judgment before a tool reproduces the uncertainty at greater speed.
L1: demonstrate useful assistance across actual attempts
L1 concerns assistance applied to a task you can still judge. A reusable prompt is a starting artifact. Evidence requires actual attempts, the material supplied, the first outputs, and the corrections needed. A prompt that exists but has never been used establishes that you wrote an instruction, not that it produces the intended result.
The Functional Life suggests repeated use of a saved task prompt, including a five-run starter exercise. Treat that count as a practical invitation to observe variation, not a scientifically established reliability threshold. A narrow set of easy cases can pass repeatedly while leaving an important failure untouched. (The Future Is Solo, n.d.-a)
Audy’s early action-list examples show why the first response matters. An output can copy a plausible owner into an unassigned task or turn “soon” into a date. If she saves only the repaired answer, she loses the distinction between what the assistant initially did and what her intervention made correct.
For your demonstration, choose related inputs that vary a consequential feature. Include an explicit date in one, imprecise timing in another, and a suggestion that resembles a commitment. Keep expected answers separate during drafting. Review the fields against their own source passages, record the help required, and explain the error before asking for another answer.
The next repair follows the evidence. An ambiguous instruction may need clearer wording. A correct supplied rule that was violated may require better source extraction, checking, or a different choice of assistance. An unfamiliar subject may require learning or expert review. Adding instructions indiscriminately does not distinguish these problems and can leave you with a long prompt whose effective behavior remains unclear.
L2: connect steps without losing their contracts
L2 moves the unit of work from a single assisted task to a repeatable workflow. The useful evidence concerns the connections: what one step receives, what it returns, what the next step may assume, and what happens when a prerequisite is missing or a check fails.
Audy’s workflow separates source extraction, drafting, comparison against the original material, bounded repair, and a human evidence packet. Its steps exist because they answer different questions. Extraction identifies what the source establishes. Drafting proposes a useful representation. Review compares that proposal with its support. A second polished draft is not a substitute for the independent comparison the workflow requires.
To demonstrate the chain, retain one complete run from input through reviewed result. Record the actual handoffs, not just an arrow diagram. Then introduce a safe missing dependency in a rehearsal copy. The workflow should identify the absent input or stale version and hold the step that depends on it. A chain that continues by inventing missing material is operating, but it is not satisfying its contract.
This level can include substantial human direction. If you manually supply every stage, say so. You are testing a repeatable procedure and its interfaces. That practice can prepare delegation without pretending that the whole sequence already runs independently.
The next move is to define a bounded unit another executor can carry through without asking you to choose every internal step. Preserve the inputs, return contract, allowed decisions, and escalation conditions. If the chain cannot explain what to do when a source is unavailable, making it more autonomous will not supply the missing policy.
L3: show that supervision changes the result when it should
At L3, the evidence must reach beyond a delegation document. A bounded agent or executor should perform the authorized sequence, return a reviewable result, and bring the right unresolved conditions to the human. The supervisor must then inspect the consequential meaning rather than merely approve the presence of an output.
Chapter 17’s contract makes the distinction concrete. It allows a proposed candidate and a limited repair, with a hold when a material defect persists. It does not authorize external communication, source edits, or changes to authoritative memory. A real demonstration would record the executor’s actual actions and returns under those limits, including how the human responded.
Chapter 18 adds a supervision failure: an initially accepted concise draft merges distinct objects and conceals a conflict. The repaired review withdraws that acceptance and checks the particular version against the source. A portfolio should preserve such an event because it shows what supervision needs to catch. Deleting the first judgment would make the procedure appear more dependable than its history supports.
For your own run, include a condition that should be escalated and a covered uncertainty that should remain in a useful partial answer. A missing authorized source can hold drafting. An unassigned owner already covered by the instruction should remain visible without halting every other part. The distinction tests whether the contract guides decisions, rather than turning “ask the human” into a universal escape from the task.
The supervisor’s workload belongs in the evidence. Record the review needed to catch defects and the tasks kept pending when capacity was exhausted. If supervising the current operation costs more effort than performing it directly, that is information about the present design. You may narrow the delegation while improving it, without pretending that unrestricted autonomy is the required next step.
L4: inspect coordination and the retained judgment
The canonical L4 name directs attention to architecture across agents. The Functional Life’s Loop Engineer name directs attention to feedback that persists and is used. For the book’s practical portfolio, describe both the actual architecture you operate and what happens to the human judgments that should improve its later work. Do not replace either description with an agent count.
Chapter 19’s separate drafting and checking roles illustrate an architectural responsibility: their outputs must refer to the same source packet and candidate version before they can be joined. Two draft returns do not supply an independent check. A report that examined the old candidate cannot approve the revised one. These relationships make coordination inspectable and give a failed join a specific repair.
The verdict practice adds a second requirement. A useful correction identifies its target, reason, scope, and current status. An actual completed write must be reopened. A later attempt must receive the applicable verdict and apply its meaning to changed input. Copying the old answer is not the same operation as using the retained judgment.
V13-01 gives you a precise challenge: avoid inventing a date when the source says “soon,” while retaining a date that a new input explicitly supplies. A later run that changes every date to “unknown” has overgeneralized the correction. Keep the input, retrieved verdict, actual response, and review together so the failure can be traced to retrieval, interpretation, application, or authority.
The book’s manual ledger and constructed role packets make these operations understandable. They do not supply evidence that your agents performed them. If your current arrangement is one assistant with manual handoffs, describe it accurately and choose the next warranted demonstration. Additional agents are useful only when their distinct responsibilities and coordination improve a defined operation enough to justify the extra work.
L5: preserve the operation when a dependency changes
At L5, the question extends beyond producing a correct answer in a familiar environment. Can the necessary records, judgment history, permissions, and operating procedures survive a meaningful change of provider, tool, location, or responsible person? Can you restore a usable state and identify what still depends on someone else’s infrastructure?
The portability drill provides a starting distinction. An exact copy may preserve a stale instruction. A readable file may have lost the annotation that explained its scope. A new model may receive the correct packet and still mishandle a conflict. Each condition needs its own observation and repair.
Choose a dependency your actual workflow has, and rehearse its loss without damaging active work. Rebuild the selected operation from the portable package, inspect current authority, perform a changed-input task, and recover from a deliberately missing source. Where provider substitution matters, record an actual second-provider attempt under known conditions. Opening files in another editor is useful evidence about access; label the model behavior untested if no model comparison occurred.
Document how someone else could continue the necessary work within its authority, including where that person must seek expertise or permission. The goal is understandable continuity, not pretending that every judgment has been removed from the human role. A procedure can remain dependent on a specialist while making that dependency explicit and planning around it.
Economic sustainability also matters to the larger solo-enterprise claim. A portable system that consumes more owner attention and cost than its activity can support has not solved that business problem. Chapter 22’s model and the pilot’s actual scope therefore belong beside technical evidence, with their assumptions intact. Revenue, margin, and level are different judgments; none should be used as a shortcut around the others.
Use the five pillars to find a missing question
The main TFIS account names Agency, Clarity, Competence, Accountability, and Security as five pillars. Use those names to inspect the selected operation from different directions, not to create a new weighted average. The source’s self-assessment can prompt reflection, but this portfolio requires the relevant observable work. (The Future Is Solo, n.d.-b)
For Audy, Agency asks which part can proceed under the agreed limits and where her presence remains necessary. Clarity asks whether the buyer’s task, deliverable, exclusions, and acceptance criteria are actually understood. Competence asks whether she can explain a source error or recover the procedure without relying on fluent reassurance.
Accountability asks where the review decision is recorded and how she knows the completed state matches it. Security asks what material and actions are permitted, which dependencies are retained, and whether a move preserves the necessary boundaries. These questions should lead you to particular records and demonstrations.
Do not average a critical missing condition into a reassuring score. Strong drafting ability does not cancel unknown permission to use the source. A readable archive does not compensate for an obsolete current selector. Mark the specific dependency unresolved and hold the operation that relies on it. You can continue other authorized work while repairing that gap.
Work through an overstated portfolio entry
Audy’s first candidate entry says, “L4 complete: verdict ledger implemented and next-run improvement verified.” The attached evidence is the book’s V13-01 packet: an authored bad answer, a reviewed correction, a changed input, and expected properties. It makes the distinction understandable, but contains no receipt of an actual agent write or later run.
She repairs the entry rather than discarding the useful packet. The claim becomes: “I can explain and rehearse scoped verdict review using this specimen; actual durable write and changed-input use in my configured workflow remain to be demonstrated.” The source links stay. The unsupported completion statement is removed. The next action now has a visible purpose.
A second entry initially says, “Provider independence passed,” pointing to a copied Markdown package. The supplied record establishes that files can be opened and their relationships inspected in another location. Without an actual second-provider attempt, the claim must remain narrower. Audy labels file portability separately and leaves provider behavior untested.
These repairs make the next demonstration concrete enough to perform. For the verdict case, save an approved record in the authorized location, reopen it, supply it through the maintained route, and keep the actual changed-input output. For provider behavior, choose a permitted receiving environment and inspect what it does with the same task and material.
The worked portfolio supplies these entries and routes to the existing artifacts. It distinguishes a demonstration resource from a reader’s execution evidence. You can use that distinction throughout the book: a template helps you produce a record; it does not supply the observation that should fill it.
Choose one gap that blocks the next useful operation
Before selecting that gap, give a reviewer a route through one existing claim. Begin with the operation being claimed, then let the reviewer find the actual input, instruction version, output, and judgment. Allow them to ask which detail supports the judgment. If you have to fill the crucial connection from memory, add it to the record after checking it.
For a concrete rehearsal, use Chapter 7’s run-02 and the current instruction route. Run-02 is a constructed specimen associated with v2; the route now selects v3 after Chapter 11. A careless portfolio entry might call it a successful test of the current instruction because its link still opens. The historical claim is narrower: it illustrates the earlier handling of “soon” under the displayed v2 instruction.
The reviewer should preserve that useful history and ask for a fresh observation before claiming current execution behavior. This is the same distinction that matters when software, prompts, source packets, permissions, or model settings change.
Have the reviewer inspect a rejected result too. They should be able to identify the defect, why the repair addresses it, and what the repaired result still leaves unresolved. This prevents a portfolio from becoming a gallery of polished answers with no evidence of how consequential errors are recognized.
You do not need to expose an entire private archive for this review. Prepare the smallest authorized packet that permits the claim to be checked, preserving source meaning and status. If confidentiality prevents a material part from being shared, state the limitation and arrange an appropriate review method. Removing the evidence and retaining the confidence would change what an outside reader can assess.
A portfolio can become an excuse to collect more proof than the work needs. Avoid trying to complete every possible challenge before performing a modest authorized task. Identify the operation you want to rely on next, then find the missing condition that would make reliance unjustified.
If the next step is another draft-only pilot pack, you may need a dependable source review and a realistic delivery window more urgently than a multi-provider architecture. If the next step is unattended overnight processing, missing escalation and recovery evidence becomes much more consequential. The appropriate demonstration follows the intended use, not the prestige of a level.
Write the repair as an observable event. “Improve memory” is vague. “A changed-input attempt retrieves V13-01 through the current route, preserves a newly explicit date, and leaves a reviewable record” states what you will inspect. Define the failure result too: if it copies the old answer or reads a superseded instruction, locate that dependency before expanding the task.
Then repeat the relevant check under the repaired conditions. If your change affects earlier behavior, include the earlier case. If it changes only a broken link, verify the route and dependent operation rather than rerunning every unrelated exercise. The portfolio should help you select meaningful work and stop redundant checking when the claim has the evidence it needs.
Revisit a claim when its conditions change
A capability portfolio describes a working state, so maintenance should follow changes to that state. An instruction revision, different model, broader permission, new source format, or revised deliverable can invalidate part of an earlier demonstration without making every other observation worthless. Record which conditions the claim depended on so that you can identify the affected evidence.
Suppose your workflow previously accepted pasted text, but the next task introduces photographed notes. The source-faithfulness rule may remain sensible. The extraction operation now has an additional dependency: the handwriting must be read accurately before the action list can be judged. Keep the old text-input evidence and add the new transcription-and-source comparison required by the changed task.
Or suppose a draft-only assistant is given permission to save a candidate file. The existing semantic checks do not establish that the write reaches the intended folder or leaves the source unchanged. Add a bounded write-and-reopen demonstration and inspect the permission setting. If the tool cannot safely express the intended write scope, keep the save manual while the rest of the useful workflow continues.
Use plain status words for portfolio claims: current under the stated conditions, historical, awaiting a relevant check, or withdrawn after a discovered problem. These describe evidence applicability rather than your identity. A withdrawn claim can remain valuable history when its reason helps prevent someone from relying on it again.
Audy’s earlier withdrawal of a mistaken acceptance offers the same lesson at a smaller scale. The correction should be visible at the point of reliance, not hidden in an unrelated note. When an operating claim changes, update the portfolio and the procedure that depends on it. Leave unrelated evidence alone, and record the specific demonstration that would justify renewed reliance.
Keep capability and commercial judgment in contact
The pilot has made the final distinction unavoidable. Audy may produce a sound pack and still need to change its price, scope, acquisition method, or support. She may have buyer interest in a task that her current procedure cannot safely deliver. A capability portfolio and a product experiment answer different questions, but decisions improve when each can refer to the other.
For a service professional, useful evidence could join an agreed scope, a reviewed delivery, actual correction history, and the effort needed to support it. For an educator, it could connect the designed activity, authorized participant work, and the limits of what the review establishes. For a software builder, it could connect a bounded requirement, actual behavior, permission controls, and a tested recovery path.
These adaptations do not make expertise interchangeable. They show how the same habit of evidence can travel: name the operation, retain its support, inspect the result, and mark what you cannot yet claim. An advanced label should never authorize you to stop learning the domain whose work you supervise.
Field assignment: defend one claim and repair another
Complete the capability portfolio for one recurring domain. Link the baseline, actual assisted attempts, workflow, supervision, verdict, recovery, and commercial evidence that are relevant. Mark absent or simulated evidence plainly. Do not manufacture a filled row merely to make the ladder look complete.
Select one claim another person could verify from the records, and one that currently overstates them. Explain the first without AI: identify the input, help used, current instruction, output, review, and limit. Rewrite the second so it names the missing demonstration rather than hiding it behind a general confidence statement.
Perform that next demonstration where it is authorized and useful. Save the actual first result, including failure. Make a bounded repair, repeat the affected check, and update the portfolio’s statement of scope. Your completion evidence is an inspectable claim and a repaired gap, not a numerical average or a self-awarded title.
Audy ends with a clearer account of her capabilities and dependencies. The paid pilot remains one fictional commercial event; advanced operational claims still require their particular evidence. Chapter 24 returns to the economic destination and asks what a million-dollar solo company would actually have to sustain.
References
The Future Is Solo. (n.d.-a). The functional life (Field Manual No. 01). Retrieved September 10, 2026, from https://life.thefutureissolo.com/
The Future Is Solo. (n.d.-b). The future is solo. Retrieved September 10, 2026, from https://thefutureissolo.com/