One tool's output is not automatically another tool's valid input.
Each offer publishes its own contract. Any handoff must be chosen, reviewed, and represented explicitly by the operator; no automatic interoperability is claimed.
Portfolio workflow · Seven bounded decisions
Seven offers. One map of where each decision stops.
Choose the offer that resolves the uncertainty in front of you. The map covers three paid local tools, one fixed-scope repository review, and three complete MIT utilities; it is an optional decision sequence, not a required pipeline or bundled assurance claim.
01 / FreezeWhich declared fields entered?
Freeze one explicit values-free candidate-feature policy before target values are read.
02 / Audit timeCould this join know that row?
Audit declared event, availability, period, grid, revision, and freshness boundaries.
03 / PreflightAre the replay inputs ready?
Check declared authorities, identities, discovery counts, and byte bounds without executing the replay.
04 / ExplainIs the claim reviewable?
Make scope, evidence, comparison, failure criteria, limits, and decision use explicit.
05 / AttemptDid execution begin?
Distinguish a stopped preflight from an invoked command and consumed attempt.
06 / AdmitMay this artifact advance?
Evaluate exact subject and evidence hashes against one declared lifecycle policy.
07 / ReviewWhere is the release boundary weak?
Map one public repository and one named release path into prioritized implementation work.
Decision map
Start with the question, not the product name.
-
01Before target readInspect Feature Freezer
$249 · Licensed local software
Freeze the candidate-feature contract.
Use Target-Blind Feature Freezer when the governed decision is which declared schema fields satisfy an explicit pre-target policy.
- Bring
- A strict freeze contract and values-free JSON column schema with explicit roles.
- Keep
- Ordered manifest, selected and excluded CSV ledgers, summary, and checksums.
- It does not decide
- Whether roles are true, proxies are harmless, leakage is absent, or a feature is useful.
-
02Before temporal useInspect Temporal Auditor
$499 · Licensed local software
Audit the declared temporal boundary.
Use Temporal Boundary Auditor when local CSV or JSON Lines records must be checked against explicit backward as-of join, period-completion, revision, and freshness rules—or when caller-declared clock interpretations need bounded comparison against a reference series.
- Bring
- A strict contract plus local decision and context records with declared clocks.
- Keep
- Aggregate audit or clock-probe JSON, streaming JSON Lines, and Markdown summary.
- It does not decide
- Truth, the true clock, causality, complete lineage, every leakage channel, or statistical validity.
-
03Before replay executionInspect Replay Input Preflight
$99 · Licensed local software
Stop a replay before missing or changed inputs reach it.
Use Replay Input Preflight when another tool should start only after declared authorities and local inputs pass exact presence, identity, discovery, and byte-limit checks.
- Bring
- A strict JSON contract plus contained local files and directories.
- Keep
- READY, REVIEW, or BLOCKED JSON, Markdown, and checksums.
- It does not decide
- Meaning, independence, completeness, reproducibility, safety, compliance, or permission to execute.
-
04Before reviewInspect Evidence Preflight
$0 · MIT utility
Make the claim's evidence contract explicit.
Use Evidence Preflight when a conclusion, recommendation, or technical result sounds persuasive but the review record behind it remains implicit.
- Bring
- The claim, scope, provenance, comparison, failure criteria, limitations, and decision use.
- Keep
- A readable Markdown card or schema-identified JSON record.
- It does not decide
- Whether the claim is true, statistically valid, causal, safe, or fit for a decision.
-
05Before executionInspect Attempt Boundary
$0 · MIT utility
Separate rejected preflight from consumed run.
Use Attempt Boundary when an expensive or stateful command should run only after one bounded preflight and retry lineage depends on whether execution was invoked.
- Bring
- A reviewed plan, workspace root, commands, resource limits, and protected paths.
- Keep
- A create-only JSON receipt recording invocation, attempt consumption, bytes, and hashes.
- It does not decide
- Whether a command is safe, the host is trustworthy, or unrelated processes touched data.
-
06Before promotionInspect Artifact Admission
$0 · MIT utility
Apply a declared rule to one exact artifact.
Use Artifact Admission when an implementation and named evidence must satisfy a deterministic local policy before entering a governed lifecycle stage.
- Bring
- A policy, workspace, exact subject and evidence files, and one lifecycle receipt.
- Keep
- A schema-identified JSON decision with the selected receipt's exact byte digest.
- It does not decide
- Whether evidence is correct, a build is authentic, vulnerabilities are absent, or an artifact is safe.
-
07Before public releaseInspect Release Boundary Review
$450 · Fixed-scope review
Map one repository-specific release boundary.
Use Release Boundary Review when a public GitHub repository and one named release path need a decision map, evidence and attempt-boundary gap analysis, and implementation ordering.
- Bring
- One public repository, one named release path, goal, version, and non-sensitive context.
- Receive
- A written decision map, evidence-referenced gaps, and prioritized roadmap.
- It does not include
- Private access, implementation, penetration testing, certification, or outcome guarantees.
Composition rules
Sequence the records without merging the claims.
Free proof, licensed repetition, and paid diagnosis solve different needs.
The MIT utilities are complete bounded tools. The private-delivery products license repeatable local checks. The fixed-scope review adds repository-specific analysis rather than unlocking a hidden utility feature.
Six retained records still do not become one universal proof.
Identity, signatures, source truth, complete lineage, vulnerability analysis, causal validity, trusted time, compliance, safety, and fitness require separate evidence and controls.
Worked pattern · Optional sequence
A team is preparing a model-data workflow and its release tooling.
Before target values are read, the team freezes an explicit candidate-feature declaration. It separately audits whether temporal context was available at each decision time. The team documents the resulting technical claim, wraps one costly verification command with an attempt boundary, and applies an artifact-admission policy to exact release bytes and named evidence.
If the remaining problem is repository-specific architecture rather than a repeatable local check, the team may commission the fixed-scope review. None of these steps is mandatory, and no record silently validates another.
- 01Declared feature boundaryValues-free pre-target contract retained
- 02Temporal boundary reportDeclared clocks and findings retained
- 03Reviewable claimEvidence contract and limitations retained
- 04Attempt receiptInvocation and retry lineage retained
- 05Admission decisionExact governed bytes admitted or denied
- 06Repository roadmapSeparate human review only when needed
Combined boundary
More records do not create universal assurance.
Used separately or in a reviewed sequence, the offers can make seven different decisions easier to inspect. They do not collectively provide signatures, factual verification, source authenticity, complete lineage, sandboxing, remote attestation, vulnerability analysis, causal validity, trusted time, compliance, production safety, or a guarantee of correctness, reproducibility, release success, or fitness. Add those controls separately when the risk requires them.
Choose a starting point
Route by decision, then inspect price, delivery, and non-claims.
Evidence behind the map
Inspect each offer before adopting the sequence.
The Evidence Library links the exact public material for all seven current decisions and separates two withdrawn standalone records.