Before
Career evidence may be real but too sensitive, employer-specific, proprietary, or internally identifying to publish as direct artifacts.
Executive takeaway
Showing capability without disclosing client operating procedures
This walkthrough demonstrates the proof-without-disclosure model: source truth, sensitive context, generalized patterns, public examples, capability claims, and review boundaries are separated so a portfolio can be credible without exposing confidential client work.
Operating context
Most of my strongest proof cannot be published as raw artifacts because the useful details sit inside employer systems, sponsor decisions, customer contexts, supplier workflows, or sensitive operating conditions. The public portfolio solves a different problem: show the decision structure while withholding the identifiers. That means translating real operating history into generalized patterns, synthetic examples, disclosure posture, and interview-only proof. This walkthrough shows how a reader can inspect capability without asking former sponsors to carry disclosure risk.
After
Readers can inspect generalized patterns, client-safe examples, source categories, and capability maps while confidential systems and internal procedures remain protected.
Leadership judgment shown
The same discipline used in governance work applies to the portfolio itself: separate evidence, assumptions, disclosure boundaries, and reviewable claims.
Scenario
The reviewer problem
The artifact library has several useful entry points. A reviewer needs a fast way to know which source answers the question in front of them and which link should come first.
Proof path needed
A reviewer wants credible public evidence quickly. They need the map, the live examples, and the source trail without reading every repository.
Source roles can blur
Repository READMEs, wiki pages, operating patterns, and capability indexes can all look like the same kind of proof unless the route names their role.
Review goal
Show where to click first for each reviewer need, what each source proves, and how the portfolio stays easy to evaluate.
Source map
Where the inspection starts
Each walkthrough card names one source family, its review purpose, and the visible link a reviewer should use.
Synthetic reader input
What different reviewers ask
These fictional inputs represent common reviewer needs.
| Reader | Primary question | First source to inspect | Useful proof signal |
|---|---|---|---|
| Recruiter | Where is the quickest credible proof path? | Portfolio Artifact Map | A guided walkthrough from portfolio question to public artifact. |
| PMO leader | Where are the governance frameworks and repeatable patterns? | Operating Patterns repository | Generalized operating patterns for portfolio review, intake, decision quality, and follow-through. |
| AI operations reader | Where are reliance boundaries and safe use expectations visible? | Capability Index | Capability-level framing that separates automation support from human accountability. |
| Hiring manager | Where is evidence without confidential details? | Portfolio wiki pages | Curated, public-safe context that connects examples to operating judgment. |
Evidence produced
What the source review creates
The review output should make the library easier to inspect. It gives each source a purpose and keeps the evidence path short.
Reviewer walkthrough
- One click-first source for each common reader question.
- Clear difference between repository source, wiki context, capability index, and module example.
- Direct links to the public sources named in the walkthrough.
Proof inventory
- Artifact map for discovery.
- Capability index for thematic inspection.
- Operating patterns for governance and review logic.
- Module repositories for runnable or inspectable examples.
Example scope
- Fictional reader inputs.
- Generalized operating patterns.
- Designed to show the review path clearly.
Handoff material
- Exact link targets for the landing page, profile repository, and wiki references.
- Review-first language that can be approved before publication.
- A route that can be linked later without changing shared files today.
Final review
Which source answers which question
This table is the review decision aid. It tells a reviewer what each source is for and where to click first.
Review frame
Start with the artifact map when the reviewer needs orientation. Move to the capability index for themes, the operating patterns repository for governance logic, and module repositories when the reviewer wants concrete examples or implementation boundaries.
| Reviewer question | Source that answers it | Where to click first | What the reviewer should expect |
|---|---|---|---|
| How do I navigate the artifact library quickly? | Portfolio Artifact Map | Open the artifact map | A curated source guide that points from review intent to proof artifact. |
| Which capabilities does the portfolio demonstrate? | Capability Index | Open the capability index | A capability-level view across governance, portfolio operations, AI operations, and decision support. |
| Where are the reusable governance patterns? | Operating Patterns repository | Open the operating patterns repository | Client-safe pattern pages and source material for inspecting operating approach. |
| Where can I see concrete modules and examples? | Module repositories | Open Marco's repositories | README files, examples, runtime folders, and boundaries for individual portfolio modules. |
| Where is the curated portfolio context? | Portfolio wiki pages | Open the portfolio wiki | A public-facing explanation layer that connects source artifacts to reviewer needs. |
Inspection path
Public sources for inspection
These are the source links named in the walkthrough. They are listed together so a reviewer can move from this draft into the public materials without hunting.
Proven in practice
Where this walkthrough ran for real.
This walkthrough is a generalized pattern. These named case studies show the same discipline operating in real environments.