Reuse Intake and Fit Assessment¶
Workflow — instantiates Shared-Input Variety Platform Design
Screens whether a new output should use the common layer, fork it, extend it, or remain separate.
Reuse Intake and Fit Assessment is a screening workflow triggered when a single new output is proposed, that routes it to one of four dispositions — use the common layer as-is, extend it, fork it, or stay separate — by testing the new output's requirements against the shared layer's variation boundary. Its defining move is being a gate for one incoming candidate, deciding fit at the moment of entry. It exists to prevent two opposite mistakes at once: a new output silently stovepiping because no one checked whether the shared layer would serve it, and a new output being force-fitted onto a shared layer that does not actually suit it.
Example¶
A university is launching a new online master's in data science. It already runs a shared online-learning platform — enrollment, an LMS, course-scaffold templates, proctoring, student analytics — used by its existing programs. Left alone, the new program's team might rebuild its own stack, or be told to cram everything onto the shared one.
Instead the proposal goes through intake. A short assessment maps the program's requirements against the platform's variation boundary. Most needs — enrollment, the LMS, the scaffolds — fall inside the boundary and are dispositioned use. Proctoring needs a program-specific extension for live coding exams: extend. One requirement, an integrated cloud-lab environment, falls outside the boundary and is granted a local-fit exception to run separately for now: stay separate. The workflow emits that disposition plus an onboarding checklist for each path. Outcome: the program onboards onto shared inputs in weeks and builds only the genuinely unique parts.
How it works¶
- Trigger on a new-output proposal — the unit of work is a single incoming candidate, not a portfolio-wide review.
- Score requirements against the variation boundary: in-boundary needs → use; near-boundary → extend; outside-but-worth-sharing → fork; outside-and-idiosyncratic → stay separate / exception.
- Emit a disposition and an onboarding path for each chosen route, so the decision comes with the steps to act on it.
- Time-box the assessment. Intake is a fast gate, not a project; a slow intake pushes teams to route around it and build their own.
Tuning parameters¶
- Screening depth — a lightweight questionnaire versus a deep technical review. Deeper yields better fit calls but slows every onboarding.
- Disposition thresholds — how much misfit tips a candidate from use toward extend, fork, or separate. Loose thresholds over-force reuse; tight ones over-permit stovepipes.
- Default bias — reuse-by-default versus separate-by-default; the default decides the borderline cases.
- Bindingness — an advisory recommendation versus a mandatory gate. A hard gate has teeth but invites gaming.
- Reassessment — a one-time call at entry versus periodic re-runs as the output evolves and its fit changes.
When it helps, and when it misleads¶
Its strength is that it makes each new output's relationship to the shared layer a fast, principled decision rather than a default or a fight — catching the silent stovepipe and the forced misfit before either becomes expensive. It is the make-or-buy[n1] decision applied per new output, with fork and extend as first-class middle options.
Its failure mode is hardening into a bureaucratic rubber stamp — an intake that waves everything through as "reuse" regardless of fit (a de-facto reuse mandate), or, just as bad, one that rubber-stamps "build your own," so the assessment becomes theater and the four dispositions collapse to one. The classic misuse is wielding intake to mandate reuse for political tidiness rather than to test fit honestly. The guarding discipline is to keep all four dispositions genuinely live and the boundary test real, treating intake as a fitness check rather than a compliance checkbox.
How it implements the components¶
reuse_onboarding_path— its output is the concrete onboarding route for the chosen disposition, turning a fit decision into next steps.variation_boundary— the fit test is the act of checking a candidate's requirements against the shared-versus-local boundary.local_fit_exception_path— the stay separate / carve-out disposition is the sanctioned exception for a genuinely idiosyncratic new output.
It does not migrate existing duplicated stacks in bulk or weigh their migration cost (scope_benefit_metric, common_capability_layer consolidation — that is its nearest twin Stovepipe Retirement Migration Plan); intake decides one new arrival's fit at the door, whereas the retirement plan consolidates legacy duplication already inside the house.
Related¶
- Instantiates: Shared-Input Variety Platform Design — intake is the entry gate that decides how each new output relates to the shared layer.
- Consumes: Shared Service Catalog supplies the menu of shared services intake screens a candidate against.
- Sibling mechanisms: Common Platform Roadmap · Cross-Output Cost Attribution Model · Joint Procurement or Tooling Pool · Modular Capability Library · Platform Governance Board · Product-Line Architecture · Shared Data or Feature Store · Shared Service Catalog · Stovepipe Retirement Migration Plan
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Reuse Intake and Fit Assessment operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it screens whether a new output should use the common layer, fork it, extend it, or remain separate.
Independent corroboration: The frozen evidence defines Reuse Intake and Fit Assessment as 'Screens whether a new output should use the common layer, fork it, extend it, or remain separate', so its operative form is Decision, Gate & Allocation.
Nearest alternative: Assessment, Review & Assurance — Reuse Intake and Fit Assessment includes features of a bounded evaluation of existing evidence or work that produces a finding or disposition, but its defining operation is a case-specific gate, selection, routing, prioritization, or resource disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Deciding whether to reuse, extend, fork, or separate a component follows modular engineering design.
Related originating lineages:
- Computer Science & Software Engineering — Software architecture materially formalized common layers, forks, and extensions.
- Organizational & Management Science — Portfolio governance contributes intake and ownership decisions.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: screens whether a new output should use the common layer, fork it, extend it, or remain separate.
Review resolution: Both blind reviewers agree that engineering_design is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement, domain reach disagreement starts from reviewer_a’s mechanism-specific evidence: Deciding whether to reuse, extend, fork, or separate a component follows modular engineering design. Reviewer A proposed alternates=computer_science, organizational_management, origin_mode=cross_disciplinary_synthesis, domain_reach=multi_domain, and encyclopedia_synthesis=true; reviewer B proposed alternates=computer_science, organizational_management, systems_cybernetics, origin_mode=convergent, domain_reach=universal, and encyclopedia_synthesis=true. The final record retains every independently supported alternate from either review (computer_science, organizational_management, systems_cybernetics) without an arbitrary cap, selects origin_mode=cross_disciplinary_synthesis to represent the combined lineage evidence, and keeps domain_reach=multi_domain and encyclopedia_synthesis=true from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Make-or-buy decision — the classic operations and strategy choice of whether to produce a capability in-house or source it externally. Reuse intake is the internal-platform version, decided per new output: use the shared layer (buy), extend or fork it (hybrid), or build separately (make). ↩