Enterprise SDLC guide
Enterprise SDLC integration guide
How to assign lifecycle ownership, design reliable handoffs, and pilot Arcore development tools inside an existing enterprise SDLC, with profiles of 37 delivery-relevant apps.
Reviewed October 24, 2026. Relevance and implementation maturity are separate assessments; source review does not establish runtime readiness or verified integrations, and use cases are illustrative.
Guide chapters
Review date: October 24, 2026
Adopt a small set of tools around clearly owned lifecycle records, then add specialized capabilities where they solve an observed problem. These repositories contain useful development implementations, prototypes, planning documents, and placeholders; they do not establish a single deployed enterprise platform.
Scope at a glance
| Review layer | Coverage | Direct | edge | N/A | Profiles |
|---|---|---|---|---|---|
| Original | 54 top-level projects in the two RepoLibrary folders | 21 | 23 | 10 | This guide |
| Supplemental | Scriptor, BrowserForge, and Showcase (UAT, documentation, and training) | 3 | 0 | 0 | This guide |
| Expanded | 33 further apps from the Projects/ folder, including ArcoreUAT, ArcoreVox, and two Workbench planning projects |
12 | 15 | 6 | Expanded Projects review |
| Combined | 90 unique app/tool entries in the master checklist | 36 | 38 | 16 |
The guide also includes an individual checklist for 606 utilities across 33 categories in ThatWeeklyPublicRepo (490 Direct, 110 edge, 6 N/A). Many Direct utilities apply only to a particular platform or workload. All of these are relevance counts, not deployment recommendations.
What this guide profiles: the 24 Direct apps and the 13 edge apps that support delivery (planning, budget, knowledge, identity, reporting, and demos) from the original and supplemental layers—37 profiles in all. Edge apps whose primary purpose is unrelated to delivery (for example media, academic, ML-training, and website projects) and all N/A entries are omitted here; their assessments remain in the master checklist and CSV.
Internal frontend/backend packages belong to their parent app; they are not counted as independent lifecycle products. Duplicate checkouts are evidence locations, not extra products (see directory coverage).
The lifecycle, integration, and rollout sections below were written against the original and supplemental apps. Expanded-review apps that fill a lifecycle gap are named where relevant, but their profiles and limits live in the expanded review.
Reading and using the guide
- Worked enterprise case study: follow a hypothetical company from a missed business commitment through application selection, requirements, delivery, pilot operation, and outcome review. Includes an evolving framework checklist, an enterprise technology inventory, and a UAT-to-training workflow.
- Master application checklist: all 90 reviewed apps, relevance, purpose, SDLC stage, and observed readiness; CSV supports filtering and adoption tracking.
- Expanded Projects review and directory coverage: profiles for the 33 expanded-scope apps and the disposition of every immediate
Projects/folder. - Individual utility checklist: all 606 utility entries with purpose, stage, integration point, and illustrative use context; CSV.
- The application profiles below provide a purpose, integration recommendation, practical use case, and adoption boundary for each of the 37 delivery-relevant original and supplemental apps. Start with the profile index to jump to an app.
Quick path by role: sponsors and portfolio leads read the lifecycle table and rollout; architects and platform teams read integration contracts and Foundry and Schema; QA, business owners, and training leads read the UAT and training profiles and the case-study workflow; delivery and finance leads read capacity and budget planning.
Direct means the app manages or implements a software lifecycle activity. edge means useful adjacent support with a different primary purpose. N/A means unrelated domain software/content, or no evidenced capability to integrate; N/A apps are listed only in the checklist. Relevance is not maturity: Overwatch is directly relevant in concept but documentation-only. Fiscal and Chronos remain edge cases by primary purpose, while their delivery-planning contribution is explicitly included.
Recommended lifecycle and ownership
Use the existing enterprise source-control platform, issue tracker, CI runners, artifact registry, identity provider, secret store, monitoring stack, and incident process where they already meet the need. These apps should fill specific gaps. A dashboard or second task store should not silently become another source of truth.
Arrows represent a recommended information flow, not proof that native connectors already exist. The ArcoreUAT server is outside the original two folders; it is profiled in the expanded review. Showcase contains source adapters for UAT, Scriptor, and BrowserForge input, but those imports were not executed in this review.
| Lifecycle activity | Proposed accountable owner | Candidate apps | Authoritative output and exit condition |
|---|---|---|---|
| Demand and feasibility | Sponsor / portfolio board | Genesis; Clarify for diagnosis | Approved business case, value hypothesis, scope, funding reference, owner |
| Requirements and acceptance design | Product owner / analyst | Scope; Blueprint | Stable requirement IDs, testable acceptance criteria, accepted specification revision |
| Architecture and data design | Architect / data owner | Schema; Blueprint; ArcoreAgent for AI dependencies | ADRs, schema exports, interface contracts, data classification, threat/design review |
| Execution and capacity planning | Engineering manager / delivery lead | Vector or existing tracker; Chronos, Fiscal, Ledger as supporting inputs | Owned work, dependencies, staffing assumptions, feasible capacity and cost forecast |
| Implementation and code review | Engineering / platform team | Foundry selectively; Narrator; selected utilities | Reviewed PR, generated-code provenance, reproducible build inputs |
| Verification and acceptance | QA lead / business owner | Test; Sentinel; BrowserForge; ArcoreUAT with UATCLI | Test results, browser evidence, and business acceptance attached to the exact candidate build |
| User documentation and training | Training lead / business process owner | Scriptor; Showcase; optional ArcoreVox narration | Reviewed, release-linked guides and demos; observed learner completion; lesson owner and review date |
| Release and deployment | Release owner / platform operations | Parkour or existing CD; DataControl for Tableau; ArcoreFleet and ArcoreVault as expanded-review platform inputs | Approved immutable artifact, environment-specific configuration, migration and rollback evidence |
| Continuous monitoring and risk | Service owner / SRE / security | Nexus; existing observability/security systems; ArcoreDesk only after ITSM evaluation | Fresh health and risk signals, alert ownership, remediation deadlines and closure evidence |
| Incident learning and retirement | Service owner / operations | Proof; Blueprint; tracker; Nexus | Supported findings, corrective requirements, or retirement approval and dependency cleanup |
Integration contracts: make handoffs reliable
Before building a connector, nominate an owner for each field. Store links and external IDs instead of duplicating mutable business records. Where there is no verified API, start with a reviewed export/import rather than writing directly into another app's tables.
| Handoff | Information to carry | Adapter and acceptance test |
|---|---|---|
| Genesis → Scope / tracker | Project ID, approved business-case revision, sponsor, scope boundaries | Export/map to the target project; replay the same approval twice and verify only one target project exists |
| Scope → Blueprint / tracker | Requirement ID/revision, acceptance criteria, priority, external work ID | Scope has durable outbound job models; exercise the chosen target, retries, and reconciliation with a rejected payload |
| Schema → Git / migration tooling | Model version, provider, exported DDL/Prisma/types/ERD, ADR link | Review generated changes; apply a migration in a disposable database and check compatibility and restore behavior |
| Foundry → Git | Template/plugin version, configuration digest, generated files, execution log | Generate in an isolated branch/workspace; inspect the diff and run the service's normal checks |
| Git / CI → Test / Blueprint | Commit SHA, requirement/case IDs, tool version, run ID, environment, results, evidence hash | Import results via a tested adapter; reject evidence for a different revision and represent skipped/error distinctly from pass |
| Scriptor → UAT scenario | Recording ID/version, edited steps, SME, expected outcomes, synthetic-data reference | Review steps against the requirement; reject a scenario that replays a mistaken click or lacks an expected result |
| BrowserForge → UAT / Test | Run/session/action IDs, candidate identity, environment, assertion results, asset hashes | Import a deliberately failed run and confirm it stays failed; reject evidence for a different candidate |
| UAT → release record | Build identity, accepted workflows, tester, timestamp, unresolved issues, signoff, screenshots | Export with UATCLI; verify downloaded evidence and ensure acceptance refers to the promoted candidate |
| UAT / Scriptor / BrowserForge → Showcase | Accepted case IDs, source revisions, asset references, release ID, reviewer | Ingest one sample of each source; confirm missing assets fail the import and that raw failure evidence is preserved outside Showcase |
| Release system → Nexus | Service/environment, release ID, deployed artifact digest, health endpoint contract | Map endpoints or add an adapter; verify a degraded dependency and a malformed or missing response |
| Nexus / security → incident and tracker | Signal source, observed time, severity, service, owner, finding/risk ID, remediation link | Implement deduplication and escalation; prove repeated observations update the same open record |
| Chronos / Fiscal / Ledger → planning | Period, project/charge-code map, approved hours, rate basis, expenses, budget/commitments | Reconcile totals and late corrections; separate internal cost from billable amounts and future availability |
| SyncBridge → stakeholder reporting | Reporting-only views, external IDs, field ownership, synchronization cursor | Start one-way; replay a batch and test update/conflict handling before allowing any reverse writes |
A useful proposed integration envelope, not an existing shared API contract:
{
"schema_version": 1,
"event_id": "unique-idempotency-key",
"source": "ci-adapter",
"tenant_id": "enterprise-a",
"project_id": "PROJ-42",
"requirement_ids": ["REQ-218"],
"commit_sha": "full-reviewed-commit-sha",
"artifact_digest": "sha256:artifact-content-digest",
"environment": "staging",
"run_id": "RUN-884",
"observed_at": "2026-10-24T14:00:00Z",
"status": "passed",
"evidence_uri": "controlled-evidence-location"
}
Use versioned schemas, scoped service identities, idempotent writes, bounded retries, a failed-message queue or equivalent durable retry ledger, and a reconciliation report. A source approval that changes must invalidate or refresh downstream approval. If evidence is missing or stale, a release gate should report unknown or fail according to the agreed policy; a monitoring dashboard outage alone should not become an accidental dependency for all production traffic.
Security should be integrated throughout the lifecycle rather than added only at release. This operating model draws on the high-level approach in NIST SSDF 1.1; it is not a claim that these apps implement or certify those practices. Build evidence should identify where an artifact came from and be verified against trusted expectations; see SLSA provenance and artifact verification guidance. A file hash alone does not establish a trusted builder or approval.
Capacity and budget planning: Chronos + Vector + Fiscal + Ledger
This is an explicit enterprise use case even though timekeeping and financial applications are not primarily SDLC tools.
| App/input | Planning contribution | Keep distinct |
|---|---|---|
| Chronos | Approved effort actuals by person/team, period, project, and charge code; support load and estimate calibration | Time logged is not automatically future availability, useful output, or labor cost |
| Vector | Planned work, dependencies, sprint/team capacity and delivery analytics | Do not overwrite approved timekeeping data with planning estimates |
| Fiscal | Expenses and invoice inputs; visibility into financial effects of delivery and staffing choices | Billable rates/revenue and internal cost rates; invoice issue date and work period |
| Ledger | Budget envelopes, commitments, expected/actual expenses and reconciliation | Do not add an invoice and its already-counted commitment as two costs |
| HR / team calendar | Scheduled hours, approved leave, public holidays, part-time allocation, relevant skill coverage | LeaveOps is planning-only here; use the enterprise's existing availability source |
Illustrative planning cycle: a four-person team has 160 scheduled hours next week. Subtract 16 hours of leave, 16 hours of known non-project commitments, and a 24-hour support reserve informed by recent Chronos actuals: 104 hours available for planned feature work. Record mutually exclusive categories so support or meetings are not deducted twice. Use skill-specific availability and task dependencies before promising a delivery date; 104 interchangeable hours is not a staffing model.
If approved internal labor cost is $100/hour, that week's feature work represents $10,400 of forecast labor cost, before separately defined overhead and project expenses. These are illustrative assumptions, not rates from the repositories. Fiscal supplies relevant expenses/billing context; Ledger compares the forecast against remaining funding. Do not substitute a $150/hour billing rate and call the result internal cost.
Use one consistent financial basis: estimate-at-completion equals recognized project cost to date plus estimated remaining cost. The remaining estimate should include future commitments once, exclude commitments already settled into actuals, and disclose uncertainty. Keep a mapping of contract/task order/CLIN/charge code to delivery project, effective dates for rates, and currency. Late Chronos corrections should update forecasts with an audit trail. Pilot a read-only weekly reconciliation before automating writes.
Decision example: if support demand rises, the delivery lead can reduce sprint scope, move qualified staff, or request budget. Compare the alternatives in Vector using Chronos actuals and Fiscal/Ledger cost context; return a material funding or scope change to Genesis/Scope for approval. Avoid using hours alone as an individual productivity score.
Nexus: continuous monitoring and risk management
Treat Nexus as a directly relevant operate-and-improve tool. Its current polling implementation stores component/dependency health and metric history. Configuration includes a risk-score endpoint. Risk-weighted readiness and release enforcement are integration work to plan and test.
Continuous monitoring integration: register service/environment owners and normalize each application's health response. The poller requests /api/health with a structured status, timestamp, and component object; other apps expose different paths or shapes, so add adapters where needed. Define readiness rules explicitly, including how DEGRADED is treated, to match deployment policy. Verify HTTP error handling, response freshness, authentication, and malformed payloads before trusting the dashboard.
Risk integration: ingest findings from the actual security, testing, data-quality, and operational systems. Link every finding to service/environment, source, observed timestamp, risk owner, likelihood/impact assessment, remediation work, due date, and explicit acceptance/expiry when an exception is granted. Keep business/project risks in the authoritative risk register or tracker; Nexus provides a consolidated view and context. A healthy service can still have an unacceptable vulnerability, and a stale risk feed should not imply low risk.
Practical loop: Nexus observes a degraded dependency after release; SRE opens or updates an incident; Proof collects reproduction evidence; security or the service owner assesses exposure; Vector/the enterprise tracker records corrective work; the release process decides whether to halt promotion or roll back; Sentinel and CI verify the fix; Nexus observes recovery; the risk owner closes the finding with evidence. Plan and test alert routing, deduplication, risk scoring, and release policy integration as part of the rollout.
Start with synthetic known failures and known risk findings. Measure detection delay, stale-source count, alert noise, time to acknowledgement, overdue remediation, and reopen rate. Nexus should complement the enterprise telemetry and incident systems, not erase their authoritative records. CybAre appears in documentation/configuration but is not present in these two folders; its availability and interface must be established separately.
Foundry and Schema: standardization without unnecessary machinery
Foundry can justify its added complexity when several teams repeatedly create similar services. Have the platform team own one approved template containing the enterprise's chosen project layout, logging, health contract, configuration conventions, dependency baseline, test harness, and CI starter. Pin template/plugin versions, generate into a branch, review the diff, and run ordinary CI. The executor offers dry-run handling and keeps EXEC actions disabled unless enabled; pair these with template review and normal CI on generated code.
Pilot two representative services. Check whether they start and build consistently, whether teams can make normal changes without fighting the template, and whether a baseline update can reach both services safely. Record generated-template metadata in each repo. Define an upgrade process—regeneration with merge review, targeted update PRs, or a documented manual patch—and make deviations explicit. If maintaining templates costs more than the inconsistency they remove, retain simpler reviewed starter repositories instead.
Schema is a direct design-stage candidate. Its local source includes model/relation editing, ERD components, schema validation, and SQL/Prisma/TypeScript/Mermaid emitters. Use it with architects, developers, and data owners to agree entities, cardinalities, constraints, naming, and sensitive fields. Commit exports and the model's design rationale. Validate SQL against the target engine, then write and test versioned migrations; generated CREATE statements alone do not describe a safe upgrade for existing data. Test backwards compatibility during rolling deployments and document recovery for destructive changes.
Combined example: a company standardizes a new case-management service. Schema defines cases, assignments, decisions, and their relationships. Blueprint records acceptance and access rules. Foundry generates the approved service shell. Developers implement the reviewed model through migrations, then submit generated and handwritten changes together for code and test review.
Avoid overlapping ownership
| Overlap | Recommended boundary |
|---|---|
| Genesis, Scope, Vector, ProjectMaster, Blueprint | Genesis owns investment decisions; Scope requirement refinement; one tracker execution; Blueprint versioned engineering evidence. Use ProjectMaster templates or phase coordination only where they add value. Do not require five independent approvals of the same fact. |
| Test, Sentinel, BrowserForge, ArcoreUAT, UATCLI | Test is the inventory/result catalog; Sentinel runs API/load assurance; BrowserForge runs browser workflows and captures evidence; ArcoreUAT owns acceptance cases and human signoff; UATCLI exports from ArcoreUAT. Existing unit/E2E frameworks still execute their own tests. |
| Scriptor, Showcase, Phantom, Canon | Scriptor captures how experts work; Showcase produces reviewed training and demos; Phantom provides mock backends for early stakeholder demos; Canon holds approved product facts. None of them is the acceptance record. |
| Nexus and Proof | Nexus observes signals; Proof organizes investigation evidence. Neither replaces accountable risk acceptance or incident command. |
| Canon, Cognit, Clarify, Station, Chapterize | Separate approved product knowledge, working research, engagement findings, raw conversation artifacts, and document extraction. Promote reviewed conclusions to engineering records. |
| Flow, Meld | Select by workload: Python/agent orchestration or data-product workflow. Avoid routing every simple job through two orchestration systems. |
| Fiscal, Chronos, Ledger, enterprise ERP | Time actuals, expenses/billing, budget control, and contract context are different records. Keep contract and accounting authority in the enterprise's existing ERP. |
Pilot-to-enterprise rollout
- Choose one service and one delivery team. Agree measurable pain points, record owners, existing systems to retain, and a bounded set of requirements. Select apps using the checklist; do not deploy all Direct entries automatically.
- Establish traceability first. Use Scope/Blueprint with the existing tracker or Vector. Link a requirement through design, commit, test, acceptance, and deployed artifact. Reject a deliberately stale approval or mismatched result in the pilot.
- Add design and code standards selectively. Pilot Schema exports and one Foundry template if the team needs them. Add Narrator as review assistance with visible extraction limits. Verify generated outputs in normal CI.
- Connect assurance and release. Trial Test/Sentinel, BrowserForge runs, and ArcoreUAT exports against staging; validate auth failures, tool errors, skipped tests, duplicate imports, and rollback. Use Parkour only after the required runner and environment paths work end to end. If the release needs user training, validate one Scriptor/BrowserForge/UAT → Showcase import before relying on it.
- Close the operations and planning loops. Connect Nexus to health and risk sources, rehearse an incident into Proof/tracked remediation, and reconcile one planning period of Chronos/Fiscal/Ledger inputs against authoritative records.
- Expand only after ownership and operations work. Assign support/upgrade owners, restore procedures, identity/offboarding behavior, dependency/license review, and operating cost. Roll out by service type and retire duplicate stores. Keep a manual export/review fallback if an integration is unavailable.
Suggested pilot acceptance: one complete traceability chain; no duplicate target records after replay; visible unknown/error states; reconciliation totals match source records; failed dependencies and stale signals are detected; approval cannot silently attach to a different revision; restore/rollback is demonstrated; trained users can complete their workflow from the published guide without author coaching; and users can complete their workflow without maintaining duplicate status records.
Existing enterprise tooling must still cover secure source control, identity, secrets, artifact storage, dependency/container/security analysis, vulnerability response, backup/restore, and incident paging unless a selected replacement passes its acceptance tests. Specialized requirements such as legal retention or regulated approvals need organization-specific review; repository marketing labels are not evidence of certification.
Selected small utilities: practical starting points
Choose only the tools that address the pilot's actual gaps. The full utility appendix includes the rest, including edge and N/A entries.
| Utility | Intended integration / realistic example | Limitation to preserve |
|---|---|---|
| pr-citation-linter | Validate that a PR describes its issue, requirement, test evidence, and review context | Text/pattern presence does not verify cited evidence is correct |
| test-command-discoverer | Help onboard a repo by reporting candidate test commands | It deliberately does not execute those commands |
| requirements-invest-linter | Screen story wording before requirements review | A linter cannot establish real business value or feasibility |
| health-endpoint-contract-kit | Develop consistent service-health fixtures for monitoring integration | Compare its schema with Nexus; compatible naming alone is insufficient |
| database-migration-drift-snapshot | Review migration-state evidence before rollout | Snapshot comparison is not an automatic repair or safe migration plan |
| browser-screenshot-diff | Review visual regression evidence for a UI release | Visual similarity does not establish functional or accessibility acceptance |
| risk-register-question-prompts | Structure a release or planning risk discussion | Prompts do not decide risk acceptance or replace a maintained risk record |
| budget-variance-explainer | Prepare a human review of delivery forecast versus budget | Reconcile inputs and calculation basis before using the explanation |
Application-by-application integration profiles
Every scenario below is an illustrative real-world situation, not a claim of an actual customer deployment. Integration steps are recommendations and require validation in the intended environment.
Profile index
- Direct (24): ArcoreAgent · ArcoreBlueprint · ArcoreBrowserForge · ArcoreClarify · ArcoreDataControl · ArcoreFlow · ArcoreFoundry · ArcoreGenesis · ArcoreMeld · ArcoreNarrator · ArcoreNexus · ArcoreOverwatch · ArcoreProof · ArcoreSchema · ArcoreScope · ArcoreScriptor · ArcoreSentinel · ArcoreShowcase · ArcoreTest · ArcoreUATCLI · ArcoreVector · ArcorParkour · ProjectMaster · ThatWeeklyPublicRepo
- edge (13): ArcoreCanon · ArcoreChronos · ArcoreCognit · ArcoreFiscal · ArcoreLeaveOps · ArcoreLedger · ArcorePhantom · ArcoreStation · ArcoreSyncBridge · Arecore · Chapterize · OpenHands · sso-onboarding
ArcorParkour — Direct
Purpose and SDLC role: Pipeline definitions, runs, environments, and deployment orchestration. Manages/supports: Build; test; release; deploy.
How to integrate: Pilot against a staging service; ingest test results and promote the same immutable artifact through environments with an independent release decision.
Practical use case: A retail team builds a checkout fix, runs regression checks, and promotes the reviewed image during its release window.
Adoption boundary: Validate connectors and failure paths for each target environment before relying on quality gates; the folder spelling is ArcorParkour. Review classification: Source present; runtime unvalidated.
ArcoreAgent — Direct
Purpose and SDLC role: Catalog of AI capabilities, providers, consumers, interfaces, and dependency relationships. Manages/supports: Architecture; AI governance; maintenance.
How to integrate: Version the capability catalog in Git; review provider and prompt dependencies during design and change impact assessment.
Practical use case: Before replacing an embedding provider, an architect identifies all applications depending on that capability.
Adoption boundary: Catalog/library, not an agent execution engine; refresh results are static evidence, not deployed availability. Review classification: Source present; runtime unvalidated.
ArcoreBlueprint — Direct
Purpose and SDLC role: Structured specifications, requirement-to-code/test links, proposals, revision-aware approvals, and evidence checks. Manages/supports: Requirements; design; review; verification.
How to integrate: Store specifications with code; run lint and evidence checks in CI; allow acceptance commands only from reviewed configuration; bind approval to the reviewed revision.
Practical use case: An insurer changes an eligibility rule and requires the requirement, ADR, tests, and approval to refer to the same revision.
Adoption boundary: CLI/MCP reads and verification execution are separate capabilities; keep acceptance commands in reviewed configuration. Review classification: Source present; runtime unvalidated.
ArcoreCanon — edge
Purpose and SDLC role: Governed product and go-to-market knowledge with relationship graphs and review workflows. Manages/supports: Knowledge governance; release communications.
How to integrate: Publish approved product facts and support content from release evidence; link back to authoritative specifications.
Practical use case: Support and sales consume a reviewed description of a newly released reporting capability.
Adoption boundary: Primarily product/content governance; it should not become a second engineering requirements system. Review classification: Source present; runtime unvalidated.
ArcoreClarify — Direct
Purpose and SDLC role: Consulting engagement workflow with evidence analysis, findings, design actions, and phase exports. Manages/supports: Discovery; problem analysis; design; handoff.
How to integrate: Use engagement findings as discovery evidence; manually review and export accepted actions into Scope and Blueprint.
Practical use case: A modernization team diagnoses a slow approval process and turns supported findings into explicit workflow requirements.
Adoption boundary: Implements both engagement phases and knowledge search; confirm the workflow and approval steps a given engagement needs. Review classification: Source present; runtime unvalidated.
ArcoreCognit — edge
Purpose and SDLC role: Research library, PDF artifacts, bibliography/writing tools, and structured knowledge primitives. Manages/supports: Research; architecture knowledge.
How to integrate: Use as an architect's research workspace; promote reviewed conclusions into versioned ADRs rather than treating working notes as approval.
Practical use case: An architect compares database approaches and preserves source citations for the final decision.
Adoption boundary: Supports research well beyond note-taking; research notes are not release evidence by themselves. Review classification: Source present; runtime unvalidated.
ArcoreDataControl — Direct
Purpose and SDLC role: Tableau artifact inventory, normalization, baselines, drift, and controlled change/promotion workflows. Manages/supports: BI design; configuration management; test; release; operations.
How to integrate: For Tableau products, version workbook/data-source baselines; inspect drift and lint results before a reviewed promotion; rehearse restore.
Practical use case: An analytics team detects an unreviewed production workbook edit before promoting the next dashboard release.
Adoption boundary: Specialized to Tableau SDLC; validate each promotion and rollback path against a sandbox site. Review classification: Source present; runtime unvalidated.
ArcoreFlow — Direct
Purpose and SDLC role: Visual graph authoring and compilation/orchestration for Python and agent workloads. Manages/supports: Workflow design; implementation; execution; operations.
How to integrate: Version workflow definitions with code; validate graphs and execute isolated test runs; send run identifiers and failure evidence to delivery tracking.
Practical use case: A team builds a document-classification workflow with a human review step and tests its error paths before release.
Adoption boundary: Adds an execution control plane; use only when workflow orchestration is part of the product and verify implemented nodes. Review classification: Source present; runtime unvalidated.
ArcoreLedger — edge
Purpose and SDLC role: Budget envelopes, commitments, expected expenses, actual expenses, and reconciliation. Manages/supports: Portfolio budget; delivery cost control.
How to integrate: Map delivery projects and charge codes to budget envelopes; compare approved budgets, commitments, actuals, and estimated remaining work.
Practical use case: A program manager spots that committed vendor spend leaves too little budget for the remaining release scope.
Adoption boundary: Financial control is adjacent to SDLC; do not count commitments and the invoices settling them twice. Review classification: Source present; runtime unvalidated.
ArcorePhantom — edge
Purpose and SDLC role: Traffic-to-blueprint compilation and browser-side mock/demo generation. Manages/supports: Prototype; stakeholder validation; demonstrations.
How to integrate: Generate sanitized, versioned demo scenarios from a test environment; collect feedback into Scope; keep live integration tests separate.
Practical use case: A product owner demonstrates an approval journey to users without exposing a production backend.
Adoption boundary: Mock behavior cannot establish production correctness; review captured payloads before redistribution. Review classification: Source present; runtime unvalidated.
ArcoreProof — Direct
Purpose and SDLC role: Investigation engagements connecting symptoms, hypotheses, tests, evidence, findings, and reports. Manages/supports: Incident investigation; defect analysis; continuous improvement.
How to integrate: Open an investigation for a significant incident; preserve release/run IDs with evidence; convert supported findings into tracked corrective work.
Practical use case: An intermittent payment failure is investigated using logs, reproduction tests, evidence hashes, and a remediation report.
Adoption boundary: Hash verification is implemented, but storage retention and immutability are separate deployment controls; do not equate it with an attestation service. Review classification: Source present; runtime unvalidated.
ArcoreStation — edge
Purpose and SDLC role: Transcript ingestion, artifact extraction, search, provenance, and structured exports. Manages/supports: Discovery; engineering knowledge; handoff.
How to integrate: Capture approved engineering conversations; export reviewed decisions and code into the owning repository with provenance.
Practical use case: A team recovers the rationale and sample code from an architecture discussion and turns them into a reviewed ADR and PR.
Adoption boundary: Conversation output is draft material; redact secrets and avoid making chat history authoritative implementation evidence. Review classification: Source present; runtime unvalidated.
ArcoreSyncBridge — edge
Purpose and SDLC role: PostgreSQL to SharePoint/Teams-list synchronization with mapping and run tracking. Manages/supports: Stakeholder reporting; integration operations.
How to integrate: Publish a controlled reporting projection of delivery data; define field ownership and replay/conflict behavior before enabling reverse writes.
Practical use case: Executives see release milestones and risk owners in SharePoint while the engineering tracker retains authoritative status.
Adoption boundary: Synchronize purpose-built reporting views rather than core application tables, and start one-way. Review classification: Source present; runtime unvalidated.
ArcoreTest — Direct
Purpose and SDLC role: Test scenarios, cases, runs/results inventory, REST administration, and source/database discovery. Manages/supports: Test planning; inventory; results management.
How to integrate: Assign stable requirement and case IDs; import reviewed automation results with commit, environment, and run references.
Practical use case: QA identifies requirements without test cases and assembles a release coverage record.
Adoption boundary: Inventory management is distinct from executing tests; include database initialization in setup. Review classification: Source present; runtime unvalidated.
ArcoreUATCLI — Direct
Purpose and SDLC role: Client bundle for UAT exports, evidence downloads, documentation scaffolds, and process journals. Manages/supports: Acceptance testing; user documentation; release evidence.
How to integrate: Use the external UAT service for durable acceptance records; export evidence into the release package and link business signoff to a build.
Practical use case: Business users validate invoice approval and export screenshots and findings for the release review.
Adoption boundary: This checkout is a client, not the ArcoreUAT server. ArcoreUAT is profiled in the expanded review and BrowserForge in the supplemental review. Review classification: Setup/client only.
Arecore — edge
Purpose and SDLC role: Application platform with roles/permissions, users, and document-engine services. Manages/supports: Platform foundation; access governance; documentation.
How to integrate: Reuse only explicitly validated modules; map enterprise identity and roles per application and exercise deny paths.
Practical use case: A team implements a shared permission model for internal applications and exposes approved technical documentation.
Adoption boundary: Provides application-level RBAC; map enterprise SSO, tenancy, and authorization for each consuming application. Review classification: Source present; runtime unvalidated.
Chapterize — edge
Purpose and SDLC role: PDF chapter extraction with structured text/HTML and document review workflows. Manages/supports: Requirements discovery; documentation ingestion.
How to integrate: Extract sections from approved source documents, retain page references, and have an analyst verify requirements before import.
Practical use case: A team working from a large procurement specification extracts sections for requirements review.
Adoption boundary: Extraction is not semantic acceptance or requirements approval; diagrams and tables need fidelity checks. Review classification: Source present; runtime unvalidated.
OpenHands — edge
Purpose and SDLC role: Local OpenHands deployment/troubleshooting setup for coding assistance. Manages/supports: Implementation assistance.
How to integrate: If adopted, run in a restricted workspace and require ordinary PR review and CI for generated changes.
Practical use case: A developer asks a configured agent to draft a small refactor and then reviews its diff and test results.
Adoption boundary: A deployment and configuration setup for OpenHands rather than its source; confirm model-provider connectivity in the target environment. Review classification: Setup/client only.
sso-onboarding — edge
Purpose and SDLC role: Console for app inventory and Google, Microsoft, and self-hosted OIDC onboarding configuration. Manages/supports: Platform onboarding; identity configuration.
How to integrate: Use to prepare identity configuration; validate callbacks, tenant/role mapping, session expiry, and access removal in each consuming application.
Practical use case: Platform engineers register a new internal app with the enterprise identity provider.
Adoption boundary: Prepares identity configuration; each consuming application still enforces its own SSO and authorization. Review classification: Source present; runtime unvalidated.
ArcoreChronos — edge
Purpose and SDLC role: Timesheets, charge codes, contract/task-order allocation, approvals, and correction audit trails. Manages/supports: Capacity planning; effort actuals; delivery forecasting.
How to integrate: Export approved hours by project, team, period, and charge code into capacity planning; compare actual effort with Vector estimates and combine with available-hours calendars.
Practical use case: A team discovers support work consumes 25% of weekly hours and reduces the next sprint's planned feature load.
Adoption boundary: Primarily timekeeping; historical hours inform capacity but do not supply future availability, skills, leave, or staffing optimization by themselves. Review classification: Source present; runtime unvalidated.
ArcoreFiscal — edge
Purpose and SDLC role: Expense management and invoice preparation using labor, expenses, and contract/rate information. Manages/supports: Delivery budget planning; cost forecasts; billing.
How to integrate: Reconcile approved Chronos hours and expense records; feed project-level cost/billing actuals into Ledger and planning reports; use approved cost rates for internal forecasts.
Practical use case: A delivery manager compares staffing options for the next milestone against remaining budget and expected travel expense.
Adoption boundary: Useful for capacity/budget decisions, but not a staffing scheduler; billed revenue, labor cost, invoice timing, and cash flow must remain distinct. Review classification: Source present; runtime unvalidated.
ArcoreFoundry — Direct
Purpose and SDLC role: Code-generation platform with templates/plugins, transactional virtual filesystem, and dependency-ordered actions. Manages/supports: Architecture standards; scaffolding; implementation.
How to integrate: Have the platform team own versioned enterprise templates for project layout, logging, health endpoints, configuration, tests, and CI starters. Preview generated diffs in an isolated workspace, open a PR, and run normal CI; maintain an explicit upgrade and exception process.
Practical use case: Three product teams launch customer, billing, and case-management APIs from an approved service template. Developers can move between repositories with familiar layouts and checks; when the baseline changes, the platform team proposes reviewed update PRs for each service.
Adoption boundary: Optional adoption: template/plugin maintenance, developer training, and upgrades add complexity. Pilot two services and compare setup time, deviations, and upgrade effort. Generation establishes a baseline; ongoing conformance needs CI checks and review. EXEC actions require separate control. Review classification: Source present; runtime unvalidated.
ArcoreGenesis — Direct
Purpose and SDLC role: System requests, business cases, feasibility analysis, and approval decisions. Manages/supports: Intake; feasibility; portfolio approval.
How to integrate: Capture the business case and accountable sponsor; pass an approved project ID and bounded scope to requirements and planning tools.
Practical use case: A bank compares a reconciliation service against a manual process before committing a delivery team.
Adoption boundary: Approval states and models are present; validate the handoff into planning tools and the organization's business rules during the pilot. Review classification: Source present; runtime unvalidated.
ArcoreLeaveOps — edge
Purpose and SDLC role: Planned leave-management engine and enterprise HR integration design. Manages/supports: Capacity availability input.
How to integrate: Use an existing HR absence feed now; consider this project's future availability export only after implementation.
Practical use case: A planner would subtract approved absences from team capacity without exposing medical details to engineering tools.
Adoption boundary: Planning documents only; do not treat intended eligibility, privacy, or payroll features as delivered. Review classification: Planning only.
ArcoreMeld — Direct
Purpose and SDLC role: Visual data workflow, preview, gateway, and compilation/control-plane implementation. Manages/supports: Data-product design; development; test; operations.
How to integrate: For data products, version workflows and generated artifacts, validate sample outputs, and promote reviewed definitions through environments.
Practical use case: An analytics team reviews a transformation graph and its generated output before updating a revenue dataset.
Adoption boundary: Broad platform scope; evaluate the specific connector, compiler, and runtime path a data product needs. Review classification: Source present; runtime unvalidated.
ArcoreNarrator — Direct
Purpose and SDLC role: Code analysis with revision, symbol/index, evidence, and narrative-oriented review structures. Manages/supports: Code understanding; review; change impact.
How to integrate: Analyze a pinned revision; attach source-linked findings and extraction coverage to a PR; retain a human reviewer for acceptance.
Practical use case: A reviewer traces a claimed authorization change back to code evidence and notices a route missing from analysis.
Adoption boundary: Review AI interpretation and extraction coverage alongside the source-linked findings. Review classification: Source present; runtime unvalidated.
ArcoreNexus — Direct
Purpose and SDLC role: Component and dependency health polling, metric history, aggregated status, and ecosystem context. Manages/supports: Continuous monitoring; operational risk; improvement.
How to integrate: Normalize health responses, ingest validated risk metrics, preserve freshness, and route actionable findings to incident/remediation records with service owners.
Practical use case: After a release, a dependency degrades while a security risk remains open; operators correlate the signals and prioritize a rollback investigation and remediation.
Adoption boundary: Health polling and metric history are the core capability; plan risk-weighted gating and alert routing as integration work. Review classification: Source present; runtime unvalidated.
ArcoreOverwatch — Direct
Purpose and SDLC role: Planning discussion for Jira-backed or custom work/bug tracking. Manages/supports: Work/defect tracking concept.
How to integrate: Keep the existing enterprise issue tracker; revisit only if a concrete workflow gap justifies building and testing an adapter.
Practical use case: A future facade could connect an incident to a bug and release target in the enterprise tracker.
Adoption boundary: Concept stage; keep the existing enterprise tracker in the meantime. Review classification: Planning only.
ArcoreSchema — Direct
Purpose and SDLC role: Schema/model editing, relationships, ERD visualization, validation, and SQL/Prisma/TypeScript/Mermaid generation. Manages/supports: Data modeling; schema design; design review.
How to integrate: Review models and constraints; version exports with ADRs; translate approved differences into tested migration scripts in the owning repo.
Practical use case: A team models customers, orders, and invoices, reviews cardinality, and exports a consistent schema before API implementation.
Adoption boundary: DDL generation is a design output; write and test versioned migrations, compatibility, and rollback separately. Review classification: Source present; runtime unvalidated.
ArcoreScope — Direct
Purpose and SDLC role: Structured requirements, quality/prioritization, technical breakdown, and outbound integration job tracking. Manages/supports: Requirements refinement; prioritization; backlog handoff.
How to integrate: Refine approved needs into testable acceptance criteria; map requirement IDs to Blueprint specs and the chosen execution tracker; reconcile failed handoffs.
Practical use case: An ambiguous export request becomes a prioritized story with permission, format, and performance acceptance criteria.
Adoption boundary: Durable integration-job code exists, but every target mapping and retry behavior must be exercised before automatic backlog publication. Review classification: Source present; runtime unvalidated.
ArcoreSentinel — Direct
Purpose and SDLC role: Application assurance service with test definitions, execution-oriented API/UI, saved views, and reporting. Manages/supports: Integration testing; load/performance; runtime assurance.
How to integrate: Run agreed API, database, and WebSocket checks against staging; attach structured results and environment/build IDs to ArcoreTest and the release decision.
Practical use case: A team validates that a new checkout release meets its latency target under representative concurrent traffic.
Adoption boundary: Validate the exact test executor and thresholds before using results as release gates; it does not replace unit tests or independent security scanning. Review classification: Source present; runtime unvalidated.
ArcoreVector — Direct
Purpose and SDLC role: Hybrid Agile/Waterfall work items, sprints, dependencies, timelines, analytics, and capacity endpoints. Manages/supports: Execution planning; capacity; delivery tracking.
How to integrate: Use as the execution system only if replacing or complementing the existing tracker is justified; import requirement references and approved effort/availability inputs.
Practical use case: A program tracks sprint work alongside contractual milestones and reduces planned load when support actuals exceed assumptions.
Adoption boundary: Pick one authoritative owner for tasks/status; existing capacity endpoints do not prove automatic Chronos/Fiscal connectivity. Review classification: Source present; runtime unvalidated.
ProjectMaster — Direct
Purpose and SDLC role: Idea-to-solution SOP/templates plus project, phase, artifact, and gate services. Manages/supports: Lifecycle phases; design gates; artifact templates.
How to integrate: Adopt its templates selectively and link phase artifacts to Blueprint; choose a single owner for gate decisions to avoid competing workflows.
Practical use case: A new service must have a researched problem statement and data model before implementation begins.
Adoption boundary: Use phase gates as workflow guidance with explicitly configured required checks; enforce release gates in the release system. Review classification: Source present; runtime unvalidated.
ThatWeeklyPublicRepo — Direct
Purpose and SDLC role: Small local CLIs, components, templates, validators, and report generators across 33 categories. Manages/supports: Cross-lifecycle utility collection.
How to integrate: Select individual tools for a documented gap, pin revisions, run fixture tests, and adapt their output/exit semantics in CI; use the utility appendix for individual fit.
Practical use case: A team adds PR citation checking, screenshot comparison, and change-window evidence without adopting another platform.
Adoption boundary: A collection, not one deployed service; fixture-test each tool before adopting it. Review classification: Source present; runtime unvalidated.
Supplemental review: UAT, documentation, demos, and training
The following three apps live in the Projects/ folder, outside the original two-folder scope, and were added to cover UAT evidence, documentation, and training. Documentation and selected source were inspected; applications and cross-app integrations were not executed. See the case-study training workflow for the operating model, detailed scenario, release gates, and versioned handoffs.
ArcoreScriptor — Direct
Purpose and SDLC role: Browser-extension workflow recording, screenshot annotation, step editing, and HTML/PDF documentation export. Manages/supports: UAT preparation; workflow documentation; user training.
How to integrate: Record subject-matter-expert workflows with synthetic data; review steps and expected outcomes, then import selected recordings into Showcase after validating the adapter contract.
Practical use case: A branch coordinator records how to handle an unavailable part; QA derives an acceptance scenario and the training lead develops a reviewed quick-start guide.
Adoption boundary: Recording an action does not prove the business outcome. Validate export and Showcase compatibility, review screenshots and transcripts, and version training material against the application release. Review classification: Source inspected; runtime and cross-app integration unvalidated.
ArcoreBrowserForge — Direct
Purpose and SDLC role: Playwright run service and live browser sessions with assertions, action timelines, screenshots, traces, videos, and interaction capture. Manages/supports: Browser verification; UAT evidence; documentation/demo capture.
How to integrate: Execute approved workflows against a controlled candidate environment; preserve assertions and complete run evidence, then pass selected artifacts to Showcase. Link runs to requirements and artifact identity.
Practical use case: QA repeats a commitment workflow, asserts the blocked state when a part is unavailable, and captures highlighted evidence for acceptance and a support walkthrough.
Adoption boundary: Browser evidence complements API and authoritative-state checks; screenshots alone do not prove reservations. Configure artifact access and retention, and validate adapter behavior, before relying on the service. Review classification: Source inspected; runtime and cross-app integration unvalidated.
ArcoreShowcase — Direct
Purpose and SDLC role: Ingests UAT cases, Scriptor recordings, and BrowserForge sessions to produce structured guides, narrated videos, and replayable demos. Manages/supports: Acceptance support; release documentation; demos; user training.
How to integrate: Validate ingestion and required assets; review expected-result checks and narration; publish role-specific documentation and demos tied to the accepted release. Use ArcoreVox narration only after voice-service validation.
Practical use case: A training lead turns accepted coordinator, supervisor, and support workflows into a quick-start guide, an exception-handling demo, and an UNKNOWN-state recovery lesson.
Adoption boundary: Ingestion adapters exist for UAT, Scriptor, and BrowserForge; validate each with a sample import. Preserve original UAT evidence separately; demo imports are teaching material, not test reports. Human approval and release-freshness checks remain required. Review classification: Source inspected; runtime and cross-app integration unvalidated.