Compare commits
27
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
794f2aa2d6 | ||
|
|
7f40de708c | ||
|
|
d3b9f7af14 | ||
|
|
577117e19c | ||
|
|
237c6767ab | ||
|
|
f1743156b6 | ||
|
|
14ba1aa1ef | ||
|
|
d760c14dab | ||
|
|
db427f99da | ||
|
|
033d9bf8fd | ||
|
|
353a04588c | ||
|
|
01e2b4df39 | ||
|
|
5bc1263be0 | ||
|
|
ecc234234e | ||
|
|
59b4075113 | ||
|
|
6e1503d31b | ||
|
|
ea2d1e889b | ||
|
|
6b487643b3 | ||
|
|
f004e14f36 | ||
|
|
c2665624e3 | ||
|
|
0af096a285 | ||
|
|
70ffea0e16 | ||
|
|
b3e3594571 | ||
|
|
b1e3cda244 | ||
|
|
7fa50f4ed8 | ||
|
|
4f4d808bdc | ||
|
|
68f34b6a92 |
No files matched your search
@@ -27,7 +27,7 @@ After publication, verify the exact commit’s Actions task and deployed page bo
|
|||||||
|
|
||||||
## Sections and diagrams
|
## Sections and diagrams
|
||||||
|
|
||||||
Top-level sections are Organization, Strategy, and Contribution, each with an independent sidebar. The first Organization page is Structure and contains an explicitly illustrative organization chart, not confirmed Eldorado reporting lines.
|
Top-level sections are Organization, Strategy, and Contribution, each with an independent sidebar. The first Organization page is Structure. It presents the organizational operating model: leadership, departments, teams, responsibilities and cross-functional delivery. Research and source excerpts remain under `research/organization/`, outside the published documentation.
|
||||||
|
|
||||||
Archify 3.0.1 is vendored under `vendor/archify/` from commit `d5a1333d7447c866a765adac7d4d062f2f02e4d2`. MIT and third-party notices are preserved. `diagrams/` holds editable JSON; `pnpm diagrams:build` validates and generates local standalone viewers before every site build. The iframe is sandboxed without same-origin permission. See `docs/contribution/diagrams.md` for capability analysis, authoring, boundaries, and upgrade procedure.
|
Archify 3.0.1 is vendored under `vendor/archify/` from commit `d5a1333d7447c866a765adac7d4d062f2f02e4d2`. MIT and third-party notices are preserved. `diagrams/` holds editable JSON; `pnpm diagrams:build` validates and generates local standalone viewers before every site build. The iframe is sandboxed without same-origin permission. See `docs/contribution/diagrams.md` for capability analysis, authoring, boundaries, and upgrade procedure.
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,39 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {"title": "TO-BE: governed AI adoption", "output": "static/diagrams/ai-adoption-target/index.html", "quality_profile": "showcase"},
|
||||||
|
"components": [
|
||||||
|
{"id":"people","type":"external","label":"Accountable people","sublabel":"Existing teams; approved work","pos":[40,80],"size":[240,80]},
|
||||||
|
{"id":"coordinator","type":"backend","label":"One SDLC coordinator","sublabel":"Data & AI; durable task ledger","pos":[440,80],"size":[240,80]},
|
||||||
|
{"id":"registry","type":"database","label":"Governed skills registry","sublabel":"Pinned bundles + qualified adapters","pos":[840,80],"size":[260,80]},
|
||||||
|
{"id":"provider","type":"cloud","label":"Model providers","sublabel":"Approved data + retention terms","pos":[40,340],"size":[240,80]},
|
||||||
|
{"id":"clients","type":"frontend","label":"Local laptop contributors","sublabel":"Copilot / Claude Code / Cline","pos":[440,340],"size":[240,80]},
|
||||||
|
{"id":"gates","type":"security","label":"Repository + CI gates","sublabel":"Independent exact-revision checks","pos":[440,600],"size":[240,80]},
|
||||||
|
{"id":"approval","type":"external","label":"Human release approval","sublabel":"Exact artifact; scoped; expires","pos":[840,600],"size":[260,80]},
|
||||||
|
{"id":"release","type":"security","label":"Release service","sublabel":"Production credentials only here","pos":[840,860],"size":[260,80]},
|
||||||
|
{"id":"audit","type":"database","label":"Audit + measurement","sublabel":"Restricted evidence; feedback","pos":[40,860],"size":[240,80]}
|
||||||
|
],
|
||||||
|
"boundaries": [
|
||||||
|
{"kind":"security-group","label":"Supply-chain review","wraps":["registry"]},
|
||||||
|
{"kind":"security-group","label":"Data / egress boundary","wraps":["provider"]},
|
||||||
|
{"kind":"security-group","label":"Untrusted local proposals","wraps":["clients"]},
|
||||||
|
{"kind":"security-group","label":"Independent delivery authority","wraps":["gates","approval","release"]}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{"id":"approved-work","from":"people","to":"coordinator","label":"Authorize scope","variant":"security"},
|
||||||
|
{"id":"coord-skills","from":"registry","to":"coordinator","label":"Pinned skills"},
|
||||||
|
{"id":"task-proposals","from":"coordinator","to":"clients","label":"Route tasks","variant":"dashed"},
|
||||||
|
{"id":"local-skills","from":"registry","to":"clients","label":"Qualified bundle","fromSide":"bottom","toSide":"right"},
|
||||||
|
{"id":"inference","from":"clients","to":"provider","label":"Allowed data","variant":"security"},
|
||||||
|
{"id":"proposals","from":"clients","to":"gates","label":"Propose changes","variant":"dashed"},
|
||||||
|
{"id":"evidence","from":"gates","to":"approval","label":"Verified evidence"},
|
||||||
|
{"id":"authorize","from":"approval","to":"release","label":"Approve artifact","variant":"security"},
|
||||||
|
{"id":"outcomes","from":"release","to":"audit","label":"Outcome evidence"},
|
||||||
|
{"id":"feedback","from":"audit","to":"people","label":"Review outcomes","variant":"dashed"}
|
||||||
|
],
|
||||||
|
"cards": [
|
||||||
|
{"dot":"cyan","title":"Target, not deployed","items":["One logical coordinating function; resilient ledger and human takeover.","Registry content is guidance, not authority. No laptop or coordinator production credentials."]},
|
||||||
|
{"dot":"rose","title":"Human authority","items":["Department leaders retain accountability; independent reviewers accept actual artifacts.","CI and release controls fail closed; approval is bound to the exact revision."]},
|
||||||
|
{"dot":"emerald","title":"Evidence loop","items":["Audit feedback informs people and the next authorized coordinator task.","Approved provider routing applies to coordinator and local inference; no silent policy-changing fallback."]}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,230 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "Eldorado leadership and delivery structure",
|
||||||
|
"output": "static/diagrams/organization-reporting/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"entries": {
|
||||||
|
"backend": {
|
||||||
|
"label": "Leadership / department"
|
||||||
|
},
|
||||||
|
"frontend": {
|
||||||
|
"label": "Role / delivery team"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "cto",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "CTO",
|
||||||
|
"sublabel": "Technology direction",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
40
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "head-engineering",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Head of Engineering",
|
||||||
|
"sublabel": "Engineering leadership",
|
||||||
|
"pos": [
|
||||||
|
400,
|
||||||
|
40
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "group-em",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Group Eng. Manager",
|
||||||
|
"sublabel": "Engineering group leadership",
|
||||||
|
"pos": [
|
||||||
|
760,
|
||||||
|
40
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "em",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Engineering Manager",
|
||||||
|
"sublabel": "Team leadership and delivery",
|
||||||
|
"pos": [
|
||||||
|
1120,
|
||||||
|
40
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "engineers",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Software engineers",
|
||||||
|
"sublabel": "Product Engineering team",
|
||||||
|
"pos": [
|
||||||
|
1480,
|
||||||
|
40
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "ai-architect",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "AI Architect",
|
||||||
|
"sublabel": "AI enablement across engineering",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coo",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "COO",
|
||||||
|
"sublabel": "Lukas Deksnys",
|
||||||
|
"pos": [
|
||||||
|
400,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "ops-qa",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "QA Specialist (Ops)",
|
||||||
|
"sublabel": "Independent operational quality",
|
||||||
|
"pos": [
|
||||||
|
760,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "cmo",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "CMO",
|
||||||
|
"sublabel": "Marketing leadership",
|
||||||
|
"pos": [
|
||||||
|
1120,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "brand-lead",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Brand Team Lead",
|
||||||
|
"sublabel": "Brand and community",
|
||||||
|
"pos": [
|
||||||
|
1480,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
240,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "cto-head-engineering",
|
||||||
|
"from": "cto",
|
||||||
|
"to": "head-engineering",
|
||||||
|
"label": "Leads",
|
||||||
|
"variant": "default"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "head-engineering-group-em",
|
||||||
|
"from": "head-engineering",
|
||||||
|
"to": "group-em",
|
||||||
|
"label": "Leads",
|
||||||
|
"variant": "default"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "group-em-em",
|
||||||
|
"from": "group-em",
|
||||||
|
"to": "em",
|
||||||
|
"label": "Leads",
|
||||||
|
"variant": "default"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "em-engineers",
|
||||||
|
"from": "em",
|
||||||
|
"to": "engineers",
|
||||||
|
"label": "Leads",
|
||||||
|
"variant": "default"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "cto-ai-architect",
|
||||||
|
"from": "cto",
|
||||||
|
"to": "ai-architect",
|
||||||
|
"label": "Leads",
|
||||||
|
"variant": "default"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coo-ops-qa",
|
||||||
|
"from": "coo",
|
||||||
|
"to": "ops-qa",
|
||||||
|
"label": "Leads",
|
||||||
|
"variant": "default"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "cmo-brand-lead",
|
||||||
|
"from": "cmo",
|
||||||
|
"to": "brand-lead",
|
||||||
|
"label": "Leads",
|
||||||
|
"variant": "default"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"cards": [
|
||||||
|
{
|
||||||
|
"dot": "cyan",
|
||||||
|
"title": "Leadership and delivery",
|
||||||
|
"items": [
|
||||||
|
"Arrows run from leader to role or team.",
|
||||||
|
"Functional leaders develop people, standards and delivery capability."
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"dot": "amber",
|
||||||
|
"title": "Interdepartmental collaboration",
|
||||||
|
"items": [
|
||||||
|
"Product Owners, Designers and Tech Leads align on product outcomes.",
|
||||||
|
"Data & AI enables AI adoption across Technology."
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -2,22 +2,32 @@
|
|||||||
"schema_version": 1,
|
"schema_version": 1,
|
||||||
"diagram_type": "architecture",
|
"diagram_type": "architecture",
|
||||||
"meta": {
|
"meta": {
|
||||||
"title": "Illustrative organization structure",
|
"title": "Eldorado organization structure",
|
||||||
"output": "static/diagrams/organization-structure/index.html",
|
"output": "static/diagrams/organization-structure/index.html",
|
||||||
"quality_profile": "showcase"
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"entries": {
|
||||||
|
"backend": {
|
||||||
|
"label": "Leadership / department"
|
||||||
|
},
|
||||||
|
"frontend": {
|
||||||
|
"label": "Role / delivery team"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
},
|
},
|
||||||
"components": [
|
"components": [
|
||||||
{
|
{
|
||||||
"id": "leadership",
|
"id": "management",
|
||||||
"type": "backend",
|
"type": "backend",
|
||||||
"label": "Example leadership",
|
"label": "Management",
|
||||||
"sublabel": "Illustrative only",
|
"sublabel": "CEO / COO",
|
||||||
"pos": [
|
"pos": [
|
||||||
320,
|
820,
|
||||||
40
|
40
|
||||||
],
|
],
|
||||||
"size": [
|
"size": [
|
||||||
200,
|
320,
|
||||||
80
|
80
|
||||||
]
|
]
|
||||||
},
|
},
|
||||||
@@ -25,27 +35,27 @@
|
|||||||
"id": "product",
|
"id": "product",
|
||||||
"type": "backend",
|
"type": "backend",
|
||||||
"label": "Product",
|
"label": "Product",
|
||||||
"sublabel": "Example function",
|
"sublabel": "Experience and product outcomes",
|
||||||
"pos": [
|
"pos": [
|
||||||
40,
|
40,
|
||||||
260
|
280
|
||||||
],
|
],
|
||||||
"size": [
|
"size": [
|
||||||
200,
|
280,
|
||||||
80
|
80
|
||||||
]
|
]
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"id": "engineering",
|
"id": "technology",
|
||||||
"type": "backend",
|
"type": "backend",
|
||||||
"label": "Engineering",
|
"label": "Technology",
|
||||||
"sublabel": "Example function",
|
"sublabel": "Engineering and platform",
|
||||||
"pos": [
|
"pos": [
|
||||||
320,
|
360,
|
||||||
260
|
280
|
||||||
],
|
],
|
||||||
"size": [
|
"size": [
|
||||||
200,
|
280,
|
||||||
80
|
80
|
||||||
]
|
]
|
||||||
},
|
},
|
||||||
@@ -53,41 +63,409 @@
|
|||||||
"id": "operations",
|
"id": "operations",
|
||||||
"type": "backend",
|
"type": "backend",
|
||||||
"label": "Operations",
|
"label": "Operations",
|
||||||
"sublabel": "Example function",
|
"sublabel": "Service, resolution and trust",
|
||||||
"pos": [
|
"pos": [
|
||||||
600,
|
680,
|
||||||
260
|
280
|
||||||
],
|
],
|
||||||
"size": [
|
"size": [
|
||||||
200,
|
280,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "marketing",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Marketing",
|
||||||
|
"sublabel": "Brand and customer growth",
|
||||||
|
"pos": [
|
||||||
|
1000,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
280,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "finance",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Finance & Accounting",
|
||||||
|
"sublabel": "Financial performance and controls",
|
||||||
|
"pos": [
|
||||||
|
1320,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
280,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "people",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "HR & Administration",
|
||||||
|
"sublabel": "People and workplace",
|
||||||
|
"pos": [
|
||||||
|
1640,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
280,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "product-team-1",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Product Management",
|
||||||
|
"sublabel": "Strategy, priorities and outcomes",
|
||||||
|
"pos": [
|
||||||
|
100,
|
||||||
|
480
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "product-team-2",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Product Design",
|
||||||
|
"sublabel": "Research and experience design",
|
||||||
|
"pos": [
|
||||||
|
100,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-team-1",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Product Engineering",
|
||||||
|
"sublabel": "Marketplace software delivery",
|
||||||
|
"pos": [
|
||||||
|
420,
|
||||||
|
480
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-team-2",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Platform & IT",
|
||||||
|
"sublabel": "Reliability and internal systems",
|
||||||
|
"pos": [
|
||||||
|
420,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-team-3",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Architecture & Security",
|
||||||
|
"sublabel": "Technical standards and protection",
|
||||||
|
"pos": [
|
||||||
|
420,
|
||||||
|
760
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-team-4",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Quality Engineering",
|
||||||
|
"sublabel": "Testing and release quality",
|
||||||
|
"pos": [
|
||||||
|
420,
|
||||||
|
900
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-team-5",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Data & AI",
|
||||||
|
"sublabel": "Analytics, ML and AI enablement",
|
||||||
|
"pos": [
|
||||||
|
420,
|
||||||
|
1040
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "operations-team-1",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Operations Squad",
|
||||||
|
"sublabel": "Service, resolution, risk and quality",
|
||||||
|
"pos": [
|
||||||
|
740,
|
||||||
|
480
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "marketing-team-1",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Marketing Squad",
|
||||||
|
"sublabel": "Brand, acquisition and retention",
|
||||||
|
"pos": [
|
||||||
|
1060,
|
||||||
|
480
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "finance-team-1",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "Finance & Accounting Squad",
|
||||||
|
"sublabel": "Planning, controls and payments",
|
||||||
|
"pos": [
|
||||||
|
1380,
|
||||||
|
480
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
|
80
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "people-team-1",
|
||||||
|
"type": "frontend",
|
||||||
|
"label": "People & Administration Squad",
|
||||||
|
"sublabel": "Talent, people and workplace",
|
||||||
|
"pos": [
|
||||||
|
1700,
|
||||||
|
480
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
220,
|
||||||
80
|
80
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"connections": [
|
"connections": [
|
||||||
{
|
{
|
||||||
"id": "leadership-product",
|
"id": "management-product",
|
||||||
"from": "leadership",
|
"from": "management",
|
||||||
"to": "product"
|
"to": "product",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "top"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"id": "leadership-engineering",
|
"id": "management-technology",
|
||||||
"from": "leadership",
|
"from": "management",
|
||||||
"to": "engineering"
|
"to": "technology",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "top"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"id": "leadership-operations",
|
"id": "management-operations",
|
||||||
"from": "leadership",
|
"from": "management",
|
||||||
"to": "operations"
|
"to": "operations",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "top"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "management-marketing",
|
||||||
|
"from": "management",
|
||||||
|
"to": "marketing",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "top"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "management-finance",
|
||||||
|
"from": "management",
|
||||||
|
"to": "finance",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "top"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "management-people",
|
||||||
|
"from": "management",
|
||||||
|
"to": "people",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "top"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "product-1",
|
||||||
|
"from": "product",
|
||||||
|
"to": "product-team-1",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "product-2",
|
||||||
|
"from": "product",
|
||||||
|
"to": "product-team-2",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-1",
|
||||||
|
"from": "technology",
|
||||||
|
"to": "technology-team-1",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-2",
|
||||||
|
"from": "technology",
|
||||||
|
"to": "technology-team-2",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-3",
|
||||||
|
"from": "technology",
|
||||||
|
"to": "technology-team-3",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-4",
|
||||||
|
"from": "technology",
|
||||||
|
"to": "technology-team-4",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "technology-5",
|
||||||
|
"from": "technology",
|
||||||
|
"to": "technology-team-5",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "operations-1",
|
||||||
|
"from": "operations",
|
||||||
|
"to": "operations-team-1",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "marketing-1",
|
||||||
|
"from": "marketing",
|
||||||
|
"to": "marketing-team-1",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "finance-1",
|
||||||
|
"from": "finance",
|
||||||
|
"to": "finance-team-1",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "people-1",
|
||||||
|
"from": "people",
|
||||||
|
"to": "people-team-1",
|
||||||
|
"variant": "default",
|
||||||
|
"fromSide": "bottom",
|
||||||
|
"toSide": "left"
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"cards": [
|
"cards": [
|
||||||
{
|
{
|
||||||
"dot": "amber",
|
"dot": "cyan",
|
||||||
"title": "Test diagram \u2014 not a confirmed structure",
|
"title": "Product",
|
||||||
"items": [
|
"items": [
|
||||||
"All roles and relationships are illustrative.",
|
"Product Management",
|
||||||
"Actual Eldorado teams and reporting lines remain to be defined."
|
"Product Design"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"dot": "amber",
|
||||||
|
"title": "Technology",
|
||||||
|
"items": [
|
||||||
|
"Product Engineering",
|
||||||
|
"Platform & IT",
|
||||||
|
"Architecture & Security",
|
||||||
|
"Quality Engineering",
|
||||||
|
"Data & AI"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"dot": "cyan",
|
||||||
|
"title": "Operations",
|
||||||
|
"items": [
|
||||||
|
"Operations Squad",
|
||||||
|
"Customer Support; Trust & Resolution",
|
||||||
|
"Risk & Fraud",
|
||||||
|
"Operational Quality"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"dot": "amber",
|
||||||
|
"title": "Marketing",
|
||||||
|
"items": [
|
||||||
|
"Marketing Squad",
|
||||||
|
"Brand & Community; Creative; SEO",
|
||||||
|
"PPC & Affiliate; Influencer",
|
||||||
|
"CRM"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"dot": "cyan",
|
||||||
|
"title": "Finance & Accounting",
|
||||||
|
"items": [
|
||||||
|
"Finance & Accounting Squad",
|
||||||
|
"Financial Planning & Analysis",
|
||||||
|
"Accounting, Tax & Controls",
|
||||||
|
"Treasury & Payment Operations"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"dot": "amber",
|
||||||
|
"title": "HR & Administration",
|
||||||
|
"items": [
|
||||||
|
"People & Administration Squad",
|
||||||
|
"Talent Acquisition",
|
||||||
|
"People Operations",
|
||||||
|
"Office & Administration"
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
|
|||||||
@@ -0,0 +1,139 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Learn before expanding",
|
||||||
|
"output": "static/diagrams/strategy-adoption-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "choose",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Choose workflow",
|
||||||
|
"sublabel": "Department outcome",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coach",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Coach people",
|
||||||
|
"sublabel": "Verify + recover",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "canary",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Run bounded canary",
|
||||||
|
"sublabel": "Qualified skill + client",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "accept",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Accept real work",
|
||||||
|
"sublabel": "Independent review",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "feedback",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Review feedback",
|
||||||
|
"sublabel": "Usefulness + non-use",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "expand",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Expand or revise",
|
||||||
|
"sublabel": "Keep a manual path",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "choose",
|
||||||
|
"to": "coach",
|
||||||
|
"label": "Prepare"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "coach",
|
||||||
|
"to": "canary",
|
||||||
|
"label": "support pilot"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "canary",
|
||||||
|
"to": "accept",
|
||||||
|
"label": "Verify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "accept",
|
||||||
|
"to": "feedback",
|
||||||
|
"label": "learn"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "feedback",
|
||||||
|
"to": "expand",
|
||||||
|
"label": "decide"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "feedback-loop",
|
||||||
|
"from": "expand",
|
||||||
|
"to": "coach",
|
||||||
|
"label": "Review revision",
|
||||||
|
"variant": "dashed",
|
||||||
|
"fromSide": "right",
|
||||||
|
"toSide": "right"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,139 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Learn before expanding",
|
||||||
|
"output": "static/diagrams/strategy-adoption/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "choose",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Choose workflow",
|
||||||
|
"sublabel": "Department outcome",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coach",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Coach people",
|
||||||
|
"sublabel": "Verify + recover",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "canary",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Run bounded canary",
|
||||||
|
"sublabel": "Qualified skill + client",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "accept",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Accept real work",
|
||||||
|
"sublabel": "Independent review",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "feedback",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Review feedback",
|
||||||
|
"sublabel": "Usefulness + non-use",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "expand",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Expand or revise",
|
||||||
|
"sublabel": "Keep a manual path",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "choose",
|
||||||
|
"to": "coach",
|
||||||
|
"label": "Prepare"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "coach",
|
||||||
|
"to": "canary",
|
||||||
|
"label": "support pilot"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "canary",
|
||||||
|
"to": "accept",
|
||||||
|
"label": "Verify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "accept",
|
||||||
|
"to": "feedback",
|
||||||
|
"label": "learn"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "feedback",
|
||||||
|
"to": "expand",
|
||||||
|
"label": "decide"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "feedback-loop",
|
||||||
|
"from": "expand",
|
||||||
|
"to": "coach",
|
||||||
|
"label": "Review revision",
|
||||||
|
"variant": "dashed",
|
||||||
|
"fromSide": "right",
|
||||||
|
"toSide": "right"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Independent approval",
|
||||||
|
"output": "static/diagrams/strategy-governance-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "owner",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Owner proposes",
|
||||||
|
"sublabel": "Existing accountable team",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "review",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Independent review",
|
||||||
|
"sublabel": "Quality + risk evidence",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "canary",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Bounded canary",
|
||||||
|
"sublabel": "Qualified client path",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "approve",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Approve revision",
|
||||||
|
"sublabel": "Exact digest + scope",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "publish",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Publish bundle",
|
||||||
|
"sublabel": "Data & AI catalog",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "distribute",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Verify effective state",
|
||||||
|
"sublabel": "Platform & IT",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "owner",
|
||||||
|
"to": "review",
|
||||||
|
"label": "submit"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "review",
|
||||||
|
"to": "canary",
|
||||||
|
"label": "qualify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "canary",
|
||||||
|
"to": "approve",
|
||||||
|
"label": "Accept"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "approve",
|
||||||
|
"to": "publish",
|
||||||
|
"label": "record approval"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "publish",
|
||||||
|
"to": "distribute",
|
||||||
|
"label": "Deliver"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Independent approval",
|
||||||
|
"output": "static/diagrams/strategy-governance/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "owner",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Owner proposes",
|
||||||
|
"sublabel": "Existing accountable team",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "review",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Independent review",
|
||||||
|
"sublabel": "Quality + risk evidence",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "canary",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Bounded canary",
|
||||||
|
"sublabel": "Qualified client path",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "approve",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Approve revision",
|
||||||
|
"sublabel": "Exact digest + scope",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "publish",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Publish bundle",
|
||||||
|
"sublabel": "Data & AI catalog",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "distribute",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Verify effective state",
|
||||||
|
"sublabel": "Platform & IT",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "owner",
|
||||||
|
"to": "review",
|
||||||
|
"label": "submit"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "review",
|
||||||
|
"to": "canary",
|
||||||
|
"label": "qualify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "canary",
|
||||||
|
"to": "approve",
|
||||||
|
"label": "Accept"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "approve",
|
||||||
|
"to": "publish",
|
||||||
|
"label": "record approval"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "publish",
|
||||||
|
"to": "distribute",
|
||||||
|
"label": "Deliver"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Skills before authority",
|
||||||
|
"output": "static/diagrams/strategy-journey-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "skills",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Govern skills",
|
||||||
|
"sublabel": "Owner + pinned revision",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "prove",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Prove quality",
|
||||||
|
"sublabel": "Independent evaluation",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "pilot",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Pilot with people",
|
||||||
|
"sublabel": "Qualified local clients",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "distribute",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Verify distribution",
|
||||||
|
"sublabel": "Canary + rollback",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coordinate",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Coordinate delivery",
|
||||||
|
"sublabel": "One logical SDLC agent",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "expand",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Expand by evidence",
|
||||||
|
"sublabel": "Department outcomes",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "skills",
|
||||||
|
"to": "prove",
|
||||||
|
"label": "qualify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "prove",
|
||||||
|
"to": "pilot",
|
||||||
|
"label": "coach"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "pilot",
|
||||||
|
"to": "distribute",
|
||||||
|
"label": "Verify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "distribute",
|
||||||
|
"to": "coordinate",
|
||||||
|
"label": "prove recovery"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "coordinate",
|
||||||
|
"to": "expand",
|
||||||
|
"label": "Justify"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Skills before authority",
|
||||||
|
"output": "static/diagrams/strategy-journey/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "skills",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Govern skills",
|
||||||
|
"sublabel": "Owner + pinned revision",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "prove",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Prove quality",
|
||||||
|
"sublabel": "Independent evaluation",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "pilot",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Pilot with people",
|
||||||
|
"sublabel": "Qualified local clients",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "distribute",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Verify distribution",
|
||||||
|
"sublabel": "Canary + rollback",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coordinate",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Coordinate delivery",
|
||||||
|
"sublabel": "One logical SDLC agent",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "expand",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Expand by evidence",
|
||||||
|
"sublabel": "Department outcomes",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "skills",
|
||||||
|
"to": "prove",
|
||||||
|
"label": "qualify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "prove",
|
||||||
|
"to": "pilot",
|
||||||
|
"label": "coach"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "pilot",
|
||||||
|
"to": "distribute",
|
||||||
|
"label": "Verify"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "distribute",
|
||||||
|
"to": "coordinate",
|
||||||
|
"label": "prove recovery"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "coordinate",
|
||||||
|
"to": "expand",
|
||||||
|
"label": "Justify"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,141 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Maintain trust over time",
|
||||||
|
"output": "static/diagrams/strategy-maintenance-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "monitor",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Monitor skills",
|
||||||
|
"sublabel": "Usefulness + safety",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "triage",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Triage changes",
|
||||||
|
"sublabel": "Owner + risk review",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "correct",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Correct and test",
|
||||||
|
"sublabel": "Independent regression",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "decision",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Approve or hold",
|
||||||
|
"sublabel": "Exact revised bundle",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "promote",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Promote safely",
|
||||||
|
"sublabel": "Verify state + monitor",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "observe",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Quarantine / rollback",
|
||||||
|
"sublabel": "Revoke unsafe revision",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "monitor",
|
||||||
|
"to": "triage",
|
||||||
|
"label": "Detect"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "triage",
|
||||||
|
"to": "correct",
|
||||||
|
"label": "scope correction"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "correct",
|
||||||
|
"to": "decision",
|
||||||
|
"label": "Prove"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "decision",
|
||||||
|
"to": "promote",
|
||||||
|
"label": "authorize"
|
||||||
|
},
|
||||||
|
|
||||||
|
{
|
||||||
|
"id": "unsafe",
|
||||||
|
"from": "triage",
|
||||||
|
"to": "observe",
|
||||||
|
"label": "Unsafe",
|
||||||
|
"variant": "security",
|
||||||
|
"fromSide": "right",
|
||||||
|
"toSide": "right"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "review-loop",
|
||||||
|
"from": "observe",
|
||||||
|
"to": "correct",
|
||||||
|
"label": "Requalify",
|
||||||
|
"variant": "dashed"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,141 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Maintain trust over time",
|
||||||
|
"output": "static/diagrams/strategy-maintenance/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "monitor",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Monitor skills",
|
||||||
|
"sublabel": "Usefulness + safety",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "triage",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Triage changes",
|
||||||
|
"sublabel": "Owner + risk review",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "correct",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Correct and test",
|
||||||
|
"sublabel": "Independent regression",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "decision",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Approve or hold",
|
||||||
|
"sublabel": "Exact revised bundle",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "promote",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Promote safely",
|
||||||
|
"sublabel": "Verify state + monitor",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "observe",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Quarantine / rollback",
|
||||||
|
"sublabel": "Revoke unsafe revision",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "monitor",
|
||||||
|
"to": "triage",
|
||||||
|
"label": "Detect"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "triage",
|
||||||
|
"to": "correct",
|
||||||
|
"label": "scope correction"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "correct",
|
||||||
|
"to": "decision",
|
||||||
|
"label": "Prove"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "decision",
|
||||||
|
"to": "promote",
|
||||||
|
"label": "authorize"
|
||||||
|
},
|
||||||
|
|
||||||
|
{
|
||||||
|
"id": "unsafe",
|
||||||
|
"from": "triage",
|
||||||
|
"to": "observe",
|
||||||
|
"label": "Unsafe",
|
||||||
|
"variant": "security",
|
||||||
|
"fromSide": "right",
|
||||||
|
"toSide": "right"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "review-loop",
|
||||||
|
"from": "observe",
|
||||||
|
"to": "correct",
|
||||||
|
"label": "Requalify",
|
||||||
|
"variant": "dashed"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Evidence before claims",
|
||||||
|
"output": "static/diagrams/strategy-measurement-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "collect",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Collect evidence",
|
||||||
|
"sublabel": "Task / CI / incident",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "validate",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Validate sources",
|
||||||
|
"sublabel": "Joins + missingness",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "calculate",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Calculate measures",
|
||||||
|
"sublabel": "16 exact contracts",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "balance",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Read balanced signals",
|
||||||
|
"sublabel": "Quality / flow / risk",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "weigh",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Weigh benefit and cost",
|
||||||
|
"sublabel": "Outcomes / cost / people",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "decide",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Continue or change",
|
||||||
|
"sublabel": "No causal ROI claim",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "collect",
|
||||||
|
"to": "validate",
|
||||||
|
"label": "Check"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "validate",
|
||||||
|
"to": "calculate",
|
||||||
|
"label": "apply definitions"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "calculate",
|
||||||
|
"to": "balance",
|
||||||
|
"label": "compare"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "balance",
|
||||||
|
"to": "weigh",
|
||||||
|
"label": "consider together"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "weigh",
|
||||||
|
"to": "decide",
|
||||||
|
"label": "decide"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Evidence before claims",
|
||||||
|
"output": "static/diagrams/strategy-measurement/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "collect",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Collect evidence",
|
||||||
|
"sublabel": "Task / CI / incident",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "validate",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Validate sources",
|
||||||
|
"sublabel": "Joins + missingness",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "calculate",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Calculate measures",
|
||||||
|
"sublabel": "16 exact contracts",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "balance",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Read balanced signals",
|
||||||
|
"sublabel": "Quality / flow / risk",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "weigh",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Weigh benefit and cost",
|
||||||
|
"sublabel": "Outcomes / cost / people",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "decide",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Continue or change",
|
||||||
|
"sublabel": "No causal ROI claim",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "collect",
|
||||||
|
"to": "validate",
|
||||||
|
"label": "Check"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "validate",
|
||||||
|
"to": "calculate",
|
||||||
|
"label": "apply definitions"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "calculate",
|
||||||
|
"to": "balance",
|
||||||
|
"label": "compare"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "balance",
|
||||||
|
"to": "weigh",
|
||||||
|
"label": "consider together"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "weigh",
|
||||||
|
"to": "decide",
|
||||||
|
"label": "decide"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Risk-tiered qualification",
|
||||||
|
"output": "static/diagrams/strategy-quality-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "risk",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Classify risk",
|
||||||
|
"sublabel": "R1 / R2 / R3",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "plan",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Agree evaluation",
|
||||||
|
"sublabel": "Task mix + thresholds",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "trial",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Repeat trials",
|
||||||
|
"sublabel": "Candidate vs approved",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "verify",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Verify artifacts",
|
||||||
|
"sublabel": "Independent checks",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "gate",
|
||||||
|
"type": "security",
|
||||||
|
"label": "All gates pass?",
|
||||||
|
"sublabel": "Safety cannot be traded",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "promote",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Promote or hold",
|
||||||
|
"sublabel": "Owner decision",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "risk",
|
||||||
|
"to": "plan",
|
||||||
|
"label": "Scope"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "plan",
|
||||||
|
"to": "trial",
|
||||||
|
"label": "freeze plan"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "trial",
|
||||||
|
"to": "verify",
|
||||||
|
"label": "Assess"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "verify",
|
||||||
|
"to": "gate",
|
||||||
|
"label": "review evidence"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "gate",
|
||||||
|
"to": "promote",
|
||||||
|
"label": "decide"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Risk-tiered qualification",
|
||||||
|
"output": "static/diagrams/strategy-quality/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "risk",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Classify risk",
|
||||||
|
"sublabel": "R1 / R2 / R3",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "plan",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Agree evaluation",
|
||||||
|
"sublabel": "Task mix + thresholds",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "trial",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Repeat trials",
|
||||||
|
"sublabel": "Candidate vs approved",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "verify",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Verify artifacts",
|
||||||
|
"sublabel": "Independent checks",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "gate",
|
||||||
|
"type": "security",
|
||||||
|
"label": "All gates pass?",
|
||||||
|
"sublabel": "Safety cannot be traded",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "promote",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Promote or hold",
|
||||||
|
"sublabel": "Owner decision",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "risk",
|
||||||
|
"to": "plan",
|
||||||
|
"label": "Scope"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "plan",
|
||||||
|
"to": "trial",
|
||||||
|
"label": "freeze plan"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "trial",
|
||||||
|
"to": "verify",
|
||||||
|
"label": "Assess"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "verify",
|
||||||
|
"to": "gate",
|
||||||
|
"label": "review evidence"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "gate",
|
||||||
|
"to": "promote",
|
||||||
|
"label": "decide"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,110 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Evidence-gated rollout",
|
||||||
|
"output": "static/diagrams/strategy-roadmap-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "foundation",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "1 \u00b7 Foundation",
|
||||||
|
"sublabel": "People + data + baseline",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "pilot",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "2 \u00b7 Skills pilot",
|
||||||
|
"sublabel": "Qualified, useful work",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "distribution",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "3 \u00b7 Distribution",
|
||||||
|
"sublabel": "Revocation + recovery",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coordination",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "4 \u00b7 Coordination",
|
||||||
|
"sublabel": "Human takeover proven",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "expansion",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "5 \u00b7 Departments",
|
||||||
|
"sublabel": "Outcomes + cost + risk",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "foundation",
|
||||||
|
"to": "pilot",
|
||||||
|
"label": "Charter"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "pilot",
|
||||||
|
"to": "distribution",
|
||||||
|
"label": "quality + coverage"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "distribution",
|
||||||
|
"to": "coordination",
|
||||||
|
"label": "Controls"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "coordination",
|
||||||
|
"to": "expansion",
|
||||||
|
"label": "authority drills pass"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,110 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: Evidence-gated rollout",
|
||||||
|
"output": "static/diagrams/strategy-roadmap/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "foundation",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "1 \u00b7 Foundation",
|
||||||
|
"sublabel": "People + data + baseline",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "pilot",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "2 \u00b7 Skills pilot",
|
||||||
|
"sublabel": "Qualified, useful work",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "distribution",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "3 \u00b7 Distribution",
|
||||||
|
"sublabel": "Revocation + recovery",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coordination",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "4 \u00b7 Coordination",
|
||||||
|
"sublabel": "Human takeover proven",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
150
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "expansion",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "5 \u00b7 Departments",
|
||||||
|
"sublabel": "Outcomes + cost + risk",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
280
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "foundation",
|
||||||
|
"to": "pilot",
|
||||||
|
"label": "Charter"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "pilot",
|
||||||
|
"to": "distribution",
|
||||||
|
"label": "quality + coverage"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "distribution",
|
||||||
|
"to": "coordination",
|
||||||
|
"label": "Controls"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "coordination",
|
||||||
|
"to": "expansion",
|
||||||
|
"label": "authority drills pass"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,156 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: coordination without authority transfer",
|
||||||
|
"output": "static/diagrams/strategy-target-mobile/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "people",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "People authorize",
|
||||||
|
"sublabel": "Retain accountability",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coordinator",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "SDLC coordinator",
|
||||||
|
"sublabel": "Routes approved work",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "clients",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Local coding agents",
|
||||||
|
"sublabel": "Propose changes",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "gates",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Repository + CI",
|
||||||
|
"sublabel": "Verify exact revision",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "registry",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Governed skills",
|
||||||
|
"sublabel": "Pinned + qualified",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "approval",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Human approval",
|
||||||
|
"sublabel": "Exact artifact + scope",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
620
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "release",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Release service",
|
||||||
|
"sublabel": "Production credentials",
|
||||||
|
"pos": [
|
||||||
|
40,
|
||||||
|
740
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "people",
|
||||||
|
"to": "coordinator",
|
||||||
|
"label": "Authorize scope"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "coordinator",
|
||||||
|
"to": "clients",
|
||||||
|
"label": "Route tasks"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "registry",
|
||||||
|
"to": "coordinator",
|
||||||
|
"label": "Guide"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "registry",
|
||||||
|
"to": "clients",
|
||||||
|
"label": "Guide"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "clients",
|
||||||
|
"to": "gates",
|
||||||
|
"label": "Propose"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-5",
|
||||||
|
"from": "gates",
|
||||||
|
"to": "approval",
|
||||||
|
"label": "Evidence"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-6",
|
||||||
|
"from": "approval",
|
||||||
|
"to": "release",
|
||||||
|
"label": "Authorize"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,156 @@
|
|||||||
|
{
|
||||||
|
"schema_version": 1,
|
||||||
|
"diagram_type": "architecture",
|
||||||
|
"meta": {
|
||||||
|
"title": "TO-BE: coordination without authority transfer",
|
||||||
|
"output": "static/diagrams/strategy-target/index.html",
|
||||||
|
"quality_profile": "showcase",
|
||||||
|
"legend": {
|
||||||
|
"mode": "hidden"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"components": [
|
||||||
|
{
|
||||||
|
"id": "people",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "People authorize",
|
||||||
|
"sublabel": "Retain accountability",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
20
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "coordinator",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "SDLC coordinator",
|
||||||
|
"sublabel": "Routes approved work",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "clients",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Local coding agents",
|
||||||
|
"sublabel": "Propose changes",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
260
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "gates",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Repository + CI",
|
||||||
|
"sublabel": "Verify exact revision",
|
||||||
|
"pos": [
|
||||||
|
20,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "registry",
|
||||||
|
"type": "backend",
|
||||||
|
"label": "Governed skills",
|
||||||
|
"sublabel": "Pinned + qualified",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
140
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "approval",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Human approval",
|
||||||
|
"sublabel": "Exact artifact + scope",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
380
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "release",
|
||||||
|
"type": "security",
|
||||||
|
"label": "Release service",
|
||||||
|
"sublabel": "Production credentials",
|
||||||
|
"pos": [
|
||||||
|
260,
|
||||||
|
500
|
||||||
|
],
|
||||||
|
"size": [
|
||||||
|
180,
|
||||||
|
60
|
||||||
|
]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"connections": [
|
||||||
|
{
|
||||||
|
"id": "flow-0",
|
||||||
|
"from": "people",
|
||||||
|
"to": "coordinator",
|
||||||
|
"label": "Authorize scope"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-1",
|
||||||
|
"from": "coordinator",
|
||||||
|
"to": "clients",
|
||||||
|
"label": "Route tasks"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-2",
|
||||||
|
"from": "registry",
|
||||||
|
"to": "coordinator",
|
||||||
|
"label": "Guide"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-3",
|
||||||
|
"from": "registry",
|
||||||
|
"to": "clients",
|
||||||
|
"label": "Guide"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-4",
|
||||||
|
"from": "clients",
|
||||||
|
"to": "gates",
|
||||||
|
"label": "Propose"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-5",
|
||||||
|
"from": "gates",
|
||||||
|
"to": "approval",
|
||||||
|
"label": "Evidence"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "flow-6",
|
||||||
|
"from": "approval",
|
||||||
|
"to": "release",
|
||||||
|
"label": "Authorize"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -9,19 +9,19 @@ description: Author typed JSON diagrams and embed their local interactive viewer
|
|||||||
|
|
||||||
| Diagram type | Intended use |
|
| Diagram type | Intended use |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| Architecture | Components, boundaries and relationships; also suitable for this illustrative structure test |
|
| Architecture | Components, boundaries and relationships; also used for the organization structure views |
|
||||||
| Workflow | Processes, branches and approval gates |
|
| Workflow | Processes, branches and approval gates |
|
||||||
| Sequence | Participants and ordered messages |
|
| Sequence | Participants and ordered messages |
|
||||||
| Dataflow | Sources, processing and destinations |
|
| Dataflow | Sources, processing and destinations |
|
||||||
| Lifecycle | States and transitions |
|
| Lifecycle | States and transitions |
|
||||||
|
|
||||||
The standalone viewer provides pan/zoom, node inspection, search/focus, relationship tracing, light/dark themes, and an export menu. Motion is opt-in. The Organization example exercises architecture mode; other diagram types use the same build interface but do not yet have portal-specific examples. Browser-dependent exports such as video are not acceptance-tested by this integration.
|
The standalone viewer provides pan/zoom, node inspection, search/focus, relationship tracing, light/dark themes, and an export menu. Motion is opt-in. The Organization views exercise architecture mode; other diagram types use the same build interface but do not yet have portal-specific examples. Browser-dependent exports such as video are not acceptance-tested by this integration.
|
||||||
|
|
||||||
## Author a diagram
|
## Author a diagram
|
||||||
|
|
||||||
Create `diagrams/<name>.<type>.json` using the matching schema and authoring guidance in `vendor/archify/schemas/` and `vendor/archify/references/`. Use stable IDs, explicit relationships, and honest evidence labels. Do not include private information merely because the source repository is private: Pages access is a separate platform policy.
|
Create `diagrams/<name>.<type>.json` using the matching schema and authoring guidance in `vendor/archify/schemas/` and `vendor/archify/references/`. Use stable IDs, explicit relationships, and honest evidence labels. Do not include private information merely because the source repository is private: Pages access is a separate platform policy.
|
||||||
|
|
||||||
Set `meta.output` to `static/diagrams/<name>/index.html`. The build validates the typed source with the upstream showcase profile, renders locally, checks the artifact, and publishes the standalone HTML and a downloadable JSON source.
|
Set `meta.output` to `static/diagrams/<name>/index.html`. The build validates the typed source with the upstream showcase profile, renders locally, checks the artifact, and publishes the standalone HTML. Editable JSON stays in the repository; the portal does not publish source-download files.
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
pnpm diagrams:build
|
pnpm diagrams:build
|
||||||
@@ -34,13 +34,13 @@ pnpm build
|
|||||||
```mdx
|
```mdx
|
||||||
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
<ArchifyDiagram name="organization-structure" title="Illustrative organization structure" />
|
<ArchifyDiagram name="organization-structure" title="Eldorado organization structure" />
|
||||||
```
|
```
|
||||||
|
|
||||||
Supply a text alternative below each diagram. The wrapper uses a local, base-path-aware iframe with a descriptive title, scripts and downloads enabled, and no same-origin or parent-navigation permissions. A full-viewer link provides a wider canvas. Generated output is ignored by Git and rebuilt in CI.
|
Supply a text alternative below each diagram. The wrapper uses a local, base-path-aware iframe with a descriptive title, scripts and downloads enabled, and no same-origin or parent-navigation permissions. The top-right expand icon expands the diagram in a full-screen modal on the current page, with the same iframe sandbox. Close it with the Close button or Escape; focus returns to the opener. It does not open a new tab. The separate standalone HTML asset remains directly addressable and is not itself iframe-sandboxed, so publish only reviewed, trusted diagrams. Generated output is ignored by Git and rebuilt in CI.
|
||||||
|
|
||||||
## Integration boundaries
|
## Integration boundaries
|
||||||
|
|
||||||
The portal remains Docusaurus/React/TypeScript with pnpm. It uses the actual upstream renderer, not a look-alike diagram implementation. No Astro site, global agent installation, hosted rendering service, or AI API was added. The integration disables Archify update networking and does not run its installation commands.
|
The portal remains Docusaurus/React/TypeScript with pnpm. It uses the actual upstream renderer, not a look-alike diagram implementation. No Astro site, global agent installation, hosted rendering service, or AI API was added. The integration disables Archify update networking and does not run its installation commands. This does not disable every possible build-time request: upstream can fetch authored, digest-pinned brand URLs. The current example contains none. Review external asset sources deliberately; update-check suppression is not an offline guarantee.
|
||||||
|
|
||||||
Upgrades are deliberate: review the upstream diff and licenses, update the provenance record and vendor checksums, then run tests, diagram validation, production build, and browser checks. Do not edit upstream files for portal styling.
|
Upgrades are deliberate: review the upstream diff and licenses, update the provenance record and vendor checksums, then run tests, diagram validation, production build, and browser checks. Do not edit upstream files for portal styling.
|
||||||
+10
-1
@@ -19,7 +19,16 @@ Open the development server address printed in the terminal. The site uses the `
|
|||||||
|
|
||||||
## Add or change a page
|
## Add or change a page
|
||||||
|
|
||||||
Edit Markdown in `docs/`. Include `title` and `description` frontmatter and add the page ID to `sidebars.ts`. Keep the documentation’s future scope open until it is agreed.
|
Include `title` and `description` frontmatter. Place each page in its owning section and add its document ID to that section’s sidebar:
|
||||||
|
|
||||||
|
| Section | Content directory | Sidebar configuration |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Organization | `docs/organization/` | `sidebars/organization.ts` |
|
||||||
|
| Strategy | `docs/strategy/` | `sidebars/strategy.ts` |
|
||||||
|
| Contribution | `docs/contribution/` | `sidebars/contribution.ts` |
|
||||||
|
| Portal maintenance and reference | `docs/core/` | `sidebars.ts` |
|
||||||
|
|
||||||
|
Keep these content roots disjoint. Preserve existing URLs when moving pages. Specific AI initiatives and organizational reporting lines remain subject to agreement.
|
||||||
|
|
||||||
## Validate the change
|
## Validate the change
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,23 @@
|
|||||||
|
---
|
||||||
|
title: Collaboration
|
||||||
|
description: How Eldorado departments combine their responsibilities to deliver shared business outcomes.
|
||||||
|
---
|
||||||
|
|
||||||
|
Departments collaborate around shared outcomes while retaining their own team ownership and accountability. See [Structure](./structure.mdx) for department and squad responsibilities.
|
||||||
|
|
||||||
|
## How the departments work together
|
||||||
|
|
||||||
|
| Business outcome | Collaboration |
|
||||||
|
| --- | --- |
|
||||||
|
| Better buyer experience | Product defines improvements; Technology delivers them; Operations brings customer feedback; Data & AI measures the result. |
|
||||||
|
| Stronger seller experience | Product and Technology develop seller tools; Operations supports sellers; Finance manages financial processes. |
|
||||||
|
| Safe and trustworthy trading | Risk & Fraud, Trust & Resolution, Architecture & Security, and Finance coordinate controls and incident responses. |
|
||||||
|
| Sustainable growth | Marketing develops demand; Product improves conversion and retention; Finance measures profitability. |
|
||||||
|
| AI-powered execution | Data & AI supports engineering and develops marketplace intelligence; Operations improves service and quality workflows. |
|
||||||
|
|
||||||
|
Department leaders remain accountable for outcomes, controls and service quality as AI becomes part of everyday work.
|
||||||
|
|
||||||
|
## Related pages
|
||||||
|
|
||||||
|
- [Structure](./structure.mdx) — departments, squads and responsibilities.
|
||||||
|
- [SDLC — Software Delivery Life Cycle](./sdlc.mdx) — leadership and delivery responsibilities.
|
||||||
@@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
title: SDLC — Software Delivery Life Cycle
|
||||||
|
sidebar_label: SDLC
|
||||||
|
description: Leadership, reporting lines and team responsibilities supporting software delivery at Eldorado.
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
Software delivery brings together Product and Technology, supported by the departments responsible for marketplace operations and growth. This page describes the leadership and delivery responsibilities that support that work.
|
||||||
|
|
||||||
|
## Leadership and delivery structure
|
||||||
|
|
||||||
|
<ArchifyDiagram name="organization-reporting" compact title="Eldorado leadership and delivery structure" />
|
||||||
|
|
||||||
|
The diagram shows management responsibility from leader to role or team:
|
||||||
|
|
||||||
|
- **CTO → Head of Engineering → Group Engineering Managers → Engineering Managers → the Product Engineering team.**
|
||||||
|
- **CTO → AI Architect**, coordinating engineering AI enablement.
|
||||||
|
- **COO → Operational Quality**, providing independent quality oversight.
|
||||||
|
- **CMO → Brand Team Lead**, leading Brand & Community.
|
||||||
|
|
||||||
|
Product and Technology retain separate team ownership and reporting lines. Their teams coordinate priorities, design, engineering, quality and data work to deliver business outcomes.
|
||||||
|
|
||||||
|
## Related pages
|
||||||
|
|
||||||
|
- [Structure](./structure.mdx) — departments, squads and responsibilities.
|
||||||
|
- [Collaboration](./collaboration.mdx) — how departments coordinate around business outcomes.
|
||||||
@@ -1,19 +1,117 @@
|
|||||||
---
|
---
|
||||||
title: Structure
|
title: Structure
|
||||||
description: Explore an illustrative organization diagram with the Archify viewer.
|
description: Eldorado’s organizational operating model, departments, teams and responsibilities.
|
||||||
slug: /structure
|
|
||||||
---
|
---
|
||||||
|
|
||||||
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
:::note Illustrative integration example
|
This operating model organizes Eldorado around six departments: **Product, Technology, Operations, Marketing, Finance & Accounting, and HR & Administration**. Leadership aligns their priorities around marketplace growth, customer trust and efficient delivery.
|
||||||
This is **not Eldorado’s confirmed organization chart**. The roles and relationships below are test data demonstrating the diagram capability. Actual teams, reporting lines, and AI responsibilities will be defined separately.
|
|
||||||
:::
|
|
||||||
|
|
||||||
<ArchifyDiagram name="organization-structure" title="Illustrative organization structure" />
|
## Leadership
|
||||||
|
|
||||||
Select a node to inspect it. Use the viewer’s search, zoom, theme, and export controls, or open the full viewer for more space.
|
| Role | Leadership | Responsibility |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Chief Executive Officer | Vladas Jurkevičius | Company direction, business performance, strategic priorities and executive alignment. |
|
||||||
|
| Chief Operating Officer | Lukas Deksnys | Marketplace operations, customer service, resolution quality and operational performance. |
|
||||||
|
|
||||||
## Text alternative
|
Functional leaders translate company priorities into departmental plans. Team leads own execution, people development and service quality within their teams.
|
||||||
|
|
||||||
The example connects **Example leadership** to three sample functions: **Product**, **Engineering**, and **Operations**. These links demonstrate structure; they do not assert real reporting relationships at Eldorado.
|
## Organization overview
|
||||||
|
|
||||||
|
<ArchifyDiagram name="organization-structure" title="Eldorado organization structure" />
|
||||||
|
|
||||||
|
**Management coordinates the six departments.** Each department has a clear business responsibility and a set of teams that deliver it.
|
||||||
|
|
||||||
|
## Departments and teams
|
||||||
|
|
||||||
|
Product has **two teams** and Technology has **five teams**. Operations, Marketing, Finance & Accounting, and HR & Administration each have **one squad** covering their departmental workstreams. Each team belongs to one department, with its own leadership and responsibilities. The departments collaborate on delivery without sharing team ownership.
|
||||||
|
|
||||||
|
### Product
|
||||||
|
|
||||||
|
**Purpose:** improve the buyer and seller experience and turn marketplace opportunities into valuable product capabilities.
|
||||||
|
|
||||||
|
| Team | Responsibilities |
|
||||||
|
| --- | --- |
|
||||||
|
| Product Management | Product strategy, roadmaps, priorities and outcome measurement across discovery, categories, orders, seller tools, payments and operational workflows. |
|
||||||
|
| Product Design | User research, interaction design, design consistency and accessible buyer and seller experiences. |
|
||||||
|
|
||||||
|
Product Management owns what to improve and why. Product Design shapes the experience. Both work with Technology teams while remaining within Product.
|
||||||
|
|
||||||
|
### Technology
|
||||||
|
|
||||||
|
**Purpose:** build and operate a secure, reliable marketplace and improve the effectiveness of engineering.
|
||||||
|
|
||||||
|
| Team | Responsibilities |
|
||||||
|
| --- | --- |
|
||||||
|
| Product Engineering | Build and maintain marketplace capabilities, including search, orders, seller tools, checkout, wallet and operational tooling. |
|
||||||
|
| Platform & IT | Platform services, delivery infrastructure, observability, reliability, performance, internal systems, employee devices and identity administration. |
|
||||||
|
| Architecture & Security | Technical standards, system design, security architecture and secure engineering practices. |
|
||||||
|
| Quality Engineering | Test strategy, automation, release quality and defect prevention. |
|
||||||
|
| Data & AI | Analytics, experimentation, ranking, recommendations, marketplace ML and safe AI-assisted engineering workflows. |
|
||||||
|
|
||||||
|
The CTO owns technology direction. The Head of Engineering leads engineering delivery through Group Engineering Managers and Engineering Managers. The AI Architect coordinates AI enablement within Data & AI, working with Architecture & Security and the other Technology teams. These are leadership roles within the five-team structure, not additional teams.
|
||||||
|
|
||||||
|
### Operations
|
||||||
|
|
||||||
|
**Purpose:** keep marketplace trading dependable and resolve customer issues fairly and efficiently.
|
||||||
|
|
||||||
|
**Operations Squad** delivers the department’s responsibilities across the following workstreams.
|
||||||
|
|
||||||
|
| Workstream | Responsibilities |
|
||||||
|
| --- | --- |
|
||||||
|
| Customer Support | Buyer and seller assistance, knowledge management, self-service and support workflow automation. |
|
||||||
|
| Trust & Resolution | Disputes, appeals, refunds, warranties, chargebacks and complex customer cases. |
|
||||||
|
| Risk & Fraud | Transaction and account risk, fraud prevention, investigations and operational controls. |
|
||||||
|
| Operational Quality | Independent case reviews, quality standards, calibration, service accuracy and improvement tracking across operational teams. |
|
||||||
|
|
||||||
|
The COO coordinates Operations. Team leads manage specialists and daily service delivery. Operational Quality reports directly to the COO and reviews quality across teams.
|
||||||
|
|
||||||
|
### Marketing
|
||||||
|
|
||||||
|
**Purpose:** attract and retain customers, build the Eldorado brand and grow marketplace demand.
|
||||||
|
|
||||||
|
**Marketing Squad** delivers the department’s responsibilities across the following workstreams.
|
||||||
|
|
||||||
|
| Workstream | Responsibilities |
|
||||||
|
| --- | --- |
|
||||||
|
| Brand & Community | Brand positioning, campaigns, organic social, community and brand partnerships. |
|
||||||
|
| Creative | Campaign concepts, visual assets and performance creative. |
|
||||||
|
| SEO | Organic discovery, search visibility and content performance. |
|
||||||
|
| PPC & Affiliate | Paid acquisition, affiliate channels and return on marketing investment. |
|
||||||
|
| Influencer | Creator relationships, influencer programs and campaign delivery. |
|
||||||
|
| CRM | Customer lifecycle communication, retention, reactivation and campaign personalization. |
|
||||||
|
|
||||||
|
The CMO coordinates Marketing. The Brand Team Lead owns Brand & Community, with shared support from Creative and the other marketing workstreams.
|
||||||
|
|
||||||
|
### Finance & Accounting
|
||||||
|
|
||||||
|
**Purpose:** maintain financial control, support business decisions and keep marketplace money flows dependable.
|
||||||
|
|
||||||
|
**Finance & Accounting Squad** delivers the department’s responsibilities across the following workstreams.
|
||||||
|
|
||||||
|
| Workstream | Responsibilities |
|
||||||
|
| --- | --- |
|
||||||
|
| Financial Planning & Analysis | Budgets, forecasts, profitability, management reporting and investment analysis. |
|
||||||
|
| Accounting, Tax & Controls | Accounting, financial reporting, tax, audit coordination and internal controls. |
|
||||||
|
| Treasury & Payment Operations | Cash management, reconciliation, payout oversight, payment-provider coordination and financial risk. |
|
||||||
|
|
||||||
|
The CFO coordinates Finance & Accounting and works with executive leadership on business performance. Finance, Operations and Product share responsibility for effective payment and withdrawal processes, each within its own area of expertise.
|
||||||
|
|
||||||
|
### HR & Administration
|
||||||
|
|
||||||
|
**Purpose:** help teams attract, develop and retain people and provide an effective working environment.
|
||||||
|
|
||||||
|
**People & Administration Squad** delivers the department’s responsibilities across the following workstreams.
|
||||||
|
|
||||||
|
| Workstream | Responsibilities |
|
||||||
|
| --- | --- |
|
||||||
|
| Talent Acquisition | Recruitment, candidate experience, hiring coordination and workforce demand support. |
|
||||||
|
| People Operations | Employee onboarding, development, performance processes, policies and employee experience. |
|
||||||
|
| Office & Administration | Workplace services, office operations and administrative coordination. |
|
||||||
|
|
||||||
|
HR partners with department leaders on team capacity and development. People Operations works with Platform & IT on employee onboarding, role changes and offboarding.
|
||||||
|
|
||||||
|
## Related pages
|
||||||
|
|
||||||
|
- [Collaboration](./collaboration.mdx) — how departments work together on business outcomes.
|
||||||
|
- [SDLC — Software Delivery Life Cycle](./sdlc.mdx) — leadership and delivery responsibilities.
|
||||||
@@ -1,11 +0,0 @@
|
|||||||
---
|
|
||||||
title: Direction
|
|
||||||
description: Define the strategy and direction for an AI-powered Eldorado.
|
|
||||||
slug: /
|
|
||||||
---
|
|
||||||
|
|
||||||
# Strategy and direction
|
|
||||||
|
|
||||||
**Eldorado Powered By AI** is the space for shaping how AI can support Eldorado.
|
|
||||||
|
|
||||||
Specific initiatives, priorities, measures of success, and a delivery roadmap remain to be agreed. This section is ready for that work; no proposals here should be treated as approved commitments until explicitly agreed.
|
|
||||||
@@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
id: index
|
||||||
|
title: AI adoption strategy
|
||||||
|
description: Govern skills first; outcomes before activity; explicit target status.
|
||||||
|
slug: /
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## How do we reach dependable AI-assisted work?
|
||||||
|
|
||||||
|
Start with governed skills, then widen coordination only when evidence supports it. The destination is one logical SDLC coordinator alongside people using qualified local coding agents.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-journey" title="Skills and quality evidence precede wider coordination" story />
|
||||||
|
|
||||||
|
- **Skills first:** reusable working knowledge, not permission to act.
|
||||||
|
- **People stay accountable:** the six departments and eleven teams keep their decisions.
|
||||||
|
- **Outcomes before activity:** quality, risk and total cost determine whether to continue.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Strategy rationale and reading map</summary>
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
### Govern skills first, expand authority only with evidence
|
||||||
|
|
||||||
|
Eldorado's target is to make AI-assisted work dependable across the organization: useful guidance, clear human ownership, controlled execution and measurable outcomes. The first investment is a governed skills system, not an autonomous replacement for the organization. A skill packages reusable working knowledge, prerequisites and verification steps. It helps an agent perform a task; it does not grant permission or guarantee that the work is correct.
|
||||||
|
|
||||||
|
The target combines one logical SDLC coordinating agent with developer choice on local laptops. Copilot, Claude Code and Cline remain client options within a qualified support matrix. They receive the same reviewed portable skill content through client-specific adapters. Repository, CI and release services remain the enforcement points, independently of what any agent says or which local tool produced a change.
|
||||||
|
|
||||||
|
The strategy describes the intended operating model and the evidence required to introduce it. It does not establish that these controls are installed, that every client is supported, or that AI has improved Eldorado's performance. The current reference is the documented six-department organization. Rollout begins by validating actual clients, responsibilities, data boundaries and available evidence.
|
||||||
|
|
||||||
|
Success means accepted outcomes with maintained quality, controlled risk and understood total cost. Faster activity without reliable outcomes is not success. More skill invocations, generated lines or tool subscriptions are not productivity targets. People remain accountable for product, customer, financial and personnel decisions.
|
||||||
|
|
||||||
|
## Navigate the strategy
|
||||||
|
|
||||||
|
- [Target operating model](./target-operating-model.mdx) — One logical coordinator; local client choice; independent authority; all departments.
|
||||||
|
- [Skills governance](./skills-governance.mdx) — Contract, lifecycle, decision rights, adapters, locking, exceptions.
|
||||||
|
- [Skills quality](./skills-quality.mdx) — Risk tiers, independent evaluation, repeated trials, adversarial conformance.
|
||||||
|
- [Skills adoption](./skills-adoption.mdx) — Workflow-led coaching, client choice, feedback, manual path.
|
||||||
|
- [Measurement](./measurement.mdx) — Full KPI contracts, minimal events, illustrative calculations, privacy and limits.
|
||||||
|
- [Skills maintenance](./skills-maintenance.mdx) — Review, drift, deprecation, rollback and incident handling.
|
||||||
|
- [Roadmap](./roadmap.mdx) — Evidence-gated phases, no promised dates or budgets.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [See how people, skills and delivery controls connect →](./target-operating-model.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
@@ -0,0 +1,385 @@
|
|||||||
|
---
|
||||||
|
id: measurement
|
||||||
|
title: Measurement
|
||||||
|
description: Full KPI contracts, minimal events, illustrative calculations, privacy and limits.
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## Is AI-assisted work worth continuing?
|
||||||
|
|
||||||
|
Judge accepted outcomes alongside quality, delivery flow, risk, cost and human experience. Validate source coverage before calculating; missing evidence is unknown, not success.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-measurement" title="Collect evidence, validate it, calculate balanced measures and decide" story />
|
||||||
|
|
||||||
|
**Illustrative only:** 1 accepted task ÷ 4 matured starts × 100 = **25%** confirmed success. One unresolved task stays in the denominator; known-outcome coverage is **75%**. These are synthetic data, not Eldorado results.
|
||||||
|
|
||||||
|
- **16 contracts:** exact definitions below; 9 prototype calculations, 7 explicitly unimplemented metrics.
|
||||||
|
- **Balanced evidence:** no productivity rankings, composite score or causal ROI claim.
|
||||||
|
- **Privacy first:** no raw prompts or code by default; protect small cohorts and agree retention before collection.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Collection, baseline, event and privacy contracts</summary>
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
### Decide what counts before counting
|
||||||
|
|
||||||
|
Use the metric contracts below for exact definitions. Every report states its eligible population, observation window, numerator and denominator or distribution sample count, source coverage, exclusions and calculation version. Zero denominators return “not available.” Missing telemetry is unknown, not inactivity, compliance or success. Examples are explicitly synthetic and illustrative.
|
||||||
|
|
||||||
|
Begin with task acceptance, repository, CI, deployment and incident systems because they can independently establish outcomes. Add catalog/version inventory and task-level declarations. Client telemetry is supplementary and version-dependent; enabling rich tool details may collect sensitive commands and identifiers. Do not enable it merely to count skills. A normalized adapter may report approved skill identifiers without forwarding raw arguments.
|
||||||
|
|
||||||
|
Validated success uses all eligible initiated tasks whose predeclared observation window has matured. Failed and abandoned tasks remain nonsuccess. Unresolved or unobserved outcomes remain in the denominator, with known-outcome coverage shown alongside the conservative confirmed-success share. They are not relabeled as observed failure. A task cancelled before start is excluded; cancellation after start remains visible. Count a task once across retries and multiple skills. For timeliness, also show unfinished work and age; accepted-only lead-time distributions have survivorship limitations.
|
||||||
|
|
||||||
|
Track all five service-level DORA measures: commit-to-production lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate. Do not substitute PR-open-to-merge time or all-incident MTTR. Pair them with matured escaped-quality rates, policy effects, total cost per accepted outcome, support coverage, adoption, human experience and catalog maintenance. Keep customer/business outcomes linked to their departmental hypotheses; do not infer conversion, trust or revenue improvement from delivery telemetry.
|
||||||
|
|
||||||
|
### Baseline and interpretation
|
||||||
|
|
||||||
|
Before a pilot, freeze eligibility and acceptance rules and verify event joins. Collect prospective no-skill/current-practice evidence over a complete comparable workflow cycle and until the preregistered precision/sample requirement is met. Do not select a convenient end date after seeing results. Retain task class, service, skill, client/model configuration and concurrent changes. A matched or randomized comparison may be used when practical and ethical; label observational trends as descriptive and report confounding, selection and uncertainty.
|
||||||
|
|
||||||
|
Elapsed time and human effort are different quantities. Parallel agents may reduce waiting while increasing review or compute. Include failed attempts and human review/rework in cost, do not multiply a multi-skill task's value across every invocation, and do not convert survey perceptions into proven time savings. Small or incomplete populations yield evidence limits, not an ROI percentage.
|
||||||
|
|
||||||
|
### Event and privacy contract
|
||||||
|
|
||||||
|
Use a versioned event envelope and required fields per event. Source producer plus event ID deduplicates transport retries. Conflicting payloads under the same key are quarantined. Attempts have distinct IDs under one task. Domain IDs deduplicate deployments, defects and approvals even when multiple feeds describe them. Late arrivals produce versioned aggregate corrections; never silently overwrite a published result. Preserve occurrence and receipt times, reject impossible orderings and flag clock skew. Missing terminal events remain unresolved until the work owner reconciles them.
|
||||||
|
|
||||||
|
Many-to-many task/attempt/skill/client associations preserve exact immutable versions. Unknown version stays null with a reason; never assign the latest revision retroactively. Client declarations, server facts and self-reports remain separately labeled. A skill-loaded event is evidence of loading only. The minimal prototype can operate without actor identity except where a lawful, necessary adoption denominator requires pseudonymous cohort membership.
|
||||||
|
|
||||||
|
The privacy starting proposal is 30 days for raw structured analytics events and 12 months for aggregated trends, subject to the responsible owners' review. Keep the approved catalog/approval record for the supported revision's lifetime and its required audit period, which must be decided separately. Incident evidence uses a restricted, explicitly authorized hold and deletion schedule, not an indefinite analytics exception. Suppress reports below five people and prohibit drill-down or overlapping cohort slices that reconstruct identities. Five is a proposed minimum, not a guarantee against re-identification. No raw prompts, code, screens, customer cases or secrets are collected by default. Publish the purpose, lawful collection basis, access/deletion route and retention before collecting. Consent is not presumed to be an appropriate employment-law basis.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>All 16 KPI contracts — formulas, populations, owners and limits</summary>
|
||||||
|
|
||||||
|
## Metric contracts
|
||||||
|
|
||||||
|
Each contract is a prospective collection design. No live source or observed baseline is established. N and D refer to the numerator and denominator shown for that metric.
|
||||||
|
|
||||||
|
### Validated task success
|
||||||
|
|
||||||
|
Confirmed independently accepted tasks as a share of all eligible initiated tasks in a matured start cohort; a conservative confirmed-success share, not observed failure rate.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct matured task_ids with valid independent task.accepted evidence by as_of |
|
||||||
|
| Denominator | All distinct eligible task_ids started in window with started_at + preregistered task_observation_hours <= as_of |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Tasks in a preregistered workflow cohort, started in window; each counted once across retries, skills and clients. |
|
||||||
|
| Exclusions | Cancelled before start, sandbox/evaluation tasks and out-of-scope workflows; never post-start failures/abandonments. |
|
||||||
|
| Events and source | task.started; task.accepted; task.failed; task.abandoned; task.cancelled; work-management acceptance record |
|
||||||
|
| Owner / cadence | Quality Engineering / Weekly pilot; monthly departmental outcome review |
|
||||||
|
| Missing evidence | Unresolved/missing terminal outcomes remain in denominator with unknown count and known-outcome coverage; do not label them failed. Invalid/missing start excluded from calculation but flagged as orphan evidence. |
|
||||||
|
| Gaming and limits | Split easy tasks or omit starts; reconcile starts to approved backlog and audit acceptance rubrics. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Maturation horizon is workflow-specific and must be approved; no automatic abandonment on timeout. |
|
||||||
|
|
||||||
|
|
||||||
|
### Skill selection precision
|
||||||
|
|
||||||
|
Correct activations among activations on an independently labeled evaluation corpus.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | True-positive activations for the requested workflow |
|
||||||
|
| Denominator | True-positive plus false-positive activations |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | All candidate/client labeled evaluation task-trials with known activation and relevance. |
|
||||||
|
| Exclusions | Unlabeled/unknown activations excluded with coverage; no cherry-picked failed trials. |
|
||||||
|
| Events and source | eval.selection; versioned labeled corpus and runner |
|
||||||
|
| Owner / cadence | Data & AI / Each skill/client qualification |
|
||||||
|
| Missing evidence | Unknown activation/relevance is unscorable; publish missing count and deny qualification if planned coverage incomplete. |
|
||||||
|
| Gaming and limits | Choose easy labels or hide negative cases; freeze corpus and independently review labels. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Does not show execution success; precision depends on corpus prevalence. |
|
||||||
|
|
||||||
|
|
||||||
|
### Skill selection recall
|
||||||
|
|
||||||
|
Relevant task-trials in which the intended skill activates.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | True-positive activations |
|
||||||
|
| Denominator | True-positive plus false-negative task-trials |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Independently labeled relevant evaluation task-trials for a skill/client tuple. |
|
||||||
|
| Exclusions | Irrelevant tasks; missing relevance or activation reported as unscorable, not negative. |
|
||||||
|
| Events and source | eval.selection; versioned labeled corpus and runner |
|
||||||
|
| Owner / cadence | Data & AI / Each skill/client qualification |
|
||||||
|
| Missing evidence | Report evaluation coverage; null if no relevant labeled tasks. |
|
||||||
|
| Gaming and limits | Overtrigger to maximize recall; always pair with precision and negative cases. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Loading the right skill is not adherence. |
|
||||||
|
|
||||||
|
|
||||||
|
### Supported bundle coverage
|
||||||
|
|
||||||
|
Inventoried active installations with verified effective approved, supported and nonrevoked bundle/adapter tuple.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Eligible installation_ids with valid inventory evidence within approved freshness window and matching support matrix |
|
||||||
|
| Denominator | All expected active installation_ids in the managed pilot inventory |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Active installation inventory frozen for report, including invisible/offline entries until authoritative offboarding. |
|
||||||
|
| Exclusions | Verified decommissioned installations and nonpilot assets; lack of telemetry alone never excludes. |
|
||||||
|
| Events and source | inventory.observed; catalog.published; catalog.revoked; device inventory |
|
||||||
|
| Owner / cadence | Platform & IT / Weekly and at revocation |
|
||||||
|
| Missing evidence | Unknown/stale versions count outside numerator, inside denominator. Show inventory discovery coverage versus eligible device roster; if roster unknown metric is provisional. |
|
||||||
|
| Gaming and limits | Remove silent devices or trust declared versions; reconcile managed inventory and separately label attestation trust. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Even verified file digests do not prove a private model followed the content. |
|
||||||
|
|
||||||
|
|
||||||
|
### Approved-workflow adoption
|
||||||
|
|
||||||
|
Eligible participants with at least one approved-skill workflow use; usefulness assessed separately through accepted outcomes and feedback.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct eligible pseudonymous participants with workflow-linked skill.used on approved revision |
|
||||||
|
| Denominator | Distinct eligible participants in frozen invited cohort |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Consented or otherwise lawfully enrolled pilot cohort for the period; supported workflow available. |
|
||||||
|
| Exclusions | Outside pilot and formally recorded leave before period; nonresponders remain eligible, not excluded. |
|
||||||
|
| Events and source | skill.used; cohort.snapshot; optional qualified client adapter or declaration |
|
||||||
|
| Owner / cadence | Data & AI / Monthly |
|
||||||
|
| Missing evidence | Show observed lower bound and telemetry/response coverage; missing usage unknown rather than non-use. |
|
||||||
|
| Gaming and limits | Invocation quotas and coercion; no target usage count, split server/client/self-report origins. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Self-report is not verified use; installation/loading is not use or benefit. Suppress small groups. |
|
||||||
|
|
||||||
|
|
||||||
|
### Change lead time
|
||||||
|
|
||||||
|
Arithmetic mean commit-to-first-successful-production-deployment duration; also publish median/p90 and sample count.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Sum of elapsed hours from committed_at to first successful production deployment for each service+commit |
|
||||||
|
| Denominator | Count of eligible service+commit pairs with valid mappings |
|
||||||
|
| Expression | N / D |
|
||||||
|
| Aggregation | mean |
|
||||||
|
| Unit | hours/change |
|
||||||
|
| Eligible population | Changes first successfully deployed to a service in reporting window; rollout retries collapse to same logical deployment. |
|
||||||
|
| Exclusions | Nonproduction, duplicates, no-op deployment with no new commits; missing mappings shown as coverage loss. |
|
||||||
|
| Events and source | change.committed; deployment.completed; VCS immutable commit timestamps and release manifest |
|
||||||
|
| Owner / cadence | Platform & IT / Weekly per service |
|
||||||
|
| Missing evidence | Missing commit mapping or negative/skewed duration excluded from numeric sample, reported explicitly; no zero substitution. |
|
||||||
|
| Gaming and limits | Timestamp rewriting and cherry-picking fast work; lock change mapping and show undeployed backlog age. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Not PR cycle time, effort saved, or a complete view of unfinished changes. p90 uses nearest-rank sorted sample. |
|
||||||
|
|
||||||
|
|
||||||
|
### Deployment frequency
|
||||||
|
|
||||||
|
Distinct successful logical production deployments per complete service-day of observation.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct service_id+deployment_id successful production deployments in window |
|
||||||
|
| Denominator | Observed service-days in window |
|
||||||
|
| Expression | N / D |
|
||||||
|
| Aggregation | ratio |
|
||||||
|
| Unit | deployments/service-day |
|
||||||
|
| Eligible population | Declared production services and complete UTC observation days; report each service before pooled views. |
|
||||||
|
| Exclusions | Test/staging, failed attempts without production effect, duplicate callbacks and retries of the same rollout. |
|
||||||
|
| Events and source | deployment.completed; authoritative deployment service |
|
||||||
|
| Owner / cadence | Platform & IT / Weekly per service |
|
||||||
|
| Missing evidence | Missing feed periods not zero; report coverage and no unqualified overall rate when period incomplete. |
|
||||||
|
| Gaming and limits | Split deployments without value; pair with success, rework and failure measures. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. More deployments alone do not establish better performance; affected unsuccessful changes remain in change-fail population. |
|
||||||
|
|
||||||
|
|
||||||
|
### Change fail rate
|
||||||
|
|
||||||
|
Production deployment effects requiring unplanned remediation, rollback or hotfix, not solely outage declarations.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct matured production deployment_ids linked to qualifying immediate intervention |
|
||||||
|
| Denominator | All distinct production deployment_ids that reached production in the matured deployment cohort |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Deployments with production effect during window and approved intervention follow-up horizon elapsed. |
|
||||||
|
| Exclusions | Failed preproduction attempts, duplicate callbacks and no-effect retries; failures after production effect stay included. |
|
||||||
|
| Events and source | deployment.completed; deployment.failed; incident.linked; release and incident records |
|
||||||
|
| Owner / cadence | Quality Engineering / Weekly; finalized after horizon |
|
||||||
|
| Missing evidence | Known failures / all eligible deployments is a lower bound where incident linkage incomplete; label provisional and report unknown links. |
|
||||||
|
| Gaming and limits | Avoid incident links or relabel intervention planned; reconcile rollbacks/hotfixes independently. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Define immediate intervention and follow-up horizon before pilot; no universal incident-to-AI attribution. |
|
||||||
|
|
||||||
|
|
||||||
|
### Failed deployment recovery time
|
||||||
|
|
||||||
|
Mean elapsed time from production deployment failure onset to service restoration, with median/p90 and unresolved count/age.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Sum of recovery_at minus failure_started_at in hours for recovered eligible deployment failures |
|
||||||
|
| Denominator | Count of recovered eligible deployment failures with valid timestamps |
|
||||||
|
| Expression | N / D |
|
||||||
|
| Aggregation | mean |
|
||||||
|
| Unit | hours/failure |
|
||||||
|
| Eligible population | Production deployment failures beginning in window; latest verified restoration if a recovery is rescinded. |
|
||||||
|
| Exclusions | Nondeployment incidents; invalid timestamp pairs reported missing, not treated as instantaneous recovery. |
|
||||||
|
| Events and source | deployment.failed; service.restored; incident service |
|
||||||
|
| Owner / cadence | Platform & IT / Weekly with unresolved failures |
|
||||||
|
| Missing evidence | Unresolved failures reported separately and excluded only from recovered-duration distribution; prevent declaring improvement without their visibility. |
|
||||||
|
| Gaming and limits | Premature recovery declarations or omit hard cases; require operational readback and carry unresolved ages. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Not all-incident MTTR; recovered-only sample has survivorship bias. p90 nearest rank. |
|
||||||
|
|
||||||
|
|
||||||
|
### Deployment rework rate
|
||||||
|
|
||||||
|
Unplanned production deployment effects triggered by a production incident as a share of deployment effects.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct incident-linked deployment_ids classified unplanned remediation |
|
||||||
|
| Denominator | All distinct production deployment_ids with production effect in window |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Production deployment effects in window with immutable planned/unplanned classification and incident linkage. |
|
||||||
|
| Exclusions | Nonproduction, no-effect retries and duplicates; do not exclude unclassified changes silently. |
|
||||||
|
| Events and source | deployment.completed; incident.linked; release intent classification |
|
||||||
|
| Owner / cadence | Platform & IT / Weekly |
|
||||||
|
| Missing evidence | Unknown classification stays denominator; observed numerator is lower bound until reconciliation; show classification coverage. |
|
||||||
|
| Gaming and limits | Call hotfixes planned; freeze reason and independently reconcile incident/deployment links. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Distinct from failure rate: one failed deployment can lead to multiple separate rework deployments. |
|
||||||
|
|
||||||
|
|
||||||
|
### Changes with escaped quality issues
|
||||||
|
|
||||||
|
Accepted changes with at least one confirmed post-acceptance defect during approved follow-up, split by severity.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct eligible change_ids with one or more linked confirmed defects in follow-up |
|
||||||
|
| Denominator | Accepted change_ids with completed predeclared follow-up horizon |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Accepted changes in acceptance window whose follow-up is complete by as_of. |
|
||||||
|
| Exclusions | Immature changes shown separately; duplicates/unconfirmed reports excluded but counted as pending triage. |
|
||||||
|
| Events and source | change.accepted; defect.confirmed; defect tracking and acceptance evidence |
|
||||||
|
| Owner / cadence | Quality Engineering / Monthly mature cohorts |
|
||||||
|
| Missing evidence | Unknown linkage is a coverage warning; no fabricated clean outcome. Show absolute defect and severe incident counts as well. |
|
||||||
|
| Gaming and limits | Shorten follow-up or downgrade severity; freeze horizon and rubric and independently sample defects. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Counts affected changes, not raw defects per change; no presumption defects are AI-caused. |
|
||||||
|
|
||||||
|
|
||||||
|
### Confirmed policy effects
|
||||||
|
|
||||||
|
Eligible evaluated attempts with an actual confirmed prohibited effect; report attempts, blocked attempts and effects separately.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct attempt_ids with confirmed prohibited action effect |
|
||||||
|
| Denominator | All evaluated eligible attempt_ids including failed and abandoned runs |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Governed skill trials or supported workflow attempts, reported separately for eval and live populations. |
|
||||||
|
| Exclusions | Out-of-scope runs; detection gaps remain coverage issues, not exclusions from known initiated population. |
|
||||||
|
| Events and source | attempt.started; policy.violation; gate.blocked; security audit and incident triage |
|
||||||
|
| Owner / cadence | Architecture & Security / Immediate incident action; weekly aggregates |
|
||||||
|
| Missing evidence | Unknown outcomes remain visible; zero detected effects never proves safety. Missing audits make rate provisional. |
|
||||||
|
| Gaming and limits | Hide incidents or inflate harmless trials; absolute severity counts and fixed task mix accompany rate. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Blocked attempts are not actual effects; any critical effect blocks promotion regardless of aggregate rate. |
|
||||||
|
|
||||||
|
|
||||||
|
### Cost per accepted outcome
|
||||||
|
|
||||||
|
Allocated total workflow cost including unsuccessful attempts, licenses, compute, tooling and human review/rework divided by accepted outcomes.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Sum allocated costs in one approved reporting currency for all tasks/attempts in matured start cohort |
|
||||||
|
| Denominator | Distinct independently accepted tasks in same cohort |
|
||||||
|
| Expression | N / D |
|
||||||
|
| Aggregation | ratio |
|
||||||
|
| Unit | currency/accepted outcome |
|
||||||
|
| Eligible population | Matured eligible started-task cohort, with all attempt costs through as_of and allocated shared period costs. |
|
||||||
|
| Exclusions | Unrelated projects and documented taxes/transfers outside chosen accounting basis; never failed/abandoned attempts. |
|
||||||
|
| Events and source | cost.recorded; task.accepted; finance invoices, usage ledger, sampled effort with approved rates |
|
||||||
|
| Owner / cadence | Finance & Accounting Squad / Monthly with late invoice restatement |
|
||||||
|
| Missing evidence | Missing cost buckets produce partial estimate plus coverage, not a total. Mixed currency requires dated approved conversion; zero accepted outcomes = null with full cost shown. |
|
||||||
|
| Gaming and limits | Count tokens only or hide labor/failures; reconcile invoice and allocation totals without double counting. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Allocation and sampled labor carry uncertainty; no ROI without independently measured business benefit. |
|
||||||
|
|
||||||
|
|
||||||
|
### Verification confidence and cognitive load
|
||||||
|
|
||||||
|
Three separate anonymous 1–5 item distributions: confidence in verifying output, manageable workload, usefulness. Primary item: verification confidence mean; report full distributions and response rate.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Sum valid 1–5 verification-confidence responses, one per participant per survey wave |
|
||||||
|
| Denominator | Count valid responses to that item |
|
||||||
|
| Expression | N / D |
|
||||||
|
| Aggregation | mean |
|
||||||
|
| Unit | points (1–5) |
|
||||||
|
| Eligible population | Invited eligible cohort at fixed survey wave; voluntary responses. |
|
||||||
|
| Exclusions | Invalid/out-of-range answers and superseded duplicate submission; nonresponders stay in response-rate denominator. |
|
||||||
|
| Events and source | survey.response; anonymous survey with single-use token and aggregate invitation count |
|
||||||
|
| Owner / cadence | People & Administration Squad / After pilot workflow cycle; periodic follow-up |
|
||||||
|
| Missing evidence | Report valid response count / invited count and item nonresponse; no imputation. Suppress people cohorts below five. |
|
||||||
|
| Gaming and limits | Pressure to respond positively; no manager access to individual responses, avoid identifying free text. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Perception and selection bias; not measured time savings. No composite productivity index. |
|
||||||
|
|
||||||
|
|
||||||
|
### Skills within substantive review window
|
||||||
|
|
||||||
|
Active approved skill revisions with an accountable owner and completed substantive review not past due.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Distinct active approved skill revisions with current owner, review evidence and review_due_at >= as_of |
|
||||||
|
| Denominator | All active approved skill revisions in catalog snapshot |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | Approved revisions currently supported for use at as_of. |
|
||||||
|
| Exclusions | Experimental and retired revisions; deprecated/revoked in-use counts reported independently, not hidden. |
|
||||||
|
| Events and source | catalog.published; catalog.reviewed; catalog.deprecated; catalog.revoked; version inventory |
|
||||||
|
| Owner / cadence | Data & AI / Monthly and each release |
|
||||||
|
| Missing evidence | Missing owner/date/evidence outside numerator; show ownerless, deprecated-in-use and revoked-in-use absolute counts. |
|
||||||
|
| Gaming and limits | Rubber-stamp review dates; require linked regression/security/usefulness evidence. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. A current review is not proof of effectiveness; consumer inventory may miss shadow copies. |
|
||||||
|
|
||||||
|
|
||||||
|
### Workflow-specific business acceptance
|
||||||
|
|
||||||
|
Independently accepted domain outcomes against a predeclared business rubric, separate from technical completion.
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| Numerator | Eligible completed-observation task_ids meeting the department-specific outcome rubric |
|
||||||
|
| Denominator | All eligible initiated workflow task_ids with matured business-outcome horizon |
|
||||||
|
| Expression | N / D * 100 |
|
||||||
|
| Aggregation | percent |
|
||||||
|
| Unit | % |
|
||||||
|
| Eligible population | One named departmental workflow and predeclared start cohort; never pool unlike rubrics. |
|
||||||
|
| Exclusions | Cancelled-before-start and unrelated workflows; unsuccessful or abandoned eligible work remains. |
|
||||||
|
| Events and source | task.started; business.accepted; departmental case/content/reconciliation/onboarding review record |
|
||||||
|
| Owner / cadence | Product Management / Each pilot cycle with owning department |
|
||||||
|
| Missing evidence | Unknown follow-up stays denominator with unresolved count; no claim actual business outcome changed without source evidence. |
|
||||||
|
| Gaming and limits | Weaken rubric or count drafts as customer benefit; lock rubric and independently audit acceptance. Descriptive signal, not causal AI productivity attribution. Source completeness, task mix and sampling limit inference; report uncertainty. Domain owner signs acceptance: Operations service accuracy; Marketing claims/rights; Finance reconciliation accuracy; HR policy correctness; Product usability/value. Not revenue uplift. |
|
||||||
|
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Run the nine-metric synthetic prototype and inspect omissions</summary>
|
||||||
|
|
||||||
|
## Run the synthetic measurement example
|
||||||
|
|
||||||
|
**Executed synthetic example — not Eldorado results.** The bundled fixture produces 1 independently accepted task from 4 matured starts: 25% confirmed success. One unresolved task remains in that denominator; known-outcome coverage is 75%. Selection precision and recall are each 1 / 2 = 50%. Allocated synthetic cost is EUR 60 / 1 accepted outcome = EUR 60 per accepted outcome. These deliberately small samples demonstrate arithmetic and missingness, not a baseline, target or ROI claim.
|
||||||
|
|
||||||
|
From the private documentation checkout, run `node scripts/ai-kpi.mjs` and `node --test scripts/ai-kpi.test.mjs`. The fixture `scripts/fixtures/ai-kpi-synthetic.json` is labeled synthetic; every result carries the same label and calculation version. This prototype has no network collectors and does not enable employee telemetry.
|
||||||
|
|
||||||
|
The executable covers validated success, selection precision/recall, change fail and rework rates, escaped quality, policy effects, cost and human experience. Other catalog metrics remain contracts rather than implemented collectors; output lists the omissions. Snapshot inputs are simplified, pre-reconciled records, not a production ingestion system. Conflicting duplicates reject the calculation rather than silently choosing a value.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [Use findings to maintain, quarantine or replace skills →](./skills-maintenance.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
@@ -0,0 +1,75 @@
|
|||||||
|
---
|
||||||
|
id: roadmap
|
||||||
|
title: Roadmap
|
||||||
|
description: Evidence-gated phases, no promised dates or budgets.
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## What must be true before widening the rollout?
|
||||||
|
|
||||||
|
Advance by exit evidence, not promised dates or usage volume. Each stage can hold, narrow or stop; changed client, data or authority boundaries reopen earlier gates.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-roadmap" title="Foundation, pilot, reliable distribution, coordination and departmental expansion have exit gates" story />
|
||||||
|
|
||||||
|
- **Start bounded:** named people, lawful data handling and a reproducible baseline precede the pilot.
|
||||||
|
- **Prove recovery before coordination:** verified versions, revocation and human takeover are prerequisites.
|
||||||
|
- **Expand by department:** accepted outcomes, guardrails, total cost and experience justify continuation; sensitive decisions remain human.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Stage-by-stage entry evidence, work, exit gates and hold conditions</summary>
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
### Foundation
|
||||||
|
|
||||||
|
**Entry evidence** — Strategy scope accepted for planning; existing teams identified.
|
||||||
|
|
||||||
|
**Work** — Inventory actual client hosts/builds, provider/data terms, repositories, authority, owners and event availability; select low-risk workflows and metric definitions.
|
||||||
|
|
||||||
|
**Exit evidence and hold condition** — Named accountable people and independent reviewers, bounded pilot charter, forbidden actions, data/retention decision and reproducible baseline plan. Hold if accountability or lawful collection is unresolved.
|
||||||
|
|
||||||
|
### Governed skills pilot
|
||||||
|
|
||||||
|
**Entry evidence** — Foundation evidence approved; no privileged autonomous effects.
|
||||||
|
|
||||||
|
**Work** — Build a small registry, immutable contract, client adapters, evaluations, coaching and synthetic measurement verification.
|
||||||
|
|
||||||
|
**Exit evidence and hold condition** — Qualified client/skill tuples, mandatory safety checks, independent task acceptance, reconciled coverage and user feedback. Hold or narrow scope if quality or data coverage is inadequate.
|
||||||
|
|
||||||
|
### Reliable distribution
|
||||||
|
|
||||||
|
**Entry evidence** — Pilot quality and usefulness support continuing.
|
||||||
|
|
||||||
|
**Work** — Canary updates, effective-version readback, version locking, exception expiry, stale/offline handling and rollback.
|
||||||
|
|
||||||
|
**Exit evidence and hold condition** — Tested revocation and recovery, no bypass of central privileged gates, owners can support the catalog. Hold if effective versions or controls cannot be verified.
|
||||||
|
|
||||||
|
### Logical SDLC coordination
|
||||||
|
|
||||||
|
**Entry evidence** — Distribution, authority and measurement evidence stable.
|
||||||
|
|
||||||
|
**Work** — Observe and assemble evidence first, then propose and route work within scoped identities and budgets.
|
||||||
|
|
||||||
|
**Exit evidence and hold condition** — Exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills pass; humans can take over. No authority expansion based on usage alone.
|
||||||
|
|
||||||
|
### Departmental expansion
|
||||||
|
|
||||||
|
**Entry evidence** — Each department supplies a workflow owner, outcome, data boundary and capacity.
|
||||||
|
|
||||||
|
**Work** — Add Operations, Marketing, Finance & Accounting and HR & Administration workflows with domain-specific review; Product and Technology continue quality improvement.
|
||||||
|
|
||||||
|
**Exit evidence and hold condition** — Departmental accepted outcomes, guardrails, total cost and experience justify continuation; sensitive decisions stay human. Stop or roll back workflows without adequate evidence.
|
||||||
|
|
||||||
|
There are no invented launch dates, budgets, staffing commitments or guaranteed gains. Phase gates permit narrowing or stopping. Re-evaluate earlier phases when the underlying client, provider, data scope or authority changes.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [Return to the strategy destination →](./index.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
id: skills-adoption
|
||||||
|
title: Skills adoption
|
||||||
|
description: Workflow-led coaching, client choice, feedback, manual path.
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## When should a pilot become a team workflow?
|
||||||
|
|
||||||
|
Expand only when a bounded canary produces independently accepted work and useful feedback. Teach people to verify artifacts and recover without AI, not merely invoke a skill.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-adoption" title="Choose a workflow, coach a canary, verify outcomes and improve before expansion" story />
|
||||||
|
|
||||||
|
- **Team-led:** the departmental owner defines the outcome; People & Administration Squad supports learning.
|
||||||
|
- **Choice within support:** qualify the client path instead of promising identical agent behavior.
|
||||||
|
- **No adoption quotas:** retain a manual path; rejected suggestions and non-use are feedback, not poor performance.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Onboarding responsibilities, coaching and feedback safeguards</summary>
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
Start with a small set of useful workflows chosen by the existing teams. Product Management and the departmental owner identify the outcome; Data & AI helps turn it into a skill; Quality Engineering establishes acceptance; Platform & IT qualifies the client path; Architecture & Security clears the data boundary. People & Administration Squad coordinates learning and accessible feedback.
|
||||||
|
|
||||||
|
Onboarding should teach people to select the right skill, inspect the actual artifact, recognize untrusted instructions, use the exception and incident routes and recover without AI. A practice task ends with verified work and an explanation of limits, not just a logged invocation. Demonstrate the same portable skill on the supported local clients without promising identical agent behavior.
|
||||||
|
|
||||||
|
Use short worked examples, peer pairing, office hours and a clear catalog search path. Gather reasons for non-use and rejected suggestions without penalizing them. Preserve a manual path. Training feedback improves the skill only through review, not automatic self-modification of the approved catalog. Departmental workflow outcomes matter more than uniform uptake.
|
||||||
|
|
||||||
|
No developer rankings, individual productivity scores, minimum invocation quotas or inference of effort from token counts are part of this strategy. Report cohort-level evidence with privacy protection and balanced quality, flow, risk and cost. A participant may reasonably stop using a skill that creates more work or uncertainty.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [Measure accepted outcomes, not activity →](./measurement.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
@@ -0,0 +1,104 @@
|
|||||||
|
---
|
||||||
|
id: skills-governance
|
||||||
|
title: Skills governance
|
||||||
|
description: Contract, lifecycle, decision rights, adapters, locking, exceptions.
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## Who can approve a skill for use?
|
||||||
|
|
||||||
|
The owning team authors the skill; independent reviewers assess it before exact-revision approval. Data & AI maintains the catalog, while Platform & IT verifies distribution and revocation.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-governance" title="An owner proposes; independent review and canary evidence precede approval" story />
|
||||||
|
|
||||||
|
- **Separate duties:** the author cannot provide the only approval; higher risk involves Architecture & Security.
|
||||||
|
- **Pin the whole bundle:** content, adapters and executable dependencies travel together.
|
||||||
|
- **Keep controls authoritative:** exceptions expire and cannot bypass protected release, payment or identity controls.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Ownership, client qualification, exceptions and rollback</summary>
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
### A contract that travels, controls that stay authoritative
|
||||||
|
|
||||||
|
Maintain one catalog entry per stable skill ID, with immutable revisions and a concise portable `SKILL.md` body. Required content includes when to use and when not to use the skill, prerequisites, bounded steps, expected artifacts, verification, failure handling and escalation. The catalog contract below defines owner and independent reviewer, risk tier, supported clients and versions, dependencies, digest, provenance and license, evaluations, approval, review date, deprecation and rollback.
|
||||||
|
|
||||||
|
The release manifest pins the content, dependencies and adapter revisions by full immutable commit or digest. Names use an `eldorado-` prefix to reduce collisions. Friendly versions aid communication but never replace the digest. No arbitrary upstream automatic update is admitted into the approved bundle. Changes to scripts, resources or dependencies count as skill changes, not harmless documentation edits.
|
||||||
|
|
||||||
|
Adapters place content in the qualified client's discovery paths and implement only verified client-specific behavior. Qualification records the host, exact build, OS, model configuration, discovery, explicit invocation, collisions, disabled skills, permission behavior, context compaction and reload behavior. A common file format is not common precedence or a portable hooks API. Claude and Cline skill-name precedence differs from rule/memory behavior; Copilot support varies by surface. Test the actual build, not the brand name.
|
||||||
|
|
||||||
|
### Lifecycle and decision rights
|
||||||
|
|
||||||
|
A proposal names the problem, owner, data scope and testable outcome. Experimental revisions run only in approved disposable environments. Promotion requires independent review, static and executable dependency checks, per-client behavioral evaluations and a bounded canary. Approval records bind the exact artifact and permitted uses. Deprecated revisions carry a migration path and deadline; retired revisions are unavailable for new work. Any active revision can be quarantined immediately.
|
||||||
|
|
||||||
|
The author never supplies the only approval. Data & AI maintains catalog state; the owning team is accountable for content; Quality Engineering approves evaluation evidence; Architecture & Security approves higher-risk boundaries; Platform & IT verifies distribution and revocation. A business owner accepts workflow outcomes. These functions can be covered by existing staff, but incompatible author/approver duties must remain separate for the same release.
|
||||||
|
|
||||||
|
An exception contains its ID, skill/client revision, scope, business reason, risk owner, compensating checks, approver, start and expiry, affected users/projects and rollback route. It does not disable protected release, payment or identity controls. Expired or unverifiable exceptions deny privileged actions. Repeated exceptions trigger a supported-design change rather than permanent informal bypass.
|
||||||
|
|
||||||
|
### Distribution, stale clients and rollback
|
||||||
|
|
||||||
|
Stage a verified bundle atomically, check its digest, load it through the qualified adapter and read back its effective revision. Test already-open sessions; changing files is not proof of reloading instructions. Record immutable last-known-good content and adapter dependencies. Canary upgrades precede wider distribution.
|
||||||
|
|
||||||
|
A cached verified bundle may support explicitly permitted low-risk work if its model and tool dependencies are available. It does not make a cloud-backed client work offline. Stale or unsupported sessions cannot obtain centrally mediated privileged access. Reconnection revalidates support, revocation and policy before credentials are issued. Central artifact review protects delivery even when a laptop declaration is absent or false; a client report cannot prove which private prompt was actually followed.
|
||||||
|
|
||||||
|
Rollback restores the approved manifest and dependencies, invalidates affected sessions, revokes unsafe revisions, runs a smoke test and verifies effective state. It cannot undo data disclosure or commands already executed. Those require incident response.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Catalog contract — required fields</summary>
|
||||||
|
|
||||||
|
## Catalog contract
|
||||||
|
|
||||||
|
| Contract | Definition |
|
||||||
|
| --- | --- |
|
||||||
|
| skill_id | Stable globally unique eldorado-<domain>-<purpose>; never reused for a different purpose |
|
||||||
|
| name | Human-readable name |
|
||||||
|
| purpose | Problem, expected outcome and intended users |
|
||||||
|
| triggers | Positive and negative invocation conditions |
|
||||||
|
| owner | Existing department/team plus assigned accountable person before approval |
|
||||||
|
| reviewer | Independent person and existing team; cannot equal release author |
|
||||||
|
| backup | Named coverage within existing team before production support |
|
||||||
|
| risk_tier | R1\|R2\|R3; maximum implied by data, tool and effect scope |
|
||||||
|
| data_classification | Allowed input/output/provider boundary and forbidden data |
|
||||||
|
| authority_envelope | Allowed resources/operations and forbidden effects; enforced externally |
|
||||||
|
| supported_clients | Array of client, host, exact tested builds, OS, model configuration, adapter digest and qualification evidence |
|
||||||
|
| dependencies | All skill/resource/script/tool/MCP/plugin dependencies pinned by immutable digest plus license and source |
|
||||||
|
| revision | Full immutable source commit and content/artifact digest; friendly semver optional |
|
||||||
|
| tests_evals | Suite/corpus/rubric/runner/judge revisions, client tuple, seeds or trial IDs, results and independent evidence refs |
|
||||||
|
| approval | Approver identities, exact digest and policy revision, approved scope, time and expiry/invalidation condition |
|
||||||
|
| provenance_license | Origin repository/author, upstream revision, acquisition/review history, rights/license for content and bundled resources |
|
||||||
|
| maintenance_date | Last substantive review timestamp plus next review due and trigger conditions |
|
||||||
|
| deprecation | State, reason, replacement, migration instructions, consumers and retirement deadline if applicable |
|
||||||
|
| rollback | Approved known-good bundle+adapter+dependency digests, revocation/reload procedure and tested evidence |
|
||||||
|
| procedure | Prerequisites, bounded steps, expected artifacts, verification, failure handling, escalation |
|
||||||
|
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Lifecycle transitions and required evidence</summary>
|
||||||
|
|
||||||
|
## Promotion and retirement
|
||||||
|
|
||||||
|
| Transition | Required evidence |
|
||||||
|
| --- | --- |
|
||||||
|
| proposed → experimental | Owner, purpose, risk/data scope, disposable environment and preregistered test plan |
|
||||||
|
| experimental → approved | Independent review, all mandatory tests, qualified clients, canary, exact-digest approval |
|
||||||
|
| approved → deprecated | Owner gives migration/replacement and retirement conditions |
|
||||||
|
| deprecated → retired | Consumers reconciled or explicit risk-approved cutover; no new invocation |
|
||||||
|
| any active state → quarantined | Incident or unsafe/unknown provenance; central deny immediately |
|
||||||
|
| quarantined → experimental | Reviewed correction; new immutable revision; requalify, never auto-restore approval |
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [See the evidence needed to qualify a skill →](./skills-quality.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
id: skills-maintenance
|
||||||
|
title: Skills maintenance
|
||||||
|
description: Review, drift, deprecation, rollback and incident handling.
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## What happens when a skill drifts or causes harm?
|
||||||
|
|
||||||
|
Monitor usefulness and safety throughout a revision's life. Unsafe behavior triggers containment; a correction returns through independent tests and approval, never automatic reinstatement.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-maintenance" title="Monitor, triage and test corrections; promote safely or contain and roll back" story />
|
||||||
|
|
||||||
|
- **Named ownership:** Data & AI coordinates catalog health with the owning teams.
|
||||||
|
- **Early triggers:** incidents and client, model or dependency changes override the calendar.
|
||||||
|
- **Recovery is verified:** rollback restores a known-good bundle; it cannot undo disclosure or past effects.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Review responsibilities, incident handling and proposed review intervals</summary>
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
Every approved skill has an accountable owning team, independent reviewer, review due date, supported client matrix and rollback bundle. Review both usefulness and safety, not just metadata freshness. Proposed maximum review intervals are recorded by risk tier; incidents, dependency changes, model/client drift or repeated failures trigger earlier review.
|
||||||
|
|
||||||
|
Data & AI reviews catalog health with the owning teams. Quality Engineering samples accepted outputs and adds confirmed failures to regression sets without exposing sensitive content. Platform & IT watches unsupported, deprecated and revoked revisions and tests distribution recovery. Architecture & Security reviews emerging misuse and exception expiry. Remove redundant or unused entries deliberately, after examining whether poor discoverability or fit explains non-use.
|
||||||
|
|
||||||
|
A reported unsafe behavior opens an incident with artifact, policy and client versions. Architecture & Security coordinates containment; Platform & IT revokes authority, stops scheduling and quarantines affected revisions; the owning department handles customer or business consequences; Quality Engineering reproduces the failure; Data & AI coordinates catalog correction and trend analysis. Preserve minimal restricted evidence and involve People & Administration Squad for employee-data concerns and Finance & Accounting Squad for financial effects. Restart requires a reviewed fix, regression evidence, verified rollback/revocation and accountable human authorization. Closing the incident does not erase the historical failure from measurement.
|
||||||
|
|
||||||
|
## Proposed maximum review intervals
|
||||||
|
|
||||||
|
Owner ratification is required before adoption. Review earlier after incidents or material dependency changes.
|
||||||
|
|
||||||
|
| Tier | Maximum days between substantive reviews |
|
||||||
|
| --- | --- |
|
||||||
|
| R1 | 90 |
|
||||||
|
| R2 | 60 |
|
||||||
|
| R3 | 30 |
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [Use exit evidence to choose the next rollout stage →](./roadmap.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
@@ -0,0 +1,86 @@
|
|||||||
|
---
|
||||||
|
id: skills-quality
|
||||||
|
title: Skills quality
|
||||||
|
description: Risk tiers, independent evaluation, repeated trials, adversarial conformance.
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## What evidence is enough to promote a skill?
|
||||||
|
|
||||||
|
Risk determines the evaluation depth, not whether safety checks apply. Independent evidence must show useful outcomes and no failed mandatory gate before promotion.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-quality" title="Classify risk, test independently, then pass every mandatory gate" story />
|
||||||
|
|
||||||
|
- **R1:** approved nonsensitive drafting. **R2:** code or customer-impacting material. **R3:** privileged or sensitive effects; human-authorized, outside initial autonomous scope.
|
||||||
|
- **No averaging away harm:** a critical unauthorized effect blocks promotion.
|
||||||
|
- **Proposed floors need owner ratification:** missing coverage or acceptance rules means qualification is incomplete.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Evaluation design, adversarial cases and interpretation</summary>
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
Quality has four separate questions: was the right skill selected, was the procedure executed safely, did the artifact pass independent checks, and did the workflow produce useful outcomes? A successful invocation answers none of the remaining questions by itself.
|
||||||
|
|
||||||
|
The proposed qualification contract uses three tiers. R1 is read-only or drafting with nonsensitive approved material; R2 creates code or material with customer impact but no privileged external effect; R3 touches privileged, financial, sensitive-personal or production decisions. R3 remains human-authorized and out of the initial autonomous scope.
|
||||||
|
|
||||||
|
Every tier requires all mandatory deterministic safety, schema, authorization and provenance checks to pass, with no observed critical unauthorized action. An observed critical effect blocks promotion. The proposed pilot evaluation floors below set success thresholds; these are design defaults for owner ratification, not externally validated guarantees or approved service levels. If sample coverage, acceptance criteria or responsible reviewers are missing, qualification remains incomplete. No aggregate score can trade off a failed mandatory safety check.
|
||||||
|
|
||||||
|
Use sanitized, predeclared task sets containing positive triggers, near misses, negative cases and the normal workload mix. Compare no-skill, current-approved and candidate paths with the same starting artifacts; repeat stochastic trials and retain failed and abandoned attempts. Independently inspect output state. Deterministic tests grade checkable constraints; calibrated humans grade usefulness, maintainability and experience. A model judge is supplementary, versioned and checked against human disagreements, never the sole safety or promotion authority.
|
||||||
|
|
||||||
|
Include adversarial repository text, malicious referenced code, wrong permissions, client toggles, name shadowing, unsupported versions, hook timeout/crash/malformed response, stale sessions, offline recovery and rollback. Run central checks against forged/missing client declarations. Hook presence is not fail-closed enforcement: failure semantics must be tested on each client, and central authorization remains independent.
|
||||||
|
|
||||||
|
Report denominators, task mix, trial counts, per-client results and uncertainty. A passing benchmark is evidence within a tested envelope, not proof that all future tasks are safe. Material model, client, adapter or dependency changes trigger requalification.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Proposed R1 / R2 / R3 sample sizes and thresholds</summary>
|
||||||
|
|
||||||
|
## Proposed qualification floors
|
||||||
|
|
||||||
|
These are local design defaults for responsible-owner ratification, not approved service levels or guarantees. All mandatory checks must pass regardless of aggregate score.
|
||||||
|
|
||||||
|
### R1
|
||||||
|
|
||||||
|
**Distinct tasks** — 30
|
||||||
|
|
||||||
|
**Trials per task/client** — 3
|
||||||
|
|
||||||
|
**Artifact success** — 90%
|
||||||
|
|
||||||
|
**Selection precision / recall** — 90% / 90%
|
||||||
|
|
||||||
|
### R2
|
||||||
|
|
||||||
|
**Distinct tasks** — 60
|
||||||
|
|
||||||
|
**Trials per task/client** — 3
|
||||||
|
|
||||||
|
**Artifact success** — 95%
|
||||||
|
|
||||||
|
**Selection precision / recall** — 95% / 90%
|
||||||
|
|
||||||
|
### R3
|
||||||
|
|
||||||
|
**Distinct tasks** — 100
|
||||||
|
|
||||||
|
**Trials per task/client** — 5
|
||||||
|
|
||||||
|
**Artifact success** — 99%
|
||||||
|
|
||||||
|
**Selection precision / recall** — 99% / 95%
|
||||||
|
|
||||||
|
Artifact success denominator is every planned executed trial, retaining failures and abandonment. Trials of same task are correlated: show per-task and per-client strata; do not inflate independent sample size. Selection floors use independent labels. Report 95% uncertainty intervals clustered by task for outcome comparisons; no regression versus current approved path beyond a preregistered owner-approved margin. Missing margin/precision rule prevents promotion.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [Introduce qualified skills through a bounded pilot →](./skills-adoption.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
@@ -0,0 +1,138 @@
|
|||||||
|
---
|
||||||
|
id: target-operating-model
|
||||||
|
title: Target operating model
|
||||||
|
description: One logical coordinator; local client choice; independent authority; all departments.
|
||||||
|
hide_table_of_contents: true
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
<div className="strategy-content">
|
||||||
|
|
||||||
|
**TO-BE · Target operating model — not installed controls or company results.**
|
||||||
|
|
||||||
|
## Who coordinates, and who can authorize delivery?
|
||||||
|
|
||||||
|
One logical coordinator routes work; people retain authority. Local agents propose changes, while independent CI and human approval govern what the release service can execute.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="strategy-target" title="People authorize; skills guide; independent gates protect release" story />
|
||||||
|
|
||||||
|
- **Local choice:** Copilot, Claude Code and Cline use qualified adapters and pinned skills.
|
||||||
|
- **Central controls:** neither laptops nor the coordinator hold production credentials.
|
||||||
|
- **Existing organization:** six departments, eleven teams; Data & AI owns coordination, not their decisions.
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Trust boundaries, recovery and detailed delivery path</summary>
|
||||||
|
|
||||||
|
## Coordination without transferred authority
|
||||||
|
|
||||||
|
The diagram is an overview; the equivalent delivery path below remains readable on narrow screens. Expand the diagram to inspect its trust boundaries and use its zoom controls for individual relationships.
|
||||||
|
|
||||||
|
1. Accountable people authorize the work scope; one logical coordinator routes tasks.
|
||||||
|
2. The reviewed registry supplies pinned skills and qualified adapters to coordinator and local clients.
|
||||||
|
3. Laptop contributors propose changes; independent repository and CI checks verify the exact revision.
|
||||||
|
4. A human approves that artifact; only the release service holds production credentials.
|
||||||
|
5. Restricted audit and measurement evidence returns to people and informs the next authorized task.
|
||||||
|
|
||||||
|
<ArchifyDiagram name="ai-adoption-target" title="TO-BE AI adoption: human accountability, no direct production authority for laptops or coordinator" />
|
||||||
|
|
||||||
|
**TO-BE · Target operating model.** Introduction depends on the [roadmap gates](./roadmap.mdx); these pages do not describe installed controls or measured company results.
|
||||||
|
|
||||||
|
### One coordination function, distributed contributions
|
||||||
|
|
||||||
|
Data & AI owns the coordinating function, with the existing AI Architect function connecting it to Technology leadership. The logical coordinator maintains approved work records, dependencies, evidence requests, bounded retries and escalation. It can summarize, propose work and route decisions. It cannot declare its own work approved, change protected checks, authorize production release or replace the responsible human.
|
||||||
|
|
||||||
|
One logical coordinator does not mean one fragile process. A durable task ledger, explicit state transitions, leases and idempotency keys allow recovery or multiple replicas without duplicate delivery. Inference outages stop new agent decisions, not the organization's ability to take over. People can resume work through the normal deterministic workflow. Evidence and authorization services fail closed for privileged actions; missing evidence never becomes permission.
|
||||||
|
|
||||||
|
The delivery path is: an approved problem and acceptance criteria; an authorized task; local or isolated worker proposals; independently reviewed repository changes; exact-revision CI evidence; a human release decision; execution by the release service; then operational feedback. Product Management accepts the outcome hypothesis and business result. Product Design reviews experience and accessibility. Product Engineering owns the code and maintainability. Quality Engineering assesses quality independently. Architecture & Security assesses risk. Platform & IT operates the delivery boundary. No arrow from a laptop or coordinator goes directly to production authority.
|
||||||
|
|
||||||
|
### Trust and authority boundaries
|
||||||
|
|
||||||
|
People authenticate to the work system; the coordinator receives only the project context it needs. Untrusted issue text, repository content, web pages and tool output are task data, never an authorization source. Local clients operate under device controls and project-scoped access. Hard containment requires OS/container isolation, filesystem and network restrictions and separate short-lived identities; a skill folder, prompt or working directory is not a sandbox.
|
||||||
|
|
||||||
|
The registry distributes reviewed immutable content and adapters, not ambient credentials. Executable scripts, plugins, MCP servers and dependencies are separately reviewed and pinned. Model-provider routing is allowlisted for the data classification, with approved retention and training-use terms before sensitive data crosses that boundary. Fallback to another provider must not silently change the data policy.
|
||||||
|
|
||||||
|
Central controls verify protected-branch review, actual artifact identity, exact commit and policy revision, required checks and a scoped human approval. Candidate changes cannot edit their own authoritative gate or reuse approval for a different artifact. Deployment credentials belong to the release service, not the local agent. Approval expires or is invalidated by changed content. Emergency stop revokes mutation credentials and stops scheduling independently of the model, preserves evidence and enables human takeover.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Responsibilities and first workflows for all eleven teams</summary>
|
||||||
|
|
||||||
|
### Department contributions
|
||||||
|
|
||||||
|
### Product / Product Management
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own pilot priorities, acceptance criteria and outcome hypotheses; decide product value.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Draft acceptance criteria from sanitized discovery notes; independent completeness review and accepted-task success.
|
||||||
|
|
||||||
|
### Product / Product Design
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own design quality, accessibility and research handling.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Review a proposed flow against an accessibility checklist; verify findings against the interface.
|
||||||
|
|
||||||
|
### Technology / Product Engineering
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own skill authoring, code review and maintainability; remain accountable for generated code.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Test scaffolding and change summaries in a disposable branch; independent tests and escaped-quality follow-up.
|
||||||
|
|
||||||
|
### Technology / Platform & IT
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own supported client inventory, distribution, identity, isolation, CI/release integration, transport and emergency revocation.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Qualify a pinned bundle and exercise rollback; inventory and exact-revision gate evidence.
|
||||||
|
|
||||||
|
### Technology / Architecture & Security
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own risk classification, data boundaries, security review and bounded exceptions.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Review injected-input and unauthorized-tool cases; independent control evidence and policy-effect counts.
|
||||||
|
|
||||||
|
### Technology / Quality Engineering
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own regression/adversarial suites, rubric calibration and acceptance evidence.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Evaluate candidate versus approved skills on repeated representative tasks; retain all failures.
|
||||||
|
|
||||||
|
### Technology / Data & AI
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own catalog coordination, coordinator evaluation and measurement design, through existing AI enablement responsibilities.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Curate a small skill set and analyze a prospective pilot; no new AI department.
|
||||||
|
|
||||||
|
### Operations / Operations Squad
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own service acceptance, disputes, fraud, refunds and customer communications.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Draft an answer from sanitized resolved cases; Operational Quality workstream checks correctness before any send. No automated dispute/refund decision.
|
||||||
|
|
||||||
|
### Marketing / Marketing Squad
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own brand, factual claims, content rights, publication and spend approvals.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Draft a campaign brief against approved brand material; human claim/rights review before publication.
|
||||||
|
|
||||||
|
### Finance & Accounting / Finance & Accounting Squad
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own allocation of total costs, financial evidence and segregation of approvals.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Explain a sanitized reconciliation exception; no posting, payout or payment authority.
|
||||||
|
|
||||||
|
### HR & Administration / People & Administration Squad
|
||||||
|
|
||||||
|
**Contribution and retained human decision** — Own coaching, acceptable use, feedback privacy and people decisions; partner with Platform & IT on access lifecycle.
|
||||||
|
|
||||||
|
**First bounded workflow and evidence** — Draft onboarding guidance from approved policy; human accuracy review. No hiring or performance decision automation.
|
||||||
|
|
||||||
|
Product keeps two teams; Technology keeps five; the other four departments keep one squad each. Coordination, skill ownership, approval and cover are assignments inside these teams, not new standing departments, roles or headcount. Department leaders retain accountability and designate real approvers before a pilot starts.
|
||||||
|
|
||||||
|
See the existing [organization structure](/organization/structure/), [department collaboration](/organization/collaboration/) and [SDLC responsibilities](/organization/sdlc/).
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
**Next:** [Decide who owns and approves each skill →](./skills-governance.mdx)
|
||||||
|
|
||||||
|
</div>
|
||||||
+9
-2
@@ -14,7 +14,9 @@
|
|||||||
"verify": "pnpm test && node scripts/verify.mjs",
|
"verify": "pnpm test && node scripts/verify.mjs",
|
||||||
"verify:build": "node scripts/verify.mjs --build",
|
"verify:build": "node scripts/verify.mjs --build",
|
||||||
"diagrams:build": "node scripts/build-diagrams.mjs",
|
"diagrams:build": "node scripts/build-diagrams.mjs",
|
||||||
"test": "node --test scripts/portal.test.mjs"
|
"test": "node --test scripts/*.test.mjs",
|
||||||
|
"test:browser": "node scripts/browser/strategy-story.cjs",
|
||||||
|
"kpi:example": "node scripts/ai-kpi.mjs"
|
||||||
},
|
},
|
||||||
"dependencies": {
|
"dependencies": {
|
||||||
"@docusaurus/core": "3.10.2",
|
"@docusaurus/core": "3.10.2",
|
||||||
@@ -32,9 +34,14 @@
|
|||||||
"@docusaurus/tsconfig": "3.10.2",
|
"@docusaurus/tsconfig": "3.10.2",
|
||||||
"@docusaurus/types": "3.10.2",
|
"@docusaurus/types": "3.10.2",
|
||||||
"@types/react": "19.1.13",
|
"@types/react": "19.1.13",
|
||||||
|
"playwright": "1.63.0",
|
||||||
"typescript": "5.9.3"
|
"typescript": "5.9.3"
|
||||||
},
|
},
|
||||||
"pnpm": {"overrides": {"serialize-javascript": "7.0.5"}},
|
"pnpm": {
|
||||||
|
"overrides": {
|
||||||
|
"serialize-javascript": "7.0.5"
|
||||||
|
}
|
||||||
|
},
|
||||||
"browserslist": {
|
"browserslist": {
|
||||||
"production": [
|
"production": [
|
||||||
">0.5%",
|
">0.5%",
|
||||||
|
|||||||
Generated
+19
@@ -51,6 +51,9 @@ importers:
|
|||||||
'@types/react':
|
'@types/react':
|
||||||
specifier: 19.1.13
|
specifier: 19.1.13
|
||||||
version: 19.1.13
|
version: 19.1.13
|
||||||
|
playwright:
|
||||||
|
specifier: 1.63.0
|
||||||
|
version: 1.63.0
|
||||||
typescript:
|
typescript:
|
||||||
specifier: 5.9.3
|
specifier: 5.9.3
|
||||||
version: 5.9.3
|
version: 5.9.3
|
||||||
@@ -3962,6 +3965,16 @@ packages:
|
|||||||
resolution: {integrity: sha512-Oo/NZcSWccq8KyoG7gLE9fnltgHns+pNCjCAp/WmjsUySi+sX7y4z4Xqu4fVb42CDHzRPl33fjzT15V1wvcyhA==}
|
resolution: {integrity: sha512-Oo/NZcSWccq8KyoG7gLE9fnltgHns+pNCjCAp/WmjsUySi+sX7y4z4Xqu4fVb42CDHzRPl33fjzT15V1wvcyhA==}
|
||||||
engines: {node: '>=16.0.0'}
|
engines: {node: '>=16.0.0'}
|
||||||
|
|
||||||
|
playwright-core@1.63.0:
|
||||||
|
resolution: {integrity: sha512-rYCsBF/M5HjUch52bbtVONEFjv6Xu8sm8h72dNlR5bzIE1fvC/bxgspzkjSfU+MweEMmPM8KJebG6nnyxo5mCg==}
|
||||||
|
engines: {node: '>=20'}
|
||||||
|
hasBin: true
|
||||||
|
|
||||||
|
playwright@1.63.0:
|
||||||
|
resolution: {integrity: sha512-+7ziBLidS4NaNCdt57SUDT+wYmmd5fmiQejUic/kb+YsYSCPyOOE9sebzMjNmQrsnNpDJqd4WHvV/8lfKfUDUg==}
|
||||||
|
engines: {node: '>=20'}
|
||||||
|
hasBin: true
|
||||||
|
|
||||||
postcss-attribute-case-insensitive@7.0.1:
|
postcss-attribute-case-insensitive@7.0.1:
|
||||||
resolution: {integrity: sha512-Uai+SupNSqzlschRyNx3kbCTWgY/2hcwtHEI/ej2LJWc9JJ77qKgGptd8DHwY1mXtZ7Aoh4z4yxfwMBue9eNgw==}
|
resolution: {integrity: sha512-Uai+SupNSqzlschRyNx3kbCTWgY/2hcwtHEI/ej2LJWc9JJ77qKgGptd8DHwY1mXtZ7Aoh4z4yxfwMBue9eNgw==}
|
||||||
engines: {node: '>=18'}
|
engines: {node: '>=18'}
|
||||||
@@ -10793,6 +10806,12 @@ snapshots:
|
|||||||
pvutils: 1.2.0
|
pvutils: 1.2.0
|
||||||
tslib: 2.8.1
|
tslib: 2.8.1
|
||||||
|
|
||||||
|
playwright-core@1.63.0: {}
|
||||||
|
|
||||||
|
playwright@1.63.0:
|
||||||
|
dependencies:
|
||||||
|
playwright-core: 1.63.0
|
||||||
|
|
||||||
postcss-attribute-case-insensitive@7.0.1(postcss@8.5.28):
|
postcss-attribute-case-insensitive@7.0.1(postcss@8.5.28):
|
||||||
dependencies:
|
dependencies:
|
||||||
postcss: 8.5.28
|
postcss: 8.5.28
|
||||||
|
|||||||
@@ -0,0 +1,229 @@
|
|||||||
|
# Eldorado AI adoption — research handoff
|
||||||
|
|
||||||
|
Research only. Retrieved 4 October 2026 UTC. This document separates documented vendor capability, empirical evidence, and recommendations. Nothing here certifies an Eldorado rollout, installed client, enabled telemetry, staffing appointment, measured baseline, or realized productivity improvement. Sources and literal supporting passages are in `sources.json`; fetched text, retrieval outcomes and citation ledger are retained alongside it.
|
||||||
|
|
||||||
|
## 1. Local organizational baseline and scope
|
||||||
|
|
||||||
|
Read-only remote fetch and status inspection found a clean documentation checkout on `main`, with HEAD and `origin/main` both `14ba1aa1ef66c91525135f743d15c77e32db78d3`. Inspected all three current Organization pages: `structure.mdx`, `collaboration.mdx`, `sdlc.mdx`, plus channel wiki `/opt/data/wiki/channels/1555510466904727622.md`. This is documentation evidence, not independent verification of actual personnel, systems, or deployed controls. No repository file was changed.
|
||||||
|
|
||||||
|
Preserve the existing structure:
|
||||||
|
|
||||||
|
- Product: Product Management and Product Design.
|
||||||
|
- Technology: Product Engineering, Platform & IT, Architecture & Security, Quality Engineering, Data & AI.
|
||||||
|
- Operations: Operations Squad; Marketing: Marketing Squad; Finance & Accounting: Finance & Accounting Squad; HR & Administration: People & Administration Squad.
|
||||||
|
- Existing leadership documentation locates AI enablement coordination with the AI Architect within Data & AI, alongside established engineering leadership. Do not invent a new AI department, standing committee, delivery team, or confirmed headcount.
|
||||||
|
|
||||||
|
The requested target is ONE logical SDLC coordinating agent, with people using local Copilot, Claude Code or Cline agents. Logical coordination does not require a single fragile process and does not transfer human accountability to a model. The recommendations below develop this target; they are not a description of present operations.
|
||||||
|
|
||||||
|
## 2. Principal conclusions
|
||||||
|
|
||||||
|
1. Standardize a portable skill content contract, not the fiction of one universal client policy. Agent Skills defines `SKILL.md`, metadata and resources; `allowed-tools` is experimental, and the discovery directory is not mandated by the format.[1][21]
|
||||||
|
2. Treat instructions as guidance. GitHub explicitly warns of nondeterministic instruction following, and Claude describes memory files as context rather than enforced configuration.[3][5] Recommended enforcement belongs in independently administered repository, CI, artifact and release controls.
|
||||||
|
3. Maintain client-specific adapters and an explicit supported version matrix. Current official docs disagree even about collision precedence: Claude enterprise > personal > project; Cline global skill > project skill; Cline rules use the opposite workspace-over-global rule.[4][8][9]
|
||||||
|
4. Assess skill selection, execution, artifact quality and business outcomes separately. Repeated trials and environment-state verification matter more than an agent reporting success.[11]
|
||||||
|
5. Measure a balanced portfolio of flow, quality, risk, cost and human experience. DORA now uses five delivery metrics; SPACE explicitly rejects a single productivity metric.[12][24] Adoption counts or accepted code are not causal productivity evidence.
|
||||||
|
6. Use comparative pilots, not an imported percentage ROI. Controlled studies have reported substantial speedups and slowdowns in different settings, and METR's newer study explains why selection and concurrent-agent timing make current effects difficult to estimate.[16][17][22]
|
||||||
|
|
||||||
|
## 3. Compatibility and enforcement matrix
|
||||||
|
|
||||||
|
Every capability below is documented upstream, not exercised in Eldorado. A supported client means a particular host, version, model configuration and OS combination that passes local conformance tests; a product brand alone is insufficient.
|
||||||
|
|
||||||
|
| Dimension | GitHub Copilot | Claude Code | Cline |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| Skills and scope | Project `.github/skills`, `.claude/skills`, `.agents/skills`; personal `~/.copilot/skills`, `~/.agents/skills`. About page includes cloud agent, code review, CLI, app, VS Code and JetBrains agent mode.[2] | Common format plus invocation controls, subagents and dynamic context extensions. Native project/personal `.claude/skills`; enterprise and nested scopes also documented.[4] | Workspace `.cline/skills`, global `~/.cline/skills`; explicit invocation and enabled-by-default toggles documented.[8] |
|
||||||
|
| Always-on instructions | Repository-wide `.github/copilot-instructions.md`, path-specific files and agent instructions have surface-dependent support. Do not apply the GitHub.com hierarchy to every IDE.[3] | `CLAUDE.md` and related discovered memory files are concatenated into context, not overriding configuration files.[5] | Workspace/global rules combine, with workspace taking precedence for conflicts; toggles may disable rules.[9] |
|
||||||
|
| Name collision / precedence | Inspected docs establish instruction precedence on GitHub.com, not a universal skill-name collision order. Test duplicate personal/project skills before approval.[3] | Enterprise skill over personal over project for same-name collisions; distinct from memory-file concatenation.[4][5] | Global skill over project skill, but workspace rules over global rules. Do not conflate them.[8][9] |
|
||||||
|
| Trust and execution | GitHub warns shared skills are not verified, may contain injection or malicious scripts, and shell preapproval can remove a protective confirmation.[26] | Trust/permission dialogs and sandbox capability exist, but approved shell access can exceed working directory; unattended sessions differ.[7] | User toggles do not establish an enterprise security boundary. Current hook landing page redirects to SDK plugin documentation, which describes executable plugins.[8][10][23] |
|
||||||
|
| Hooks and enforcement | No universal Copilot hook parity established by inspected sources. Do not promise a portable hook API or use absence of research as proof none exists. | PreToolUse supports blocking, but command/http/MCP timeout does NOT block automatically; plain exit 1 is generally nonblocking without valid decision JSON. Agent SDK callbacks differ.[6] | SDK documents lifecycle hooks and explicit `fail_closed` policy. This is not proof every IDE/CLI installation exposes identical configuration or failure semantics.[23] |
|
||||||
|
| Distribution | Repository content can travel with code. `gh skill` public preview documents installation, source provenance, `@SHA` and `--pin`; pinned skills are skipped in updates.[26] | Repository/managed deployment plus client-specific facilities. Use an external immutable bundle manifest; do not presume Copilot's installer or plugin semantics apply unchanged.[4] | Commit workspace skill directories for team sharing. SDK plugins can come from npm/git/file sources; these require separate software-supply-chain review.[8][23] |
|
||||||
|
| Telemetry | Usage API spans multiple surfaces, but rich IDE detail requires telemetry; server-side active-user recovery does not fill missing dimensional data.[19] | OTel supports configured usage/cost/tool export; detailed skill names/tool arguments require explicit collection settings. Version-specific behavior is substantial.[20] | SDK lifecycle hooks provide instrumentation building blocks, not proof of a ready-made comparable enterprise skill dashboard or retention contract.[23] |
|
||||||
|
| Portable guarantee | Readable common content only; neither skill selection nor correct execution follows from installation.[3][26] | Shared format does not standardize extension behavior or guarantee instruction adherence.[4][5] | Shared content and client behavior remain different; toggles and name shadowing affect what executes.[8][9] |
|
||||||
|
|
||||||
|
### Version pinning, updates, rollback and stale laptops — recommended operational contract
|
||||||
|
|
||||||
|
These are recommended design choices, not features claimed to exist universally:
|
||||||
|
|
||||||
|
- Maintain one reviewed registry with stable skill IDs, human owner/reviewer, purpose, risk tier, provenance/license, immutable source revision, artifact digest, dependencies, supported client/OS/version range, evaluation revision/results, approval record, last review date, deprecation state, migration guide and rollback digest. Keep client-specific invocation and tool configuration outside the portable core, generated and tested as adapters.
|
||||||
|
- Release a manifest mapping stable IDs to exact immutable content and adapter revisions. Pin full commit/digest, not a mutable branch or tag alone. GitHub's preview installer provides pin/provenance mechanisms, but private Gitea compatibility and availability on Eldorado laptops have not been established.[26] A controlled vendored bundle is the simpler cross-client recommendation until proven otherwise.
|
||||||
|
- Promotion: author branch → independent review → format/resource validation → script/dependency/security checks → per-client behavioral and adversarial evals → canary → approval → distribution. Never permit a proposed skill to approve itself or edit its own promotion checks without independent review.
|
||||||
|
- Updates: compare signed/verified manifest and content digest; show release notes; stage atomically; restart/reload affected sessions where required by the client. Test whether already-open sessions retain old instructions. Do not infer reload from files changing.
|
||||||
|
- Rollback: restore a previously approved manifest AND adapter/dependency versions, revoke the unsafe revision centrally, expire affected sessions, rerun a smoke test and read back effective version. Reverting a file does not undo commands already executed or leaked data.
|
||||||
|
- Offline laptop: a verified cached bundle can support permitted low-risk local drafting, provided required local model/tool dependencies actually work offline. Local files being present do not mean cloud-backed inference is offline-capable. No claim of native offline inference or guaranteed durable telemetry buffering is made for any client.
|
||||||
|
- Stale/unsupported bundle: show a visible warning and prevent high-risk centrally mediated actions; allow explicitly approved low-risk work only. Recommended grace periods are risk decisions to settle, not fabricated vendor defaults. On reconnect, revalidate revocation and support status before obtaining privileged credentials or submitting gated delivery actions.
|
||||||
|
- Laptop evidence is fallible and may be altered by its owner. CI should verify repository-delivered manifest/content and actual output, but cannot prove which private prompt or skill a laptop truly used. Treat client attestations as advisory unless an independently verified device/runtime trust mechanism exists. Central enforcement must still protect work with no attestation.
|
||||||
|
- Avoid conflicting names and broad user-directory installation; prefix governed IDs and detect shadowing. Keep an explicit exception route with owner, scope, justification, expiry and compensating checks. An exception must not quietly disable protected-release controls.
|
||||||
|
|
||||||
|
## 4. Conflicts, weak evidence and what not to conclude
|
||||||
|
|
||||||
|
| Claim / conflict | Classification and resolution |
|
||||||
|
| --- | --- |
|
||||||
|
| “Project skills universally override user skills.” | Contradicted as a universal claim. Agent Skills implementation guide says this; current Claude and Cline product docs specify personal/global priority for skill collisions. Weight actual client documentation for that client, then verify behavior locally.[21][4][8] |
|
||||||
|
| “GitHub organization instructions enforce company policy everywhere.” | Unsupported. GitHub documents limited surfaces, personal/repository precedence, nondeterminism and head-branch review instructions. Use repository ownership and independently protected gates instead.[3] |
|
||||||
|
| “All clients support the same skills/hooks/telemetry.” | Unsupported. Standard content exists, but scope, extensions, hooks and instrumentation differ. Cline's hook page now points to SDK plugins; do not repeat historical hook file recipes without version testing.[1][10][23] |
|
||||||
|
| “Copilot supports JetBrains skills.” | About-skills page explicitly includes JetBrains; adding-skills overview currently omits it. This is documentation asymmetry, not sufficient evidence to declare unsupported. Verify the exact target host/version during adapter qualification.[2][26] |
|
||||||
|
| “Hook failure blocks dangerous work.” | Not generically true. Claude documents nonblocking timeout and exit-code cases; Cline SDK offers an explicit fail-closed setting. Test timeout, crash and malformed output separately.[6][23] |
|
||||||
|
| “AI makes developers 55.8% faster.” | Supported paraphrase only for Peng et al.'s controlled JavaScript HTTP-server task; abstract inspected. Not a software-organization forecast.[17] |
|
||||||
|
| “AI makes experienced developers 19% slower today.” | Misleading temporal/generalized claim. METR's early-2025 RCT involved 16 developers and 246 issues; the authors now label those results outdated as current capability evidence.[16] |
|
||||||
|
| “METR's newer results prove a universal speedup.” | Unsupported. Follow-up raw estimates suggest shorter task time, but intervals include no effect and authors warn participant/task selection and parallel-agent timing compromise the estimate.[22] |
|
||||||
|
| “Independent study proves a 21% Eldorado improvement.” | Unsupported. Paradis et al.'s abstract reports approximately 21% shorter task time for 96 Google engineers, with a large interval and explicit ecosystem/generalization caveats. Primary abstract, not full methods, inspected.[18] |
|
||||||
|
| “Agent says done / skill was loaded, therefore compliant.” | Unsupported. Outcome must be inspected in the environment; selection, reading, following, tool execution and outcome are separate observations.[11] |
|
||||||
|
|
||||||
|
Research hygiene correction: the initial URL seed for arXiv `2410.12944` was mistakenly labelled as a Cui field-experiments source. The retrieved body is Paradis et al.'s Google RCT; `sources.json` records the correct identity. No Cui statistic is used. Likewise, ACM SPACE returned HTTP 403; an author-hosted Microsoft Research publication summary was retrieved instead. These are bounded acquisition limitations, not invented evidence.
|
||||||
|
|
||||||
|
## 5. Target coordination, authority and organization mapping
|
||||||
|
|
||||||
|
Recommended trust flow: people and approved work records → one logical SDLC coordinator → task-scoped local-agent work proposals → repository review → independently administered CI/artifact evidence → authorized human release decision → release service. The coordinator should maintain workflow state, dependencies, requested evidence, retries and escalation. It should not be sole author, evaluator and approver, nor hold unrestricted production credentials.
|
||||||
|
|
||||||
|
Use durable IDs, idempotent task transitions and bounded retry budgets so multiple coordinator replicas cannot publish twice. Keep a human takeover and deterministic queue/authorization path if inference is unavailable. Project-level context sharing must be deliberately scoped; shared coordination is not permission to mix secrets, HR records, customer disputes and source code.
|
||||||
|
|
||||||
|
| Existing owner | Recommended accountability, without creating teams |
|
||||||
|
| --- | --- |
|
||||||
|
| Product Management | Choose outcome hypotheses and eligible work; accept product value and prioritize pilots rather than maximize AI usage. |
|
||||||
|
| Product Design | Validate usability/accessibility and customer research handling; review generated experience changes and design-task skills. |
|
||||||
|
| Product Engineering | Own code, practical skill authoring and local-agent use; review generated changes and remain responsible for maintainability. |
|
||||||
|
| Platform & IT | Own bundle delivery, device/client support, identity, workload isolation, central CI/release integration, telemetry transport and emergency revocation. |
|
||||||
|
| Architecture & Security | Own trust boundaries, data/permission risk classification, supply-chain approval requirements and security exceptions; review privileged skill proposals. |
|
||||||
|
| Quality Engineering | Own independent regression/adversarial suites, quality rubrics, gate evidence, failure sampling and evaluation reproducibility. |
|
||||||
|
| Data & AI | Coordinate the skills catalog and logical SDLC-agent evaluation with the documented AI Architect function; own statistical analysis and model/client experiment design. |
|
||||||
|
| Operations Squad | Supply sanitized service cases and operational acceptance; own human decisions on disputes, refunds, fraud and customer communications, not the coordinator. |
|
||||||
|
| Marketing Squad | Own brand/claim review, campaign approval and content rights; start with drafting/review skills rather than autonomous spending or publication. |
|
||||||
|
| Finance & Accounting Squad | Validate cost allocation and investment evidence; retain payout, accounting and financial approval segregation. |
|
||||||
|
| People & Administration Squad | Own training, onboarding, acceptable use and privacy-sensitive adoption feedback, with Platform & IT on access lifecycle; no individual developer ranking. |
|
||||||
|
|
||||||
|
Department leaders retain business accountability. Staffing capacity, named approvers and deputies need human confirmation; the operating-model role description is not evidence that every position is filled. For synthesis, map recommendations to existing responsibilities rather than publish uncertain staffing as fact.
|
||||||
|
|
||||||
|
### Threat and failure controls
|
||||||
|
|
||||||
|
NIST supplies a voluntary lifecycle governance framework and GenAI companion, not certification; the RMF core organizes work around govern, map, measure and manage.[13][14][25]
|
||||||
|
|
||||||
|
OWASP identifies external-content injection and recommends least privilege, human approval and adversarial testing.[15]
|
||||||
|
|
||||||
|
Recommended controls by failure mode:
|
||||||
|
|
||||||
|
- Malicious skill, script, dependency, MCP server or changed upstream tag: allowlisted source, immutable digest, independent review, license/provenance inventory, restricted network/runtime and no automatic arbitrary installs. A reviewed Markdown file does not make referenced executable code safe.
|
||||||
|
- Prompt injection from issues, repository instructions, web pages or tool results: treat as untrusted input; separate data from authority; limit credentials and egress; require independent authorization. GitHub code review's use of PR-head instructions is a concrete reason not to trust AI review as the sole gate.[3][15]
|
||||||
|
- Fabricated success, omitted tests, cherry-picked evidence or judge manipulation: verify actual artifact/CI state tied to exact commit and policy revision; keep evaluation checks outside candidate-controlled changes; sample human review.
|
||||||
|
- Overbroad local shell permissions: isolate process/OS identity, filesystem, network and secrets. A profile, skill folder or current directory is not containment. Claude's own docs distinguish permission prompts from sandbox controls.[7]
|
||||||
|
- Duplicate or looping agent work, runaway spend and unavailable coordinator: task idempotency, bounded retries/time/cost, lease expiry, human recovery and read-only/degraded mode. Never downgrade a release gate because the model or evidence service is unavailable.
|
||||||
|
- Model/client/context drift or stale session instructions: version-qualified adapters; requalification on material updates; compaction/long-session tests; version-aware incident analysis.
|
||||||
|
- Privacy leakage through telemetry or shared memory: minimal structured events, pseudonymous IDs, restricted retention and access; no raw prompts, secrets or source contents by default. Explicitly review the privacy cost before enabling detailed tool/skill-name export.[20]
|
||||||
|
- Kill switch: independently revoke mutation/release credentials and stop scheduling; disable affected revisions and preserve evidence. Sending “stop” to a model is not the security boundary.
|
||||||
|
|
||||||
|
## 6. Skill quality, evaluation and lifecycle recommendations
|
||||||
|
|
||||||
|
A useful skill must state when to use it, when not to use it, prerequisites, exact steps, expected artifacts, verification, failure handling and escalation. Keep the portable body small and reference bounded resources. The format specification supports progressive disclosure and recommends concise main files.[1]
|
||||||
|
|
||||||
|
Proposed evaluation layers:
|
||||||
|
|
||||||
|
1. Static contract: parse metadata; verify stable identity/owner/review date; validate links and resource paths; detect embedded secrets, prohibited dependencies, unsafe commands and unsupported client-only fields.
|
||||||
|
2. Selection tests: positive trigger tasks, near misses and negative tasks; report false activation and missed activation separately. A larger catalog should be tested for routing regressions, not presumed better.
|
||||||
|
3. Execution tests: run representative sanitized tasks in disposable environments with fixed starting repositories; verify real outputs, not self-reports. Include missing prerequisite, invalid input, tool timeout, denied permission, malformed evidence and interrupted session.
|
||||||
|
4. Safety tests: injected repository text, malicious referenced scripts, conflicting global/project skills, user toggle, unsupported version, expired/revoked bundle, offline network, context compaction and stale in-memory version.
|
||||||
|
5. Outcome grading: deterministic tests for mechanically checkable constraints; independent human review for product/design/maintainability; model judges only with explicit rubric and human calibration. Record disagreements and judge version.[11]
|
||||||
|
6. Comparison: same tasks and conditions for no-skill/current-approved/candidate versions; repeated trials, failure/abandonment retained; separate client/model/skill changes. Report sample size, variability, confidence and task mix, not only a mean pass percentage.[11]
|
||||||
|
|
||||||
|
Recommended promotion policy: all mandatory deterministic safety/authorization checks must pass; any observed critical unauthorized action blocks promotion pending investigation. This is a proposed policy, NOT proof of zero residual risk. Quantitative success-rate thresholds should be set after pilot variance and business impact are known, by risk tier; do not invent universally validated percentages. Privileged release/payment/customer-impact workflows need stronger review than read-only documentation assistance.
|
||||||
|
|
||||||
|
Lifecycle: proposed → experimental → approved → deprecated → retired, with quarantine available from every active state. Review triggered by incident, tool/model/client change, dependency change, usage feedback or scheduled owner review. Each approved skill needs an owner and backup, change history, support window, migration route and known-good rollback. Deprecation should warn, offer replacement and track consumers before retirement; urgent security revocation overrides convenience. Do not retain unowned skills merely because they remain popular.
|
||||||
|
|
||||||
|
Adoption should begin with training on how to inspect results, report failures and refuse unsafe requests. Build examples from actual team workflows; offer office hours and opt-in feedback; record why a skill was rejected. Measure whether people can perform and verify work, not whether they obey a target number of invocations. Avoid automatically promoting agent-written corrections into the governed catalog.
|
||||||
|
|
||||||
|
## 7. KPI instrumentation options and recommended choices
|
||||||
|
|
||||||
|
### Practical source tiers
|
||||||
|
|
||||||
|
A. Start with authoritative repository/CI/deployment/incident events. These can measure delivery outcomes without observing every laptop prompt. No event feed has been inspected here; feasibility must be verified with the current hosting platforms and retention.
|
||||||
|
|
||||||
|
B. Add a governed catalog/version inventory and opt-in task-level skill/client declarations. This supplies adoption and support coverage, but declarations are not proof of execution or adherence.
|
||||||
|
|
||||||
|
C. Add client adapters where supported: Copilot usage APIs and Claude OTel may help; their fields, licensing, enabled state and missingness differ.[19][20] Cline SDK hooks are an instrumentation option requiring engineering and exact-version qualification, not a proven universal collector.[23]
|
||||||
|
|
||||||
|
D. Use short anonymous surveys, work sampling and pilot comparisons for cognitive load, confidence and rework not visible in logs. SPACE's multidimensional premise supports this combination; surveys alone cannot establish time saved.[24][16]
|
||||||
|
|
||||||
|
### Candidate measurement contracts for synthesis
|
||||||
|
|
||||||
|
These are recommended options, not observed metrics or approved targets. All denominators must use a predeclared eligible population and reporting window; zero denominators produce “not available,” never zero performance.
|
||||||
|
|
||||||
|
| Measure | Definition and useful source | Owner / interpretation / missingness |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Validated task success | Independently accepted successful tasks / all eligible initiated tasks with matured observation window; count failed/abandoned tasks as nonsuccess and show still-open separately. Task ID + acceptance evidence, not agent message. | Quality Engineering; weekly pilot report. Show task type, sample size and unobserved outcomes separately; exclude cancelled-before-start work by stated rule, not post-hoc cherry-picking. |
|
||||||
|
| Skill selection precision / recall | Correct relevant activations / all activations; relevant tasks with activation / all relevant tasks, on a labeled evaluation set. | Data & AI with Quality Engineering; per candidate/client release. Not obtainable from skill-loaded logs without relevance labels. |
|
||||||
|
| Supported bundle coverage | Eligible active installations with verified supported revision / eligible active installations inventoried. | Platform & IT; weekly. Unknown/invisible laptops remain unknown and inventory coverage is separately reported; do not treat silence as compliant. |
|
||||||
|
| Useful adoption | Distinct eligible participants using an approved skill in an eligible workflow / eligible participants during window, plus qualitative usefulness. | Data & AI and People & Administration Squad; monthly aggregate. Separate declared, observed and inferred usage; suppress small cohorts and never rank people. |
|
||||||
|
| Change lead time | Commit-to-production elapsed time per deployed change; report distribution and population. Repository + deployment SHA association. | Platform & IT / Product Engineering; service-level trend. Missing SHA mapping is missing coverage, not instantaneous delivery. DORA definition, not PR-open-to-merge time.[12] |
|
||||||
|
| Deployment frequency | Production deployments / stated period, service-scoped. | Platform & IT; report with quality measures. Exclude retries/duplicate events; no incentive to split meaningless deployments.[12] |
|
||||||
|
| Change fail rate | Production deployments requiring immediate intervention / all production deployments. | Quality Engineering / Platform & IT; require incident/rollback linkage and intervention definition. Missing incident links limit confidence.[12] |
|
||||||
|
| Failed deployment recovery time | Recovery timestamp minus failed-deployment failure timestamp; distribution over relevant failed deployments. | Platform & IT; unresolved failures shown separately, never dropped as if recovered. Not all-incident MTTR.[12] |
|
||||||
|
| Deployment rework rate | Unplanned incident-driven production deployments / all production deployments. | Platform & IT; preserve planned/unplanned classification and incident link. DORA fifth metric, distinct from change fail rate.[12] |
|
||||||
|
| Escaped quality issues | Severity-stratified post-acceptance defects / accepted changes with completed follow-up, plus absolute incident counts. | Quality Engineering; agreed maturation window. Do not compare immature and mature cohorts or imply every defect was AI-caused. |
|
||||||
|
| Safety / policy violations | Confirmed prohibited actions or attempted bypasses / evaluated eligible runs, with severe incidents also as absolute counts. | Architecture & Security; immediate incident response and periodic trend. Separate detected attempts, blocked attempts and actual effects; zero observed is not proof of no risk. |
|
||||||
|
| Cost per accepted outcome | Allocated license + model/tool/compute + human review/rework costs / independently accepted outcomes; include costs of failed/abandoned attempts in numerator. | Finance & Accounting Squad; monthly. Show uncertain allocation and missing spend; do not call model tokens the whole cost. |
|
||||||
|
| Human experience | Aggregate survey distribution for cognitive load, confidence in verification and perceived usefulness, with response count / invited eligible population. | People & Administration Squad / Data & AI; periodic. Self-selection and perception bias explicit; no employee surveillance dashboard. |
|
||||||
|
| Maintenance health | Approved skills within review window / active approved skills; separately count ownerless, deprecated-in-use and revoked-in-use revisions. | Data & AI / Platform & IT; catalog release and periodic review. Review stamp alone is not quality evidence. |
|
||||||
|
|
||||||
|
Recommended minimal event schema: `event_id`, `schema_version`, `event_type`, `occurred_at`, `received_at`, `producer`, `task_id`, `attempt_id`, `project_id`, `pseudonymous_actor_id` where necessary, `client/host/version`, `model_id/version_if_exposed`, `skill_id/revision/digest`, `adapter_revision`, `policy_revision`, `repo_commit`, `outcome`, `reason_code`, `evidence_ref`, `cost_amount/currency/basis`, `measurement_origin` (server/client/self-report), and `consent_or_collection_basis`. Fields can be nullable with reason; do not fabricate a model revision hidden by a provider.
|
||||||
|
|
||||||
|
Recommended ingestion rules: deduplicate by producer + event_id; model retries as attempts, not extra completed tasks; preserve late events and recompute versioned aggregates; use server receipt and skew checks rather than trusting laptop clocks blindly. A lost terminal event is unknown until reconciled, not automatically success or abandonment. Distinguish paused, failed, abandoned, cancelled-before-start and accepted. A skill-loaded event records loading only. A task can involve multiple skills/versions and agents; avoid attributing the entire outcome or labor time to every invocation.
|
||||||
|
|
||||||
|
Suggested privacy starting point for human approval: short raw structured-event retention (for example 30 days), longer aggregate trends (for example 12 months), no raw prompts/code/screens by default, role-limited incident evidence, and explicit deletion/access process. These durations are policy proposals, not legal requirements or existing Eldorado settings. Confirm employment/privacy constraints with responsible owners before collection.
|
||||||
|
|
||||||
|
Pilot comparison recommendation: define task classes and quality acceptance first; collect a prospective baseline and eligible population; compare matched or randomized cohorts when ethical/practical; record concurrent process/client/model changes. Keep quality and risk guardrails fixed. Report descriptive trends separately from causal estimates. Measure elapsed lead time and human effort separately because parallel agents break the assumption that elapsed time equals labor saved; METR's follow-up explicitly raises this issue.[22]
|
||||||
|
|
||||||
|
For executable downstream examples, use clearly synthetic fixtures covering duplicates, retries, unknown outcomes, multiple skills, zero denominator, immature quality window and late deployment/incident events. Assert exact expected numerator/denominator and units. Do not display synthetic values as Eldorado baseline data.
|
||||||
|
|
||||||
|
## 8. Recommended sequence and evidence gates
|
||||||
|
|
||||||
|
- Foundation: inventory actual clients, repositories, data sensitivity, available events and accountable owners. Exit only with a supported pilot boundary and explicit forbidden actions, not with a catalog full of untested skills.
|
||||||
|
- Low-risk pilot: small set of useful read-only/drafting/test-assistance skills; reviewed immutable bundles; exact-client smoke and adversarial tests; human review and failure reporting. Exit with reproducible quality evidence and usable measurement coverage.
|
||||||
|
- Governed distribution: add version-aware adapters, onboarding, staged upgrades, rollback/revocation drills and exception expiry. Exit when stale/offline/unsupported clients cannot bypass central privileged gates.
|
||||||
|
- Logical SDLC coordination: coordinator starts by observing and assembling evidence, then proposing work and routing approvals. Expand mutation only after idempotency, separation of duties, scoped credentials, outage recovery and kill-switch tests pass.
|
||||||
|
- Broader departmental use: Operations, Marketing, Finance & Accounting and HR & Administration adopt domain-specific skills with their own human decisions, data boundaries and outcome measures. Do not copy coding autonomy into payments, personnel decisions or disputes.
|
||||||
|
|
||||||
|
No invented rollout dates, budget, staffing capacity or required improvement percentage. Scale only when quality, risk and cost evidence support it; stop or narrow scope when benefits are not demonstrated.
|
||||||
|
|
||||||
|
## 9. Source coverage and unresolved questions
|
||||||
|
|
||||||
|
Coverage: 26 retrieved primary-source records with 50 literal evidence passages. Includes Agent Skills specification and integration guidance; GitHub support/instructions/install/metrics; Claude skills/memory/hooks/security/monitoring; Cline skills/rules/hooks and linked SDK plugins; agent-evaluation methodology; current DORA definitions; author-hosted SPACE summary; NIST framework/core/GenAI profile landing page; OWASP prompt injection; two primary research abstracts plus METR historical study and 2026 follow-up. This is substantive source-body review, but not a systematic literature review, independent replication, legal assessment or live client qualification. Full PDFs for the two arXiv papers and NIST GenAI profile were not reviewed; claims are limited accordingly. ACM's 403 is recorded and resolved only to the author-hosted summary, not bypassed or silently called full text.
|
||||||
|
|
||||||
|
Open decisions/evidence needed before implementation:
|
||||||
|
|
||||||
|
1. Which actual client hosts, versions, models, OSs, subscriptions and managed-device controls are in use? What is the allowed support window?
|
||||||
|
2. Which repository/CI/release systems and protected-branch controls are authoritative? Can required checks and policy definitions be altered by a candidate PR or bypassed by administrators?
|
||||||
|
3. Who fills each approving/operating function and who provides cover? What pilot capacity is available? The documented organization does not establish personnel availability.
|
||||||
|
4. What data may reach each model provider or telemetry endpoint; what retention/training/region and contractual terms apply? No provider contract was inspected.
|
||||||
|
5. Which low-risk workflows have enough representative tasks and independent quality labels? What is the actual eligible population and baseline coverage?
|
||||||
|
6. What timeout, stale-bundle grace, critical-risk rejection and emergency-revocation policies will owners approve? Can laptop access be independently revoked?
|
||||||
|
7. Does the chosen distributor support private Gitea securely, and can every supported client report effective skill/adapter versions without collecting sensitive content?
|
||||||
|
8. What causal claims, if any, can the proposed pilot design justify given self-selection, learning, task mix and parallel work?
|
||||||
|
9. Which detailed Cline/Copilot hooks and offline/resume behavior exist in the precise deployed builds? Sources here do not establish cross-client equivalence.
|
||||||
|
|
||||||
|
Synthesis handoff: keep this research trail outside reader-facing portal prose. Use ordinary operating-model language for the strategy, preserve all existing teams and leadership uncertainty, visibly distinguish target maturity from current state, and retain recommendation/source mapping internally. No portal publication is part of this research card.
|
||||||
|
|
||||||
|
## Sources
|
||||||
|
|
||||||
|
[1] https://agentskills.io/specification — Agent Skills specification
|
||||||
|
[2] https://docs.github.com/en/copilot/concepts/agents/about-agent-skills — Copilot Agent Skills
|
||||||
|
[3] https://docs.github.com/en/copilot/concepts/prompting/response-customization — Copilot custom instructions
|
||||||
|
[4] https://code.claude.com/docs/en/skills — Claude Code skills
|
||||||
|
[5] https://code.claude.com/docs/en/memory — Claude Code memory
|
||||||
|
[6] https://code.claude.com/docs/en/hooks — Claude Code hooks
|
||||||
|
[7] https://code.claude.com/docs/en/security — Claude Code security
|
||||||
|
[8] https://docs.cline.bot/customization/skills — Cline skills
|
||||||
|
[9] https://docs.cline.bot/customization/cline-rules — Cline rules
|
||||||
|
[10] https://docs.cline.bot/customization/hooks — Cline hooks
|
||||||
|
[11] https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents — Demystifying evals for AI agents
|
||||||
|
[12] https://dora.dev/guides/dora-metrics — DORA software delivery metrics
|
||||||
|
[13] https://www.nist.gov/itl/ai-risk-management-framework — NIST AI RMF
|
||||||
|
[14] https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence — NIST Generative AI Profile
|
||||||
|
[15] https://genai.owasp.org/llmrisk/llm01-prompt-injection — OWASP prompt injection
|
||||||
|
[16] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study — Experienced developer RCT
|
||||||
|
[17] https://arxiv.org/abs/2302.06590 — AI developer productivity experiment
|
||||||
|
[18] https://arxiv.org/abs/2410.12944 — Field experiments in software development
|
||||||
|
[19] https://docs.github.com/en/copilot/concepts/billing-and-usage/copilot-usage-metrics/copilot-metrics — Copilot metrics concepts
|
||||||
|
[20] https://code.claude.com/docs/en/monitoring-usage — Claude Code monitoring
|
||||||
|
[21] https://agentskills.io/client-implementation/adding-skills-support — Agent Skills security
|
||||||
|
[22] https://metr.org/blog/2026-02-24-uplift-update — METR productivity update 2026
|
||||||
|
[23] https://docs.cline.bot/sdk/plugins — Cline SDK plugins
|
||||||
|
[24] https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think — SPACE research publication
|
||||||
|
[25] https://airc.nist.gov/airmf-resources/airmf/5-sec-core — NIST AI RMF Core
|
||||||
|
[26] https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills — Copilot adding skills
|
||||||
@@ -0,0 +1,564 @@
|
|||||||
|
[
|
||||||
|
{
|
||||||
|
"id": 1,
|
||||||
|
"title": "Agent Skills specification",
|
||||||
|
"url": "https://agentskills.io/specification",
|
||||||
|
"publisher": "Agent Skills",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.189577+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "The specification defines a skill directory with SKILL.md, not a universal deployment or enforcement service.",
|
||||||
|
"evidence": "A skill is a directory containing, at minimum, a SKILL.md file:",
|
||||||
|
"limitations": "Format compatibility does not certify discovery, precedence, tool permissions, safety, or instruction compliance."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "allowed-tools is experimental in the common specification.",
|
||||||
|
"evidence": "allowed-toolsNoSpace-separated string of pre-approved tools the skill may use. (Experimental)",
|
||||||
|
"limitations": "Format compatibility does not certify discovery, precedence, tool permissions, safety, or instruction compliance."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/01.txt",
|
||||||
|
"body_sha256": "0913e84055bc7eb05649aa49123a783dc1a413e4c31d0861f9ac367849c7b00e",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 2,
|
||||||
|
"title": "Copilot Agent Skills",
|
||||||
|
"url": "https://docs.github.com/en/copilot/concepts/agents/about-agent-skills",
|
||||||
|
"publisher": "GitHub",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.333904+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "GitHub documents skill support across specified Copilot surfaces, not all modes indiscriminately.",
|
||||||
|
"evidence": "Agent skills work with Copilot cloud agent, Copilot code review, the GitHub Copilot CLI, the GitHub Copilot app, and agent mode in Visual Studio Code and JetBrains IDEs.",
|
||||||
|
"limitations": "Vendor documentation, not an Eldorado installation test. Separate adding-skills page omits JetBrains in its overview; validate exact host/version."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Copilot documents multiple project skill paths.",
|
||||||
|
"evidence": "Project skills, stored in your repository (.github/skills, .claude/skills, or .agents/skills)",
|
||||||
|
"limitations": "Vendor documentation, not an Eldorado installation test. Separate adding-skills page omits JetBrains in its overview; validate exact host/version."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/02.txt",
|
||||||
|
"body_sha256": "26c86bc2afa4813c46361429f015f687164a69f39030fa05dbc1f513a04c0ca3",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 3,
|
||||||
|
"title": "Copilot custom instructions",
|
||||||
|
"url": "https://docs.github.com/en/copilot/concepts/prompting/response-customization",
|
||||||
|
"publisher": "GitHub",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.960265+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "GitHub explicitly warns that custom-instruction following is nondeterministic.",
|
||||||
|
"evidence": "Due to the non-deterministic nature of AI, Copilot may not always follow your custom instructions in exactly the same way every time they are used.",
|
||||||
|
"limitations": "Instruction precedence is surface-specific and is not enforceable authorization. Head-branch instructions create a review trust risk."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "The GitHub.com instruction hierarchy prioritizes personal over repository over organization instructions.",
|
||||||
|
"evidence": "Multiple types of custom instructions can apply to a request sent to Copilot. Personal instructions take the highest priority. Repository instructions come next, and then organization instructions are prioritized last. However, all sets of relevant instructions are provided to Copilot.",
|
||||||
|
"limitations": "Instruction precedence is surface-specific and is not enforceable authorization. Head-branch instructions create a review trust risk."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Copilot review reads instructions and skills from the PR head branch.",
|
||||||
|
"evidence": "When reviewing a pull request, Copilot reads repository custom instructions, agent instructions, and agent skills from the head branch (the branch with your changes), not the base branch. For example, when merging my-feature-branch into main, Copilot uses the instructions and skills in my-feature-branch, so you can test changes to them in the same pull request without merging them first.",
|
||||||
|
"limitations": "Instruction precedence is surface-specific and is not enforceable authorization. Head-branch instructions create a review trust risk."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/03.txt",
|
||||||
|
"body_sha256": "1c2c190052653b8baad1478dc53b7a0657b741be0dbb0ef202b3f503c6b3379c",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 4,
|
||||||
|
"title": "Claude Code skills",
|
||||||
|
"url": "https://code.claude.com/docs/en/skills",
|
||||||
|
"publisher": "Anthropic",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.088978+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Claude skill name collisions prioritize enterprise over personal over project.",
|
||||||
|
"evidence": "Two of enterprise, personal, and projectEnterprise over personal, and personal over project. With deploy in both ~/.claude/skills/ and the project’s .claude/skills/, /deploy runs the personal one",
|
||||||
|
"limitations": "Vendor extensions and changing versions prevent assuming cross-client parity. No local client exercised."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Claude extends the common skill format with client-specific functionality.",
|
||||||
|
"evidence": "Claude Code skills follow the Agent Skills open standard, which works across multiple AI tools. Claude Code extends the standard with additional features like invocation control, subagent execution, and dynamic context injection. See Using skill frontmatter outside Claude Code for which frontmatter fields are part of the standard and which are Claude Code extensions.",
|
||||||
|
"limitations": "Vendor extensions and changing versions prevent assuming cross-client parity. No local client exercised."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/04.txt",
|
||||||
|
"body_sha256": "4ac3de187f2ba050da149e1bea3364a959366be03963e7a76dc9f9041bdb4e1f",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 5,
|
||||||
|
"title": "Claude Code memory",
|
||||||
|
"url": "https://code.claude.com/docs/en/memory",
|
||||||
|
"publisher": "Anthropic",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:52.994293+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Claude memory instructions are context, not enforced configuration.",
|
||||||
|
"evidence": "Claude Code has two complementary memory systems. Both are loaded at the start of every conversation. Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead. The more specific and concise your instructions, the more consistently Claude follows them.",
|
||||||
|
"limitations": "Context order does not establish deterministic behavior; conflicting prose may still produce arbitrary choices."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Claude concatenates discovered memory files rather than treating them as override-only configuration.",
|
||||||
|
"evidence": "All discovered files are concatenated into context rather than overriding each other. Across the directory tree, content is ordered from the filesystem root down to your working directory. For the foo/bar/ example, foo/CLAUDE.md appears in context before foo/bar/CLAUDE.md, so instructions closer to where you launched Claude are read last. Within each directory, CLAUDE.local.md is appended after CLAUDE.md, so your personal notes are the last thing Claude reads at that level.",
|
||||||
|
"limitations": "Context order does not establish deterministic behavior; conflicting prose may still produce arbitrary choices."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/05.txt",
|
||||||
|
"body_sha256": "b19869f25886f95f8d93cec941482cbf9472b507ab8d643b446b1450b915e0df",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 6,
|
||||||
|
"title": "Claude Code hooks",
|
||||||
|
"url": "https://code.claude.com/docs/en/hooks",
|
||||||
|
"publisher": "Anthropic",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.059984+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Claude PreToolUse command/http/MCP hook timeout is not fail-closed.",
|
||||||
|
"evidence": "A timed-out command, http, or mcp_tool hook doesn’t block the tool call. The call continues through the normal permission flow, so don’t count on a stalled hook to act as a gate.",
|
||||||
|
"limitations": "Event and hook-family distinctions matter; no universal fail-closed promise. No hook was installed or tested here."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "A conventional exit code 1 alone does not reliably block most Claude hook events.",
|
||||||
|
"evidence": "For most hook events, exit code 2 is the only exit code that blocks through the code alone. Without valid JSON on stdout, Claude Code treats exit code 1 as a non-blocking error and proceeds with the action, even though 1 is the conventional Unix failure code. If your hook is meant to enforce a policy, use exit 2. The worktree events differ: any non-zero exit code from WorktreeCreate aborts worktree creation, and any non-zero exit code from WorktreeRemove makes worktree removal fail if the directory still exists afterward.",
|
||||||
|
"limitations": "Event and hook-family distinctions matter; no universal fail-closed promise. No hook was installed or tested here."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/06.txt",
|
||||||
|
"body_sha256": "ae1919a5b06aa6d4a213bfafcaab1d2473f0b89d53b9fcc35358a19ab9ca3e5d",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 7,
|
||||||
|
"title": "Claude Code security",
|
||||||
|
"url": "https://code.claude.com/docs/en/security",
|
||||||
|
"publisher": "Anthropic",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:52.953904+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Claude working-directory approval is not OS-level containment.",
|
||||||
|
"evidence": "Working directory boundary: In Manual mode, Claude Code asks you before its file tools read or write outside the folder where it was started and its subfolders. The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can",
|
||||||
|
"limitations": "Vendor capability is not evidence the sandbox is enabled; approved shell commands inherit actual OS authority."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "OS-level Bash restrictions require sandboxing.",
|
||||||
|
"evidence": "To restrict Bash commands at the operating system level, turn on sandboxing",
|
||||||
|
"limitations": "Vendor capability is not evidence the sandbox is enabled; approved shell commands inherit actual OS authority."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/07.txt",
|
||||||
|
"body_sha256": "a8a2ad7d077347f1d3ea43549b0be1070e03c7737647f73ef40035d5dafb5f40",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 8,
|
||||||
|
"title": "Cline skills",
|
||||||
|
"url": "https://docs.cline.bot/customization/skills",
|
||||||
|
"publisher": "Cline",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.250798+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Cline global skill overrides same-name project skill.",
|
||||||
|
"evidence": "When a global skill and project skill have the same name, the global skill takes precedence. This lets you keep general-purpose skills globally while using project-specific skills in .cline/skills/ so the whole team can use them.",
|
||||||
|
"limitations": "Current docs disagree with Agent Skills guide generalization. Exact installed Cline version remains unknown."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Discovered Cline skills have user-controlled enable/disable toggles.",
|
||||||
|
"evidence": "Every skill has a toggle to enable or disable it. This lets you control which skills are active without deleting the skill directory. Skills are enabled by default when discovered.",
|
||||||
|
"limitations": "Current docs disagree with Agent Skills guide generalization. Exact installed Cline version remains unknown."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/08.txt",
|
||||||
|
"body_sha256": "38e6af22c7e9f78e90e899a7bd285e6556bfd64197fbc3f7cf279cc9ff29d416",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 9,
|
||||||
|
"title": "Cline rules",
|
||||||
|
"url": "https://docs.cline.bot/customization/cline-rules",
|
||||||
|
"publisher": "Cline",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.308915+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Cline workspace rules override conflicting global rules, unlike skill name precedence.",
|
||||||
|
"evidence": "When both workspace and global rules exist, Cline combines them. Workspace rules take precedence when they conflict with global rules. See Storage Locations for more guidance.",
|
||||||
|
"limitations": "Rule precedence is not skill precedence; both are guidance and can be toggled."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/09.txt",
|
||||||
|
"body_sha256": "c1a2353c024491a42961e5ea171c341c66bbed2647464d200bf90fdbaa8a48e3",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 10,
|
||||||
|
"title": "Cline hooks",
|
||||||
|
"url": "https://docs.cline.bot/customization/hooks",
|
||||||
|
"publisher": "Cline",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.370475+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Cline hooks landing page delegates details to SDK plugins.",
|
||||||
|
"evidence": "See details under SDK Plugins page.",
|
||||||
|
"limitations": "Landing page alone proves no event schema or IDE compatibility. SDK page was followed separately."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/10.txt",
|
||||||
|
"body_sha256": "2ebd8cd1c0b11fec466a3b577971382d2c4ec1f9911679b10100029e9b3be095",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 11,
|
||||||
|
"title": "Demystifying evals for AI agents",
|
||||||
|
"url": "https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents",
|
||||||
|
"publisher": "Anthropic",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.451618+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Repeated trials are needed for variable agent outputs.",
|
||||||
|
"evidence": "Each attempt at a task is a trial. Because model outputs vary between runs, we run multiple trials to produce more consistent results.",
|
||||||
|
"limitations": "Vendor-authored methodology and examples, not independent proof of any skill gain or target threshold."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Agent outcome evaluation must inspect environment state rather than trust claimed completion.",
|
||||||
|
"evidence": "The outcome is the final state in the environment at the end of the trial. A flight-booking agent might say “Your flight has been booked” at the end of the transcript, but the outcome is whether a reservation exists in the environment’s SQL database.",
|
||||||
|
"limitations": "Vendor-authored methodology and examples, not independent proof of any skill gain or target threshold."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Agent evals combine code, model and human graders.",
|
||||||
|
"evidence": "Agent evaluations typically combine three types of graders: code-based, model-based, and human. Each grader evaluates some portion of either the transcript or the outcome. An essential component of effective evaluation design is to choose the right graders for the job.",
|
||||||
|
"limitations": "Vendor-authored methodology and examples, not independent proof of any skill gain or target threshold."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/11.txt",
|
||||||
|
"body_sha256": "7940a33d8e19ff68aac5e3c095e0fa771565a4b2416e8a781e9ed02d55668a12",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 12,
|
||||||
|
"title": "DORA software delivery metrics",
|
||||||
|
"url": "https://dora.dev/guides/dora-metrics/",
|
||||||
|
"publisher": "DORA",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.335018+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "DORA now documents five software-delivery performance metrics.",
|
||||||
|
"evidence": "These metrics have evolved alongside the technology landscape: shifting from the original four keys to the current five-metric model. To understand the research behind changes like the move from MTTR to Failed Deployment Recovery Time, read A history of DORA’s software delivery metrics.",
|
||||||
|
"limitations": "Service/team outcome measures, not causal AI-effect estimates or individual productivity scores."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "DORA change lead time runs from commit to production deployment.",
|
||||||
|
"evidence": "Change lead time: The amount of time it takes for a change to go from committed to version control to deployed in production.",
|
||||||
|
"limitations": "Service/team outcome measures, not causal AI-effect estimates or individual productivity scores."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "DORA deployment rework measures unplanned incident-driven deployments.",
|
||||||
|
"evidence": "Deployment rework rate: The ratio of deployments that are unplanned but happen as a result of an incident in production.",
|
||||||
|
"limitations": "Service/team outcome measures, not causal AI-effect estimates or individual productivity scores."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/12.txt",
|
||||||
|
"body_sha256": "0535efe22d238f38d1de5ec655efeb44a313e59f8a71085e902bde5c7a693cb9",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 13,
|
||||||
|
"title": "NIST AI RMF",
|
||||||
|
"url": "https://www.nist.gov/itl/ai-risk-management-framework",
|
||||||
|
"publisher": "NIST",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.731461+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "NIST AI RMF is voluntary guidance for trustworthiness across the AI lifecycle.",
|
||||||
|
"evidence": "Led by the Information Technology Laboratory (ITL) AI Program, and in collaboration with the private and public sectors, NIST has developed a framework to better manage risks to individuals, organizations, and society associated with artificial intelligence (AI). The NIST AI Risk Management Framework (AI RMF) is intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems.",
|
||||||
|
"limitations": "Voluntary framework, not certification, legal advice, or evidence of Eldorado compliance."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/14.txt",
|
||||||
|
"body_sha256": "2fed4e9811f05579384a23b9c3b81600ddf0f011fc4cfe638352a817f91ed603",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 14,
|
||||||
|
"title": "NIST Generative AI Profile",
|
||||||
|
"url": "https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence",
|
||||||
|
"publisher": "NIST",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.743664+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "NIST GenAI profile is a cross-sectoral companion to AI RMF.",
|
||||||
|
"evidence": "This document is a cross-sectoral profile of and companion resource for the AI Risk Management Framework (AI RMF 1.0) for Generative AI, pursuant to President Biden's Executive Order (EO) 14110 on Safe, Secure, and Trustworthy Artificial Intelligence. The AI RMF was released in January 2023, and is intended for voluntary use and to improve the ability of organizations to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems.",
|
||||||
|
"limitations": "Publication landing-page abstract inspected; full PDF not read. Do not attribute detailed risk taxonomy to this excerpt."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/15.txt",
|
||||||
|
"body_sha256": "7998580f4dc83770568dc361ecae1d46e1d652a2df12a278263b88de6cbfb624",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 15,
|
||||||
|
"title": "OWASP prompt injection",
|
||||||
|
"url": "https://genai.owasp.org/llmrisk/llm01-prompt-injection/",
|
||||||
|
"publisher": "OWASP",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.529810+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "External sources can carry prompt injections.",
|
||||||
|
"evidence": "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files. The content may have in the external content data that when interpreted by the model, alters the behavior of the model in unintended or unexpected ways. Like direct injections, indirect injections can be either intentional or unintentional.",
|
||||||
|
"limitations": "Mitigations reduce exposure; no guarantee that prompt injection is eliminated."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "OWASP recommends least privilege.",
|
||||||
|
"evidence": "Provide the application with its own API tokens for extensible functionality, and handle these functions in code rather than providing them to the model. Restrict the model’s access privileges to the minimum necessary for its intended operations.",
|
||||||
|
"limitations": "Mitigations reduce exposure; no guarantee that prompt injection is eliminated."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "OWASP recommends human approval for high-risk operations.",
|
||||||
|
"evidence": "Implement human-in-the-loop controls for privileged operations to prevent unauthorized actions.",
|
||||||
|
"limitations": "Mitigations reduce exposure; no guarantee that prompt injection is eliminated."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/16.txt",
|
||||||
|
"body_sha256": "5bfcc42a422165d0a6b25f28fbff144fc0dec5289f1a672a40203e1d64200c07",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 16,
|
||||||
|
"title": "Experienced developer RCT",
|
||||||
|
"url": "https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/",
|
||||||
|
"publisher": "METR",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:54.289507+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "METR early-2025 RCT found 19% longer task time in its setting.",
|
||||||
|
"evidence": "We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Surprisingly, we find that when developers use AI tools, they take 19% longer than without—AI makes them slower. We view this result as a snapshot of early-2025 AI capabilities in one relevant setting; as these systems continue to rapidly evolve, we plan on continuing to use this methodology to help estimate AI acceleration from AI R&D automation.",
|
||||||
|
"limitations": "Historical narrow setting, tools from early 2025; superseded as a current estimate by authors. No Eldorado forecast."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Study involved 16 experienced developers and 246 issues on their repositories.",
|
||||||
|
"evidence": "To directly measure the real-world impact of AI tools on software development, we recruited 16 experienced developers from large open-source repositories (averaging 22k+ stars and 1M+ lines of code) that they’ve contributed to for multiple years. Developers provide lists of real issues (246 total) that would be valuable to the repository—bug fixes, features, and refactors that would normally be part of their regular work. Then, we randomly assign each issue to either allow or disallow use of AI while working on the issue. When AI is allowed, developers can use any tools they choose (primarily Cursor Pro with Claude 3.5/3.7 Sonnet—frontier models at the time of the study); when disallowed, they work without generative AI assistance. Developers complete these tasks (which average two hours each) while recording their screens, then self-report the total implementation time they needed. We pay developers $150/hr as compensation for their participation in the study.",
|
||||||
|
"limitations": "Historical narrow setting, tools from early 2025; superseded as a current estimate by authors. No Eldorado forecast."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "METR now explicitly marks those historical results as not current.",
|
||||||
|
"evidence": "We have released results that are current as of early 2026, in a continuation of this study. We believe these historical results no longer reflect the current impact of AI models on open-source developer productivity.",
|
||||||
|
"limitations": "Historical narrow setting, tools from early 2025; superseded as a current estimate by authors. No Eldorado forecast."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/17.txt",
|
||||||
|
"body_sha256": "f9abab8a3ad312279800d8327122ebae70c13804d9f91fda1788db1a466a178b",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 17,
|
||||||
|
"title": "AI developer productivity experiment",
|
||||||
|
"url": "https://arxiv.org/abs/2302.06590",
|
||||||
|
"publisher": "Peng et al.",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.477297+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Peng et al. controlled HTTP-server task study reports 55.8% faster completion with Copilot.",
|
||||||
|
"evidence": "Abstract:Generative AI tools hold promise to increase human productivity. This paper presents results from a controlled experiment with GitHub Copilot, an AI pair programmer. Recruited software developers were asked to implement an HTTP server in JavaScript as quickly as possible. The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group. Observed heterogenous effects show promise for AI pair programmers to help people transition into software development careers.",
|
||||||
|
"limitations": "Primary paper abstract inspected, not full methods. Bounded JavaScript task; not whole-SDLC productivity."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/18.txt",
|
||||||
|
"body_sha256": "76c71ee9844c5066d184ec5006945c48959dfcd75854842463cd756f348a3140",
|
||||||
|
"evidence_type": "primary research abstract"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 18,
|
||||||
|
"title": "How much does AI impact development speed? An enterprise-based randomized controlled trial",
|
||||||
|
"url": "https://arxiv.org/abs/2410.12944",
|
||||||
|
"publisher": "Paradis et al. / arXiv",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.495104+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Paradis et al. Google RCT abstract reports about 21% shorter task time with a large confidence interval, among 96 engineers.",
|
||||||
|
"evidence": "Abstract:How much does AI assistance impact developer productivity? To date, the software engineering literature has provided a range of answers, targeting a diversity of outcomes: from perceived productivity to speed on task and developer throughput. Our randomized controlled trial with 96 full-time Google software engineers contributes to this literature by sharing an estimate of the impact of three AI features on the time developers spent on a complex, enterprise-grade task. We found that AI significantly shortened the time developers spent on task. Our best estimate of the size of this effect, controlling for factors known to influence developer time on task, stands at about 21\\%, although our confidence interval is large. We also found an interesting effect whereby developers who spend more hours on code-related activities per day were faster with AI. Product and future research considerations are discussed. In particular, we invite further research that explores the impact of AI at the ecosystem level and across multiple suites of AI-enhanced tools, since we cannot assume that the effect size obtained in our lab study will necessarily apply more broadly, or that the effect of AI found using internal Google tooling in the summer of 2024 will translate across tools and over time.",
|
||||||
|
"limitations": "Primary paper abstract inspected, not full methods. Google-specific task/tool setting; no universal gain claim. Retrieval seed title was wrong and corrected from body."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/19.txt",
|
||||||
|
"body_sha256": "e3ac83e7a8c9a613ed67b179321599538d4132e0caf858c4d335452c924c6839",
|
||||||
|
"evidence_type": "primary research abstract"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 19,
|
||||||
|
"title": "Copilot metrics concepts",
|
||||||
|
"url": "https://docs.github.com/en/copilot/concepts/billing-and-usage/copilot-usage-metrics/copilot-metrics",
|
||||||
|
"publisher": "GitHub",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:54.384631+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Copilot richest metrics depend on enabled client telemetry.",
|
||||||
|
"evidence": "Copilot usage metrics are derived from telemetry across multiple Copilot surfaces, including IDE, Copilot CLI, and agent apps activity. Most metrics come from client-side IDE telemetry, and end users need telemetry enabled in their IDE for the richest data in these metrics.",
|
||||||
|
"limitations": "No access to Eldorado subscription, settings, enabled exporters, reports or coverage. Adoption is not impact."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Server-side active-user coverage does not ensure complete feature/LOC breakdowns.",
|
||||||
|
"evidence": "Users surfaced through server-side telemetry are fully counted toward your active user totals (such as daily active users, daily_active_users ). When available, they may also appear in totals_by_ide (including the most recently detected IDE and Copilot extension versions in per-user reports). However, other dimensional breakdowns—such as totals_by_feature and lines-of-code metrics—remain empty until richer telemetry is available for them. Top-level totals and breakdowns for users already captured by client telemetry are unchanged.",
|
||||||
|
"limitations": "No access to Eldorado subscription, settings, enabled exporters, reports or coverage. Adoption is not impact."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/20.txt",
|
||||||
|
"body_sha256": "556fe5be28952b3b7d980b86b8a1a15713f0cff8359a7a0e02e09af7d6916ace",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 20,
|
||||||
|
"title": "Claude Code monitoring",
|
||||||
|
"url": "https://code.claude.com/docs/en/monitoring-usage",
|
||||||
|
"publisher": "Anthropic",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.636289+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Claude supports configured OTel usage/cost/tool telemetry.",
|
||||||
|
"evidence": "Track Claude Code usage, costs, and tool activity across your organization by exporting telemetry data through OpenTelemetry (OTel). Claude Code exports metrics as time series data via the standard metrics protocol, events via the logs/events protocol, and optionally distributed traces via the traces protocol.",
|
||||||
|
"limitations": "Capability depends on version/configuration. Tool/skill-name export may expose confidential identifiers; no observed Eldorado telemetry."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Skill-name/tool detail collection has explicit opt-in and privacy implications.",
|
||||||
|
"evidence": "OTEL_LOG_TOOL_DETAILSEnable logging of tool parameters and input arguments in tool events and trace span attributes: Bash commands, MCP server and tool names, skill names, user-authored workflow names, and tool input. Also enables custom, plugin, and MCP command names on user_prompt events, and real agent, skill, plugin, and MCP server and tool names on the cost and token counters (default: disabled). For Claude Desktop’s built-in servers, in sessions Claude Desktop owns, mcp_server_name/mcp_tool_name emit on tool_decision/tool_result even with the flag off. The exception requires Claude Code v2.1.214 or later1 to enable",
|
||||||
|
"limitations": "Capability depends on version/configuration. Tool/skill-name export may expose confidential identifiers; no observed Eldorado telemetry."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/21.txt",
|
||||||
|
"body_sha256": "197b3be58cae62470e82ac24074ca81024b030701ab3e2729116067dac798b48",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 21,
|
||||||
|
"title": "Agent Skills security",
|
||||||
|
"url": "https://agentskills.io/client-implementation/adding-skills-support",
|
||||||
|
"publisher": "Agent Skills",
|
||||||
|
"retrieved_at": "2026-10-04T10:27:53.937245+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "The implementation guide claims project-over-user skill precedence as universal.",
|
||||||
|
"evidence": "The universal convention across existing implementations: project-level skills override user-level skills.",
|
||||||
|
"limitations": "Implementation guidance rather than normative format; universal precedence claim contradicted by current Claude and Cline docs."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Agent Skills format does not mandate discovery paths.",
|
||||||
|
"evidence": "The .agents/skills/ paths have emerged as a widely-adopted convention for cross-client skill sharing. While the Agent Skills specification does not mandate where skill directories live (it only defines what goes inside them), scanning .agents/skills/ means skills installed by other compliant clients are automatically visible to yours, and vice versa.",
|
||||||
|
"limitations": "Implementation guidance rather than normative format; universal precedence claim contradicted by current Claude and Cline docs."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/22.txt",
|
||||||
|
"body_sha256": "fb2909a93d445a4b18a7cab89c22a7e92502e99d2caa586cf785e8aa8ae7a77b",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 22,
|
||||||
|
"title": "METR productivity update 2026",
|
||||||
|
"url": "https://metr.org/blog/2026-02-24-uplift-update/",
|
||||||
|
"publisher": "METR",
|
||||||
|
"retrieved_at": "2026-10-04T10:29:00.438454+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "METR 2026 follow-up calls its productivity signal unreliable because of selection and time-measurement issues.",
|
||||||
|
"evidence": "Unfortunately, given participant feedback and surveys, we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools. The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI, which likely biases downwards our estimate of AI-assisted speedup. We additionally believe there have been selection effects due to a lower pay rate (we reduced the pay from $150/hr to $50/hr), and that our measurements of time-spent on each task are unreliable for the fraction of developers who use multiple AI agents concurrently.",
|
||||||
|
"limitations": "Authors explicitly warn selection and parallel-agent timing compromise causal magnitude. Neither raw estimate is an Eldorado baseline."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "2026 raw estimates suggest speedup, but intervals include no effect and selection limits generalization.",
|
||||||
|
"evidence": "Our raw results show some evidence for speedup. Our early 2025 study found the use of AI causes tasks to take 19% longer, with a confidence interval between +2% and +39%. For the subset of the original developers who participated in the later study, we now estimate a speedup of -18% with a confidence interval between -38% and +9%. Among newly-recruited developers the estimated speedup is -4%, with a confidence interval between -15% and +9%.",
|
||||||
|
"limitations": "Authors explicitly warn selection and parallel-agent timing compromise causal magnitude. Neither raw estimate is an Eldorado baseline."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/23.txt",
|
||||||
|
"body_sha256": "7a4ce4ac6ba1a7a2410e17982493ab0d905d5d6418f28dda7460ca2aa4068306",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 23,
|
||||||
|
"title": "Cline SDK plugins",
|
||||||
|
"url": "https://docs.cline.bot/sdk/plugins",
|
||||||
|
"publisher": "Cline",
|
||||||
|
"retrieved_at": "2026-10-04T10:28:59.766735+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "Cline SDK plugins document fail_closed hook policy.",
|
||||||
|
"evidence": "Use fail_closed for policy-enforcement hooks where bypassing the hook is unsafe.",
|
||||||
|
"limitations": "SDK capability cannot be assumed identical in every Cline IDE/CLI build. Fail-closed behavior needs adapter conformance tests."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "Cline plugin installation accepts npm/git/file sources.",
|
||||||
|
"evidence": "Plugins can also be installed from file URLs, npm, git, or local paths using cline plugin install. See Plugins for install commands, the manifest format, and directory layout.",
|
||||||
|
"limitations": "SDK capability cannot be assumed identical in every Cline IDE/CLI build. Fail-closed behavior needs adapter conformance tests."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/24.txt",
|
||||||
|
"body_sha256": "445ba1089e4157e9eac938d1b7f1adf482769f3ae6d495d4bef5d666614fbd6a",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 24,
|
||||||
|
"title": "SPACE research publication",
|
||||||
|
"url": "https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/",
|
||||||
|
"publisher": "Microsoft Research",
|
||||||
|
"retrieved_at": "2026-10-04T10:29:02.189612+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "SPACE rejects productivity measurement with a single activity metric.",
|
||||||
|
"evidence": "Developer productivity is about more than an individual’s activity levels or the efficiency of the engineering systems relied on to ship software, and it cannot be measured by a single metric or dimension. The SPACE framework captures different dimensions of productivity, and here we demonstrate how this framework can be used to understand productivity in practice and why using it will help teams better understand developer productivity and create better measures to inform their work and teams.",
|
||||||
|
"limitations": "Author-hosted publication summary retrieved after ACM 403; supports multidimensional principle, not detailed instrument validity."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/25.txt",
|
||||||
|
"body_sha256": "1f8176ad5b14a5f4053162f670b95bdef81e191104f682c506b11099525b734e",
|
||||||
|
"evidence_type": "primary research abstract"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 25,
|
||||||
|
"title": "NIST AI RMF Core",
|
||||||
|
"url": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/",
|
||||||
|
"publisher": "NIST",
|
||||||
|
"retrieved_at": "2026-10-04T10:29:00.075579+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "NIST RMF organizes risk activity into govern, map, measure, manage.",
|
||||||
|
"evidence": "highest level to govern, map, measure, and manage AI risks. Governance is designed to be a cross-cutting function",
|
||||||
|
"limitations": "Risk-framework recommendations are not proof controls are deployed or staffing exists."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/26.txt",
|
||||||
|
"body_sha256": "c80bf3d3d59511eb3932cfd285893aa2a329ca9d997939c7c8c7718d704f857b",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 26,
|
||||||
|
"title": "Copilot adding skills",
|
||||||
|
"url": "https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills",
|
||||||
|
"publisher": "GitHub",
|
||||||
|
"retrieved_at": "2026-10-04T10:29:00.472587+00:00",
|
||||||
|
"claims": [
|
||||||
|
{
|
||||||
|
"claim": "gh skill --pin skips pinned skills during updates.",
|
||||||
|
"evidence": "To lock a skill to a specific version (or commit SHA) so it is skipped during updates, use --pin:",
|
||||||
|
"limitations": "gh skill is public preview, requires documented minimum CLI version; Gitea interoperability not verified. Pinning is not artifact safety."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "GitHub warns shared skills are unverified and may be malicious.",
|
||||||
|
"evidence": "Skills are not verified by GitHub and may contain prompt injections, hidden instructions, or malicious scripts. Always inspect the content of a skill before installation using gh skill preview.",
|
||||||
|
"limitations": "gh skill is public preview, requires documented minimum CLI version; Gitea interoperability not verified. Pinning is not artifact safety."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"claim": "gh skill records source ref and tree SHA in frontmatter.",
|
||||||
|
"evidence": "When you install a skill with gh skill, provenance metadata is written into the skill's SKILL.md frontmatter, including the source repository, ref, and tree SHA. The gh skill update command uses this metadata to check for upstream changes.",
|
||||||
|
"limitations": "gh skill is public preview, requires documented minimum CLI version; Gitea interoperability not verified. Pinning is not artifact safety."
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"evidence_file": "/opt/data/channels/eldorado-storm-v1/research/ai-adoption/bodies/27.txt",
|
||||||
|
"body_sha256": "7a5d8597f2ed72edb4610124e83f2abc282311739eabb561b3997ab6cbcbc46b",
|
||||||
|
"evidence_type": "primary source body"
|
||||||
|
}
|
||||||
|
]
|
||||||
@@ -0,0 +1,190 @@
|
|||||||
|
# Eldorado AI adoption — strategy implementation blueprint
|
||||||
|
|
||||||
|
Status: target operating model for review; not an approved rollout or an inventory of deployed controls. This handoff is documentation design only. It does not authorize installing agents, collecting employee telemetry, changing permissions or enabling autonomous delivery.
|
||||||
|
|
||||||
|
## Implementation contract
|
||||||
|
|
||||||
|
Create eight substantive pages in the independent Strategy navigation, in this order: `index`, `target-operating-model`, `skills-governance`, `skills-quality`, `skills-adoption`, `measurement`, `skills-maintenance`, `roadmap`. The structured companion is `strategy-model.json`; its KPI definitions and identifiers are authoritative for the measurement prototype. Preserve Organization Structure, Collaboration and SDLC and their exact department/team names. Cross-link rather than duplicate reporting charts. The existing organizational documentation is an operating model, not certification of staffing.
|
||||||
|
|
||||||
|
Use the existing Archify JSON renderer and shared icon-only modal control. Diagram logical ID: `ai-adoption-target`; editable source: `diagrams/ai-adoption-target.architecture.json`. Do not expose downloadable JSON. Keep source mapping and open-decision material outside docs/static/search. Reader-facing prose below can be adapted into MDX without bibliography, evidence codes, recruitment commentary or repeated caveats. Use a visible **Target operating model** introduction and prospective verbs where status matters. Never present synthetic calculations as Eldorado results.
|
||||||
|
|
||||||
|
## 1. Overview — index
|
||||||
|
|
||||||
|
### Govern skills first, expand authority only with evidence
|
||||||
|
|
||||||
|
Eldorado's target is to make AI-assisted work dependable across the organization: useful guidance, clear human ownership, controlled execution and measurable outcomes. The first investment is a governed skills system, not an autonomous replacement for the organization. A skill packages reusable working knowledge, prerequisites and verification steps. It helps an agent perform a task; it does not grant permission or guarantee that the work is correct.
|
||||||
|
|
||||||
|
The target combines one logical SDLC coordinating agent with developer choice on local laptops. Copilot, Claude Code and Cline remain client options within a qualified support matrix. They receive the same reviewed portable skill content through client-specific adapters. Repository, CI and release services remain the enforcement points, independently of what any agent says or which local tool produced a change.
|
||||||
|
|
||||||
|
The strategy describes the intended operating model and the evidence required to introduce it. It does not establish that these controls are installed, that every client is supported, or that AI has improved Eldorado's performance. The current reference is the documented six-department organization. Rollout begins by validating actual clients, responsibilities, data boundaries and available evidence.
|
||||||
|
|
||||||
|
Success means accepted outcomes with maintained quality, controlled risk and understood total cost. Faster activity without reliable outcomes is not success. More skill invocations, generated lines or tool subscriptions are not productivity targets. People remain accountable for product, customer, financial and personnel decisions.
|
||||||
|
|
||||||
|
## 2. Target operating model — target-operating-model
|
||||||
|
|
||||||
|
### One coordination function, distributed contributions
|
||||||
|
|
||||||
|
Data & AI owns the coordinating function, with the existing AI Architect function connecting it to Technology leadership. The logical coordinator maintains approved work records, dependencies, evidence requests, bounded retries and escalation. It can summarize, propose work and route decisions. It cannot declare its own work approved, change protected checks, authorize production release or replace the responsible human.
|
||||||
|
|
||||||
|
One logical coordinator does not mean one fragile process. A durable task ledger, explicit state transitions, leases and idempotency keys allow recovery or multiple replicas without duplicate delivery. Inference outages stop new agent decisions, not the organization's ability to take over. People can resume work through the normal deterministic workflow. Evidence and authorization services fail closed for privileged actions; missing evidence never becomes permission.
|
||||||
|
|
||||||
|
The delivery path is: an approved problem and acceptance criteria; an authorized task; local or isolated worker proposals; independently reviewed repository changes; exact-revision CI evidence; a human release decision; execution by the release service; then operational feedback. Product Management accepts the outcome hypothesis and business result. Product Design reviews experience and accessibility. Product Engineering owns the code and maintainability. Quality Engineering assesses quality independently. Architecture & Security assesses risk. Platform & IT operates the delivery boundary. No arrow from a laptop or coordinator goes directly to production authority.
|
||||||
|
|
||||||
|
### Trust and authority boundaries
|
||||||
|
|
||||||
|
People authenticate to the work system; the coordinator receives only the project context it needs. Untrusted issue text, repository content, web pages and tool output are task data, never an authorization source. Local clients operate under device controls and project-scoped access. Hard containment requires OS/container isolation, filesystem and network restrictions and separate short-lived identities; a skill folder, prompt or working directory is not a sandbox.
|
||||||
|
|
||||||
|
The registry distributes reviewed immutable content and adapters, not ambient credentials. Executable scripts, plugins, MCP servers and dependencies are separately reviewed and pinned. Model-provider routing is allowlisted for the data classification, with approved retention and training-use terms before sensitive data crosses that boundary. Fallback to another provider must not silently change the data policy.
|
||||||
|
|
||||||
|
Central controls verify protected-branch review, actual artifact identity, exact commit and policy revision, required checks and a scoped human approval. Candidate changes cannot edit their own authoritative gate or reuse approval for a different artifact. Deployment credentials belong to the release service, not the local agent. Approval expires or is invalidated by changed content. Emergency stop revokes mutation credentials and stops scheduling independently of the model, preserves evidence and enables human takeover.
|
||||||
|
|
||||||
|
### Department contributions
|
||||||
|
|
||||||
|
| Department / existing team | Contribution and retained human decision | First bounded workflow and evidence |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Product / Product Management | Own pilot priorities, acceptance criteria and outcome hypotheses; decide product value. | Draft acceptance criteria from sanitized discovery notes; independent completeness review and accepted-task success. |
|
||||||
|
| Product / Product Design | Own design quality, accessibility and research handling. | Review a proposed flow against an accessibility checklist; verify findings against the interface. |
|
||||||
|
| Technology / Product Engineering | Own skill authoring, code review and maintainability; remain accountable for generated code. | Test scaffolding and change summaries in a disposable branch; independent tests and escaped-quality follow-up. |
|
||||||
|
| Technology / Platform & IT | Own supported client inventory, distribution, identity, isolation, CI/release integration, transport and emergency revocation. | Qualify a pinned bundle and exercise rollback; inventory and exact-revision gate evidence. |
|
||||||
|
| Technology / Architecture & Security | Own risk classification, data boundaries, security review and bounded exceptions. | Review injected-input and unauthorized-tool cases; independent control evidence and policy-effect counts. |
|
||||||
|
| Technology / Quality Engineering | Own regression/adversarial suites, rubric calibration and acceptance evidence. | Evaluate candidate versus approved skills on repeated representative tasks; retain all failures. |
|
||||||
|
| Technology / Data & AI | Own catalog coordination, coordinator evaluation and measurement design, through existing AI enablement responsibilities. | Curate a small skill set and analyze a prospective pilot; no new AI department. |
|
||||||
|
| Operations / Operations Squad | Own service acceptance, disputes, fraud, refunds and customer communications. | Draft an answer from sanitized resolved cases; Operational Quality workstream checks correctness before any send. No automated dispute/refund decision. |
|
||||||
|
| Marketing / Marketing Squad | Own brand, factual claims, content rights, publication and spend approvals. | Draft a campaign brief against approved brand material; human claim/rights review before publication. |
|
||||||
|
| Finance & Accounting / Finance & Accounting Squad | Own allocation of total costs, financial evidence and segregation of approvals. | Explain a sanitized reconciliation exception; no posting, payout or payment authority. |
|
||||||
|
| HR & Administration / People & Administration Squad | Own coaching, acceptable use, feedback privacy and people decisions; partner with Platform & IT on access lifecycle. | Draft onboarding guidance from approved policy; human accuracy review. No hiring or performance decision automation. |
|
||||||
|
|
||||||
|
Product keeps two teams; Technology keeps five; the other four departments keep one squad each. Coordination, skill ownership, approval and cover are assignments inside these teams, not new standing departments, roles or headcount. Department leaders retain accountability and designate real approvers before a pilot starts.
|
||||||
|
|
||||||
|
## 3. Skills governance — skills-governance
|
||||||
|
|
||||||
|
### A contract that travels, controls that stay authoritative
|
||||||
|
|
||||||
|
Maintain one catalog entry per stable skill ID, with immutable revisions and a concise portable `SKILL.md` body. Required content includes when to use and when not to use the skill, prerequisites, bounded steps, expected artifacts, verification, failure handling and escalation. The companion model defines the complete metadata contract: owner and independent reviewer, risk tier, supported clients and versions, dependencies, digest, provenance and license, evaluations, approval, review date, deprecation and rollback.
|
||||||
|
|
||||||
|
The release manifest pins the content, dependencies and adapter revisions by full immutable commit or digest. Names use an `eldorado-` prefix to reduce collisions. Friendly versions aid communication but never replace the digest. No arbitrary upstream automatic update is admitted into the approved bundle. Changes to scripts, resources or dependencies count as skill changes, not harmless documentation edits.
|
||||||
|
|
||||||
|
Adapters place content in the qualified client's discovery paths and implement only verified client-specific behavior. Qualification records the host, exact build, OS, model configuration, discovery, explicit invocation, collisions, disabled skills, permission behavior, context compaction and reload behavior. A common file format is not common precedence or a portable hooks API. Claude and Cline skill-name precedence differs from rule/memory behavior; Copilot support varies by surface. Test the actual build, not the brand name.
|
||||||
|
|
||||||
|
### Lifecycle and decision rights
|
||||||
|
|
||||||
|
A proposal names the problem, owner, data scope and testable outcome. Experimental revisions run only in approved disposable environments. Promotion requires independent review, static and executable dependency checks, per-client behavioral evaluations and a bounded canary. Approval records bind the exact artifact and permitted uses. Deprecated revisions carry a migration path and deadline; retired revisions are unavailable for new work. Any active revision can be quarantined immediately.
|
||||||
|
|
||||||
|
The author never supplies the only approval. Data & AI maintains catalog state; the owning team is accountable for content; Quality Engineering approves evaluation evidence; Architecture & Security approves higher-risk boundaries; Platform & IT verifies distribution and revocation. A business owner accepts workflow outcomes. These functions can be covered by existing staff, but incompatible author/approver duties must remain separate for the same release.
|
||||||
|
|
||||||
|
An exception contains its ID, skill/client revision, scope, business reason, risk owner, compensating checks, approver, start and expiry, affected users/projects and rollback route. It does not disable protected release, payment or identity controls. Expired or unverifiable exceptions deny privileged actions. Repeated exceptions trigger a supported-design change rather than permanent informal bypass.
|
||||||
|
|
||||||
|
### Distribution, stale clients and rollback
|
||||||
|
|
||||||
|
Stage a verified bundle atomically, check its digest, load it through the qualified adapter and read back its effective revision. Test already-open sessions; changing files is not proof of reloading instructions. Record immutable last-known-good content and adapter dependencies. Canary upgrades precede wider distribution.
|
||||||
|
|
||||||
|
A cached verified bundle may support explicitly permitted low-risk work if its model and tool dependencies are available. It does not make a cloud-backed client work offline. Stale or unsupported sessions cannot obtain centrally mediated privileged access. Reconnection revalidates support, revocation and policy before credentials are issued. Central artifact review protects delivery even when a laptop declaration is absent or false; a client report cannot prove which private prompt was actually followed.
|
||||||
|
|
||||||
|
Rollback restores the approved manifest and dependencies, invalidates affected sessions, revokes unsafe revisions, runs a smoke test and verifies effective state. It cannot undo data disclosure or commands already executed. Those require incident response.
|
||||||
|
|
||||||
|
## 4. Skills quality — skills-quality
|
||||||
|
|
||||||
|
Quality has four separate questions: was the right skill selected, was the procedure executed safely, did the artifact pass independent checks, and did the workflow produce useful outcomes? A successful invocation answers none of the remaining questions by itself.
|
||||||
|
|
||||||
|
The proposed qualification contract uses three tiers. R1 is read-only or drafting with nonsensitive approved material; R2 creates code or material with customer impact but no privileged external effect; R3 touches privileged, financial, sensitive-personal or production decisions. R3 remains human-authorized and out of the initial autonomous scope.
|
||||||
|
|
||||||
|
Every tier requires all mandatory deterministic safety, schema, authorization and provenance checks to pass, with no observed critical unauthorized action. An observed critical effect blocks promotion. The model gives proposed pilot evaluation floors and success thresholds; these are design defaults for owner ratification, not externally validated guarantees or approved service levels. If sample coverage, acceptance criteria or responsible reviewers are missing, qualification remains incomplete. No aggregate score can trade off a failed mandatory safety check.
|
||||||
|
|
||||||
|
Use sanitized, predeclared task sets containing positive triggers, near misses, negative cases and the normal workload mix. Compare no-skill, current-approved and candidate paths with the same starting artifacts; repeat stochastic trials and retain failed and abandoned attempts. Independently inspect output state. Deterministic tests grade checkable constraints; calibrated humans grade usefulness, maintainability and experience. A model judge is supplementary, versioned and checked against human disagreements, never the sole safety or promotion authority.
|
||||||
|
|
||||||
|
Include adversarial repository text, malicious referenced code, wrong permissions, client toggles, name shadowing, unsupported versions, hook timeout/crash/malformed response, stale sessions, offline recovery and rollback. Run central checks against forged/missing client declarations. Hook presence is not fail-closed enforcement: failure semantics must be tested on each client, and central authorization remains independent.
|
||||||
|
|
||||||
|
Report denominators, task mix, trial counts, per-client results and uncertainty. A passing benchmark is evidence within a tested envelope, not proof that all future tasks are safe. Material model, client, adapter or dependency changes trigger requalification.
|
||||||
|
|
||||||
|
## 5. Adoption — skills-adoption
|
||||||
|
|
||||||
|
Start with a small set of useful workflows chosen by the existing teams. Product Management and the departmental owner identify the outcome; Data & AI helps turn it into a skill; Quality Engineering establishes acceptance; Platform & IT qualifies the client path; Architecture & Security clears the data boundary. People & Administration Squad coordinates learning and accessible feedback.
|
||||||
|
|
||||||
|
Onboarding should teach people to select the right skill, inspect the actual artifact, recognize untrusted instructions, use the exception and incident routes and recover without AI. A practice task ends with verified work and an explanation of limits, not just a logged invocation. Demonstrate the same portable skill on the supported local clients without promising identical agent behavior.
|
||||||
|
|
||||||
|
Use short worked examples, peer pairing, office hours and a clear catalog search path. Gather reasons for non-use and rejected suggestions without penalizing them. Preserve a manual path. Training feedback improves the skill only through review, not automatic self-modification of the approved catalog. Departmental workflow outcomes matter more than uniform uptake.
|
||||||
|
|
||||||
|
No developer rankings, individual productivity scores, minimum invocation quotas or inference of effort from token counts are part of this strategy. Report cohort-level evidence with privacy protection and balanced quality, flow, risk and cost. A participant may reasonably stop using a skill that creates more work or uncertainty.
|
||||||
|
|
||||||
|
## 6. Measurement — measurement
|
||||||
|
|
||||||
|
### Decide what counts before counting
|
||||||
|
|
||||||
|
Use the machine-readable KPI catalog for exact definitions. Every report states its eligible population, observation window, numerator and denominator or distribution sample count, source coverage, exclusions and calculation version. Zero denominators return “not available.” Missing telemetry is unknown, not inactivity, compliance or success. Examples are explicitly synthetic and illustrative.
|
||||||
|
|
||||||
|
Begin with task acceptance, repository, CI, deployment and incident systems because they can independently establish outcomes. Add catalog/version inventory and task-level declarations. Client telemetry is supplementary and version-dependent; enabling rich tool details may collect sensitive commands and identifiers. Do not enable it merely to count skills. A normalized adapter may report approved skill identifiers without forwarding raw arguments.
|
||||||
|
|
||||||
|
Validated success uses all eligible initiated tasks whose predeclared observation window has matured. Failed and abandoned tasks remain nonsuccess. Unresolved or unobserved outcomes remain in the denominator, with known-outcome coverage shown alongside the conservative confirmed-success share. They are not relabeled as observed failure. A task cancelled before start is excluded; cancellation after start remains visible. Count a task once across retries and multiple skills. For timeliness, also show unfinished work and age; accepted-only lead-time distributions have survivorship limitations.
|
||||||
|
|
||||||
|
Track all five service-level DORA measures: commit-to-production lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate. Do not substitute PR-open-to-merge time or all-incident MTTR. Pair them with matured escaped-quality rates, policy effects, total cost per accepted outcome, support coverage, adoption, human experience and catalog maintenance. Keep customer/business outcomes linked to their departmental hypotheses; do not infer conversion, trust or revenue improvement from delivery telemetry.
|
||||||
|
|
||||||
|
### Baseline and interpretation
|
||||||
|
|
||||||
|
Before a pilot, freeze eligibility and acceptance rules and verify event joins. Collect prospective no-skill/current-practice evidence over a complete comparable workflow cycle and until the preregistered precision/sample requirement is met. Do not select a convenient end date after seeing results. Retain task class, service, skill, client/model configuration and concurrent changes. A matched or randomized comparison may be used when practical and ethical; label observational trends as descriptive and report confounding, selection and uncertainty.
|
||||||
|
|
||||||
|
Elapsed time and human effort are different quantities. Parallel agents may reduce waiting while increasing review or compute. Include failed attempts and human review/rework in cost, do not multiply a multi-skill task's value across every invocation, and do not convert survey perceptions into proven time savings. Small or incomplete populations yield evidence limits, not an ROI percentage.
|
||||||
|
|
||||||
|
### Event and privacy contract
|
||||||
|
|
||||||
|
Use the event envelope and per-event required fields in the model. Source producer plus event ID deduplicates transport retries. Conflicting payloads under the same key are quarantined. Attempts have distinct IDs under one task. Domain IDs deduplicate deployments, defects and approvals even when multiple feeds describe them. Late arrivals produce versioned aggregate corrections; never silently overwrite a published result. Preserve occurrence and receipt times, reject impossible orderings and flag clock skew. Missing terminal events remain unresolved until the work owner reconciles them.
|
||||||
|
|
||||||
|
Many-to-many task/attempt/skill/client associations preserve exact immutable versions. Unknown version stays null with a reason; never assign the latest revision retroactively. Client declarations, server facts and self-reports remain separately labeled. A skill-loaded event is evidence of loading only. The minimal prototype can operate without actor identity except where a lawful, necessary adoption denominator requires pseudonymous cohort membership.
|
||||||
|
|
||||||
|
The privacy starting proposal is 30 days for raw structured analytics events and 12 months for aggregated trends, subject to the responsible owners' review. Keep the approved catalog/approval record for the supported revision's lifetime and its required audit period, which must be decided separately. Incident evidence uses a restricted, explicitly authorized hold and deletion schedule, not an indefinite analytics exception. Suppress reports below five people and prohibit drill-down or overlapping cohort slices that reconstruct identities. Five is a proposed minimum, not a guarantee against re-identification. No raw prompts, code, screens, customer cases or secrets are collected by default. Publish the purpose, lawful collection basis, access/deletion route and retention before collecting. Consent is not presumed to be an appropriate employment-law basis.
|
||||||
|
|
||||||
|
## 7. Maintenance — skills-maintenance
|
||||||
|
|
||||||
|
Every approved skill has an accountable owning team, independent reviewer, review due date, supported client matrix and rollback bundle. Review both usefulness and safety, not just metadata freshness. Proposed maximum review intervals are recorded by risk tier; incidents, dependency changes, model/client drift or repeated failures trigger earlier review.
|
||||||
|
|
||||||
|
Data & AI reviews catalog health with the owning teams. Quality Engineering samples accepted outputs and adds confirmed failures to regression sets without exposing sensitive content. Platform & IT watches unsupported, deprecated and revoked revisions and tests distribution recovery. Architecture & Security reviews emerging misuse and exception expiry. Remove redundant or unused entries deliberately, after examining whether poor discoverability or fit explains non-use.
|
||||||
|
|
||||||
|
A reported unsafe behavior opens an incident with artifact, policy and client versions. Architecture & Security coordinates containment; Platform & IT revokes authority, stops scheduling and quarantines affected revisions; the owning department handles customer or business consequences; Quality Engineering reproduces the failure; Data & AI coordinates catalog correction and trend analysis. Preserve minimal restricted evidence and involve People & Administration Squad for employee-data concerns and Finance & Accounting Squad for financial effects. Restart requires a reviewed fix, regression evidence, verified rollback/revocation and accountable human authorization. Closing the incident does not erase the historical failure from measurement.
|
||||||
|
|
||||||
|
## 8. Roadmap — roadmap
|
||||||
|
|
||||||
|
| Phase | Entry evidence | Work | Exit evidence and hold condition |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| Foundation | Strategy scope accepted for planning; existing teams identified. | Inventory actual client hosts/builds, provider/data terms, repositories, authority, owners and event availability; select low-risk workflows and metric definitions. | Named accountable people and independent reviewers, bounded pilot charter, forbidden actions, data/retention decision and reproducible baseline plan. Hold if accountability or lawful collection is unresolved. |
|
||||||
|
| Governed skills pilot | Foundation evidence approved; no privileged autonomous effects. | Build a small registry, immutable contract, client adapters, evaluations, coaching and synthetic measurement verification. | Qualified client/skill tuples, mandatory safety checks, independent task acceptance, reconciled coverage and user feedback. Hold or narrow scope if quality or data coverage is inadequate. |
|
||||||
|
| Reliable distribution | Pilot quality and usefulness support continuing. | Canary updates, effective-version readback, version locking, exception expiry, stale/offline handling and rollback. | Tested revocation and recovery, no bypass of central privileged gates, owners can support the catalog. Hold if effective versions or controls cannot be verified. |
|
||||||
|
| Logical SDLC coordination | Distribution, authority and measurement evidence stable. | Observe and assemble evidence first, then propose and route work within scoped identities and budgets. | Exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills pass; humans can take over. No authority expansion based on usage alone. |
|
||||||
|
| Departmental expansion | Each department supplies a workflow owner, outcome, data boundary and capacity. | Add Operations, Marketing, Finance & Accounting and HR & Administration workflows with domain-specific review; Product and Technology continue quality improvement. | Departmental accepted outcomes, guardrails, total cost and experience justify continuation; sensitive decisions stay human. Stop or roll back workflows without adequate evidence. |
|
||||||
|
|
||||||
|
There are no invented launch dates, budgets, staffing commitments or guaranteed gains. Phase gates permit narrowing or stopping. Re-evaluate earlier phases when the underlying client, provider, data scope or authority changes.
|
||||||
|
|
||||||
|
## Internal architecture brief for implementer
|
||||||
|
|
||||||
|
Use a small overview with six groups: (1) accountable people and approved work; (2) one logical coordinator and durable ledger; (3) governed registry plus qualified adapters; (4) local client contributors; (5) independent repository/CI/release boundary with separate human approval; (6) audit/measurement feedback. Put external model-provider access across a labeled data/egress boundary, with approved routing. Show registry-to-coordinator and registry-to-local-client distribution; coordinator-to-work proposals; clients-to-repository proposals; CI-to-human approval evidence; approval-to-release service; resulting evidence-to-audit and audit-to-people/coordinator feedback. Distinguish proposal/evidence arrows from authorization arrows. No coordinator-to-production or laptop-to-production edge. Diagram alt text must state target status, human accountability and lack of direct production authority. Keep full contract detail in prose, not tiny diagram boxes. Organization page links identify existing teams, not a new hierarchy.
|
||||||
|
|
||||||
|
## Internal evidence mapping and open decisions
|
||||||
|
|
||||||
|
Source IDs below refer to `research/ai-adoption/sources.json`. They support principles and documented capabilities, not local deployment or approval. Organization mapping was read from `repositories/documentation/docs/organization/{structure,collaboration,sdlc}.mdx` at `14ba1aa1ef66c91525135f743d15c77e32db78d3`.
|
||||||
|
|
||||||
|
| Recommendation | Evidence | Design decision / limit |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Portable contract plus exact-client adapters | 1, 2, 4, 8, 9, 21, 26 | Content format is portable; precedence and enforcement are not. Vendored immutable distribution is the proposed default; no Gitea installer compatibility established. |
|
||||||
|
| Independent gates, least privilege and human authority | 3, 5, 6, 7, 15, 23 | Central authorization and kill switch are target controls; local hooks are supplementary and may fail open. |
|
||||||
|
| One logical coordinator, resilient task ledger and bounded authority | Task direction; 11, 15, 25 | Replica/idempotency/recovery topology is a design choice, not an observed installation or a vendor guarantee. |
|
||||||
|
| Exact existing-team ownership | Three organization pages; findings section 5 | Assignments extend the documented model without asserting named staffing, capacity or approval. |
|
||||||
|
| Immutable provenance, review, dependency checks and rollback | 1, 26, 15 | Approval digest and distribution manifest are proposed operational contracts. Pinning alone does not make content safe. |
|
||||||
|
| Layered repeated evaluation and independent output checks | 11, 15 | Risk tiers, evaluation floors, review intervals and proposed percentages are local design defaults requiring ratification, not thresholds from the literature. |
|
||||||
|
| Balanced KPIs and all five delivery measures | 12, 24 | Service/team evidence; no individual ranking or AI causal claim from activity. |
|
||||||
|
| Comparative baseline, effort/elapsed distinction and no forecast ROI | 16, 17, 18, 22 | Studies vary by context; abstract-only evidence for 17/18 and known 2026 selection/timing limitations. Do not reproduce percentages as expected gains. |
|
||||||
|
| Version-aware optional client telemetry | 19, 20, 23 | Actual licensing, settings and host coverage unknown; normalize only minimally necessary events. |
|
||||||
|
| Lifecycle ownership, privacy and gates before expansion | 13, 14, 25; 20 | NIST voluntary framework is not certification; 14 inspected at landing-page level. Retention and cohort floor are proposals for review. |
|
||||||
|
|
||||||
|
Open decisions (not blockers to writing target documentation; blockers to their corresponding rollout gates):
|
||||||
|
|
||||||
|
1. Platform & IT with Architecture & Security: actual supported hosts/builds/OSs, identity boundaries, authoritative CI/release controls, protected-policy administration and stale-bundle access rule.
|
||||||
|
2. Department leaders with Data & AI: named owner/reviewer/deputy coverage, pilot capacity and selected workflows; no new headcount is implied.
|
||||||
|
3. Architecture & Security with People & Administration Squad and the relevant data owner: provider processing terms, data classification, lawful telemetry basis, retention, incident holds and access/deletion handling. Obtain specialist legal advice where needed; no new permanent legal role is invented.
|
||||||
|
4. Quality Engineering with Data & AI and each workflow owner: ratify or replace the proposed risk-tier thresholds, task distributions, minimum samples, uncertainty criterion and quality follow-up windows before using them for promotion.
|
||||||
|
5. Finance & Accounting Squad: cost allocation, currency normalization, treatment of shared licenses, effort sampling and confidence required for investment decisions.
|
||||||
|
6. Product Management with departmental owners: business outcome hypotheses and whether a matched/randomized pilot is practical. No tool choice is coerced for an unreviewed experiment.
|
||||||
|
7. Platform & IT: private registry distribution method, digest verification, revocation semantics, coordinator recovery and feasible minimal adapters. Do not assume vendor-preview installation or Cline SDK telemetry is already available.
|
||||||
|
|
||||||
|
## Executable handoff and verification
|
||||||
|
|
||||||
|
`build_strategy_model.py` writes the structured contract and illustrative values. `sample_calculations.py` is an executable reference/test plan using only labeled synthetic in-memory fixtures. The implementation child should port the same assertions into the documentation repository's established test tooling and add a CLI/fixture interface, rather than treating this reference as a production collector. Required cases are declared in the model. Do not ship research files or raw event fixtures into public static assets inadvertently.
|
||||||
|
|
||||||
|
Acceptance for this synthesis: both requested files parse/exist; eight page IDs and all eleven existing teams are exact; every KPI has the full calculation/evidence/privacy contract; source IDs resolve; illustrative arithmetic is executed; synthetic edge-case tests pass; documentation repository remains unchanged. Publication, browser review, diagrams and production measurement infrastructure belong to the downstream implementation task, not this synthesis.
|
||||||
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,7 @@
|
|||||||
|
# Organization background research
|
||||||
|
|
||||||
|
The source/excerpt ledger and `reconstruction-snapshot.mdx` preserve the original public-evidence investigation. They are background working material, outside the published docs and static assets.
|
||||||
|
|
||||||
|
The reader-facing `docs/organization/structure.mdx` is an organizational operating model, not a research report or an employee roster. Per the user's presentation direction, it describes leadership, departments, teams and responsibilities directly without evidence markers, vacancies or citations. Internet research informs the model; this editorial change does not independently verify staffing, incumbent names or every reporting relationship.
|
||||||
|
|
||||||
|
The original snapshot records which categories and relationships were evidenced, job-advertised or inferred. Retain that provenance for future maintenance, without importing it into the published page, diagram metadata or search index.
|
||||||
@@ -0,0 +1,102 @@
|
|||||||
|
---
|
||||||
|
title: Structure
|
||||||
|
description: Distinguish Eldorado’s publicly evidenced organization from advertised roles and planning assumptions.
|
||||||
|
---
|
||||||
|
|
||||||
|
import ArchifyDiagram from '@site/src/components/ArchifyDiagram';
|
||||||
|
|
||||||
|
**Research snapshot: 2026-10-02.** This is a public-evidence reconstruction for AI strategy planning, **not a verified employee roster** or an internally approved organization chart.
|
||||||
|
|
||||||
|
## What is known
|
||||||
|
|
||||||
|
Eldorado names **Vladas Jurkevičius — co-founder and CEO** and **Lukas Deksnys — co-founder and COO** on its official About page.[1]
|
||||||
|
|
||||||
|
Its official careers site uses seven hiring categories: **Management, Product, Technology, Operations, Marketing, Finance & Accounting, and HR & Administration**. Those labels are directly evidenced; treating them as six peer departments beneath Management is a planning arrangement, not a published reporting hierarchy.[4]
|
||||||
|
|
||||||
|
### Evidence legend
|
||||||
|
|
||||||
|
- **E — Publicly evidenced:** a named leader, team, function or careers category explicitly appears in an official source. This does not establish every reporting relationship.
|
||||||
|
- **J — Job-advertised:** a vacancy describes a role, mandate or reporting line. The position may be unfilled or newly created.
|
||||||
|
- **A — Assumed:** a proposed grouping or missing team boundary used for planning, not a claim about Eldorado’s current structure. Dashed connectors identify assumed placements.
|
||||||
|
|
||||||
|
## Department overview
|
||||||
|
|
||||||
|
<ArchifyDiagram name="organization-structure" title="Eldorado organization — evidence and assumptions" />
|
||||||
|
|
||||||
|
**Text alternative:** Management is shown above Product, Technology, Operations, Marketing, Finance & Accounting, and HR & Administration. All six placements beneath Management are assumed. The department names come from the careers taxonomy; the notes in the viewer identify evidenced teams and proposed subdivisions. This view does not assign every function directly to the CEO or COO.
|
||||||
|
|
||||||
|
## Departments and teams
|
||||||
|
|
||||||
|
The following separates **named teams** from **roles, capabilities and domains**. A function mentioned in a vacancy is not automatically a separately staffed team.
|
||||||
|
|
||||||
|
| Department / function | Publicly evidenced teams, roles or domains | Assumed completion for planning |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **Management** | **E:** CEO Vladas Jurkevičius and COO Lukas Deksnys. **J:** CTO and CMO are referenced as reporting managers.[1][8][12] CFO is advertised.[5] No incumbent names are inferred for those three roles. | **A:** a leadership coordination layer across the six functions. Exact executive reporting lines, Board membership and decision rights remain unverified. |
|
||||||
|
| **Product** | **E:** Order/Orders team; Categories design team, with Boosting & Currency scope; Data Team appears in the ranking Data Scientist vacancy metadata. Data classification and product design evidence.[9][13][14] **J:** Sellers and Operations product-owner domain, including Seller Portal, integrations, onboarding, balances/withdrawals, invoicing and support tooling.[15] | **A:** treat Sellers & Operations as a cross-functional product squad for planning, not a proven standalone team. Do not duplicate Data as a separate peer department. |
|
||||||
|
| **Technology** | **J:** Head of Engineering → Group Engineering Managers → Engineering Managers → engineers. AI Architect reports to CTO and starts solo. Technical Architect is named as an infrastructure/security partner; IT Engineer is advertised for identity, device management and internal SaaS.[6][8][10] | **A:** CTO → Head of Engineering. Proposed shared platform/reliability and security capability groups, with staffing and reporting unverified. Do not turn AI Architect into an established AI department. |
|
||||||
|
| **Operations** | **E:** Customer Support, Trust & Resolution, Risk & Fraud. **J:** QA Specialist (Operations) reports directly to COO; separate support/resolution Team Lead mandates cover specialist teams.[11][17][18] | **A:** COO ownership of the wider Operations function and its team-lead escalation chain. Only the QA Specialist’s direct COO line is explicit in the reviewed sources. |
|
||||||
|
| **Marketing** | **J:** Brand Team Lead reports to CMO. **E:** the wider Marketing team names Creative, SEO, PPC & Affiliate, Influencer, and CRM; brand scope includes organic social, community and brand partnerships.[12] | **A:** model these named disciplines as planning workstreams under Marketing. Separate team managers, headcounts and each discipline’s direct CMO line are not established. |
|
||||||
|
| **Finance & Accounting** | **E:** Finance team / hiring category. **J:** CFO remit includes planning, reporting, cash/capital, tax, compliance, financial risk and payments; it describes partnership with CEO and Board, not an explicit reporting line.[5] | **A:** FP&A; Accounting/Tax/Controls; Treasury/Payment Operations as three capability groups. These are inferred subdivisions, not proven staffed teams. Financial risk is not the same thing as the Operations Risk & Fraud team. |
|
||||||
|
| **HR & Administration** | **E:** Talent Acquisition team / role category. **J:** full-cycle IT and non-IT recruitment, partnering with hiring managers.[16] | **A:** People Operations and Office/Administration alongside Talent Acquisition. Separate teams and the HR leader’s reporting line remain unverified. |
|
||||||
|
|
||||||
|
The Sellers and Operations posting establishes a **product domain**, not a named Sellers department. Its mandate crosses seller-facing features, operational tooling and marketplace infrastructure.[15]
|
||||||
|
|
||||||
|
## Reporting lines supported by vacancies
|
||||||
|
|
||||||
|
<ArchifyDiagram name="organization-reporting" title="Eldorado reporting lines — advertised and assumed" />
|
||||||
|
|
||||||
|
**Read arrows as manager → role/team.** Solid **J** connectors are explicitly described in vacancies. The dashed **A** link between CTO and Head of Engineering is the only inferred link in this diagram. Separate rows are not connected because their upward reporting lines were not established.
|
||||||
|
|
||||||
|
| Manager / leader | Role or team below it | Status and scope |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Head of Engineering | Group Engineering Manager | **J:** explicitly reports directly to Head of Engineering; the vacancy describes managing 4–5 Engineering Managers.[6] |
|
||||||
|
| Group Engineering Manager | Engineering Manager | **J:** explicitly named manager in the Engineering Manager vacancy.[7] |
|
||||||
|
| Engineering Manager | Software engineers | **J:** leads a team of around five engineers. This is the advertised span, not a count of all current engineering teams.[7] |
|
||||||
|
| CTO | AI Architect | **J:** explicitly direct; a new individual-contributor role, starting solo with a possible future team.[8] |
|
||||||
|
| COO | QA Specialist (Operations) | **J:** explicitly direct; independent quality work across Customer Support, Trust & Resolution, and Risk & Fraud.[11] |
|
||||||
|
| CMO | Brand Team Lead | **J:** explicitly direct; brand, organic social, community and brand partnerships remit.[12] |
|
||||||
|
| Customer Support / Trust & Resolution Team Leads | Their specialists | **J:** support/resolution leadership advert describes teams of 5–10 specialists; the resolution-specific advert also states 5–10. Their own upward manager is not stated.[17][18] |
|
||||||
|
| CTO | Head of Engineering | **A:** plausible technology reporting arrangement, retained only as a planning assumption. |
|
||||||
|
|
||||||
|
Product Owner, Tech Lead and Product Designer are described as collaborating on product direction. That is evidence of cross-functional work, **not** evidence that one line-manages the others.[13][14]
|
||||||
|
|
||||||
|
## What this means for AI strategy
|
||||||
|
|
||||||
|
**Research interpretation, not an approved roadmap:** use the evidenced organizational owners rather than inventing one central AI department.
|
||||||
|
|
||||||
|
- **Engineering enablement:** the AI Architect vacancy focuses on engineering output, adoption, standards and security under the CTO—not ownership of every business AI initiative.[8]
|
||||||
|
- **Marketplace intelligence:** Product/Data has an advertised ranking and recommendations remit, including experimentation and learning-to-rank.[9]
|
||||||
|
- **Operations quality:** operational QA explicitly includes auditing AI-handled support and LLM-assisted scoring; customer support leadership includes AI-assisted support and automation.[11][17]
|
||||||
|
- **Planning assumption:** coordinate these three areas with Product, Operations, Technology and Finance owners. Whether to create a cross-company AI steering group is a future decision, not a finding about current organization.
|
||||||
|
|
||||||
|
## Limits and validation questions
|
||||||
|
|
||||||
|
- **No complete internal chart was found in the reviewed public sources.** This is not a claim that none exists. Research prioritized official About, careers, vacancy and legal pages; it is not an exhaustive employee or vacancy census.
|
||||||
|
- **Job postings are time-bound recruitment evidence.** A vacancy can describe a future role or team. Names, staffing, budgets and every executive reporting line still need company confirmation.
|
||||||
|
- **No reliable total headcount is asserted.** The careers homepage itself contains both “150+” and “200+” descriptions; do not use either to derive department sizes.[2]
|
||||||
|
- **Legal entities are not departments.** The Terms of Service names GWD Processing FZCO, Eldorado Sales LLC and Halfway House OÜ collectively as Eldorado. This establishes contracting language, not a parent/subsidiary hierarchy or the employing entity of each team.[3]
|
||||||
|
- **Keep scope distinctions:** marketplace Risk & Fraud, financial risk, AI security, and corporate compliance may collaborate but should not be collapsed into one assumed reporting chain.
|
||||||
|
|
||||||
|
Before using this as an operating model, confirm: **(1)** which advertised roles are filled, **(2)** executive and functional reporting lines, **(3)** product squad membership and engineering matrix, **(4)** ownership of Payments, Legal/Compliance and Data, and **(5)** the real team roster and capacity. Replace each **A** only when evidence is supplied.
|
||||||
|
|
||||||
|
## Sources
|
||||||
|
|
||||||
|
[1] https://www.eldorado.gg/about-us — Eldorado About us
|
||||||
|
[2] https://careers.eldorado.gg — Eldorado Careers homepage
|
||||||
|
[3] https://www.eldorado.gg/terms-of-service — Eldorado Terms of Service
|
||||||
|
[4] https://careers.eldorado.gg/jobs — Eldorado Jobs — official hiring categories
|
||||||
|
[5] https://careers.eldorado.gg/jobs/8394692-chief-financial-officer — Chief Financial Officer
|
||||||
|
[6] https://careers.eldorado.gg/jobs/8376024-group-engineering-manager — Group Engineering Manager
|
||||||
|
[7] https://careers.eldorado.gg/jobs/8290012-engineering-manager — Engineering Manager
|
||||||
|
[8] https://careers.eldorado.gg/jobs/8175478-ai-architect — AI Architect
|
||||||
|
[9] https://careers.eldorado.gg/jobs/8261309-data-scientist-offer-ranking-recommendations — Data Scientist (Offer Ranking & Recommendations)
|
||||||
|
[10] https://careers.eldorado.gg/jobs/8363463-it-engineer — IT Engineer
|
||||||
|
[11] https://careers.eldorado.gg/jobs/8358613-qa-specialist-operations — QA Specialist (Operations)
|
||||||
|
[12] https://careers.eldorado.gg/jobs/8450323-brand-team-lead — Brand Team Lead
|
||||||
|
[13] https://careers.eldorado.gg/jobs/8404928-product-designer-orders-team — Product Designer (Orders team)
|
||||||
|
[14] https://careers.eldorado.gg/jobs/8253165-product-designer — Product Designer
|
||||||
|
[15] https://careers.eldorado.gg/jobs/8389376-product-owner-sellers-and-operations — Product Owner (Sellers and Operations)
|
||||||
|
[16] https://careers.eldorado.gg/jobs/8487069-talent-acquisition-partner-junior-mid — Talent Acquisition Partner (Junior - Mid)
|
||||||
|
[17] https://careers.eldorado.gg/jobs/8381712-customer-support-team-lead — Customer Support Team Lead
|
||||||
|
[18] https://careers.eldorado.gg/jobs/8483510-trust-resolution-team-lead — Trust & Resolution Team Lead
|
||||||
|
|
||||||
@@ -0,0 +1,261 @@
|
|||||||
|
{
|
||||||
|
"version": 1,
|
||||||
|
"sources": [
|
||||||
|
{
|
||||||
|
"id": 1,
|
||||||
|
"url": "https://www.eldorado.gg/about-us",
|
||||||
|
"title": "Eldorado About us",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Eldorado.gg was founded by two Lithuanian co-founders, Vladas Jurkevičius (CEO) and Lukas Deksnys (COO).",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 2,
|
||||||
|
"url": "https://careers.eldorado.gg",
|
||||||
|
"title": "Eldorado Careers homepage",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "A global team of 150+ professionals shaping the future of in-game commerce at Eldorado.gg",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "A team of 200+ professionals",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 3,
|
||||||
|
"url": "https://www.eldorado.gg/terms-of-service",
|
||||||
|
"title": "Eldorado Terms of Service",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Together, GWD Processing FZCO, Eldorado Sales LLC and Halfway House OÜ are collectively referred to in this Agreement as “Eldorado,” unless otherwise specified.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 4,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs",
|
||||||
|
"title": "Eldorado Jobs — official hiring categories",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Finance & Accounting (1)\nHR & Administration (1)\nMarketing (2)\nOperations (5)\nProduct (3)\nTechnology (9)\nManagement",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 5,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8394692-chief-financial-officer",
|
||||||
|
"title": "Chief Financial Officer",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "This is a key executive role with a broad mandate across financial planning, reporting, cash and capital management, tax, compliance, risk, payments and the Finance team.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 6,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8376024-group-engineering-manager",
|
||||||
|
"title": "Group Engineering Manager",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "We're growing and looking for a Group Engineering Manager to lead an engineering group of several teams, manage 4-5 Engineering Managers, and report directly to Head of Engineering.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 7,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8290012-engineering-manager",
|
||||||
|
"title": "Engineering Manager",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "We’re growing and looking for an Engineering Manager to lead a team of around five software engineers and report to a Group Engineering Manager.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 8,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8175478-ai-architect",
|
||||||
|
"title": "AI Architect",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "We're creating a new role at Eldorado.gg: AI Architect, reporting directly to the CTO.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "You'll start solo: this is an individual-contributor role on paper, with outsized influence in practice. No direct reports required from day one, but a mandate that touches the whole organization.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "Own the security posture of AI usage across engineering, in partnership with Technical Architect on infra and security.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 9,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8261309-data-scientist-offer-ranking-recommendations",
|
||||||
|
"title": "Data Scientist (Offer Ranking & Recommendations)",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Team\nProduct\nRole\nData Team",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 10,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8363463-it-engineer",
|
||||||
|
"title": "IT Engineer",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Own the joiner–mover–leaver process end to end;",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 11,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8358613-qa-specialist-operations",
|
||||||
|
"title": "QA Specialist (Operations)",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Our Operations teams - Customer Support, Trust & Resolution, and Risk & Fraud - are scaling fast, and each measures quality its own way.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "We're creating a new role at Eldorado.gg: QA Specialist (Operations), reporting directly to the COO.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "Audit AI-handled support conversations and root-cause failures into content, routing, or model issues;",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 12,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8450323-brand-team-lead",
|
||||||
|
"title": "Brand Team Lead",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "You will manage a team of several people and report to our CMO.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "Lead and develop a high-performing team spanning brand, organic social, community and brand partnerships;",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "Collaborate closely with the wider Marketing team (Creative, SEO, PPC & Affiliate, Influencer, CRM) as well as Product, Data, and other cross-functional stakeholders.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 13,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8404928-product-designer-orders-team",
|
||||||
|
"title": "Product Designer (Orders team)",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "We're growing and looking for a Product Designer to join our Order team.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "Shape product direction as an equal stakeholder alongside the Product Owner and Tech Lead, owning the end-to-end design process for the order page, dispute flows, and broader post-purchase delivery experience;",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 14,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8253165-product-designer",
|
||||||
|
"title": "Product Designer",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "We’re growing and looking for a Product Designer to join our Categories design team.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 15,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8389376-product-owner-sellers-and-operations",
|
||||||
|
"title": "Product Owner (Sellers and Operations)",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "You’ll own the seller platform domain — the systems and tools that power how sellers operate on Eldorado.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "This includes Seller Portal and dashboards, direct seller integrations, onboarding and verification tools, balances and withdrawals, invoicing, and customer support tooling.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 16,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8487069-talent-acquisition-partner-junior-mid",
|
||||||
|
"title": "Talent Acquisition Partner (Junior - Mid)",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Team\nHR & Administration\nRole\nTalent Acquisition",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 17,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8381712-customer-support-team-lead",
|
||||||
|
"title": "Customer Support Team Lead",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "We’re growing our Customer Operations function and looking for two experienced Team Leads to join our Customer Support and Trust & Resolution teams.",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"text": "Explore AI-assisted support and automation opportunities;",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": 18,
|
||||||
|
"url": "https://careers.eldorado.gg/jobs/8483510-trust-resolution-team-lead",
|
||||||
|
"title": "Trust & Resolution Team Lead",
|
||||||
|
"accessed": "2026-10-02",
|
||||||
|
"quotes": [
|
||||||
|
{
|
||||||
|
"text": "Lead, coach, and grow a team of 5-10 Trust & Resolution Specialists;",
|
||||||
|
"added": "2026-10-02"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,143 @@
|
|||||||
|
#!/usr/bin/env node
|
||||||
|
/** SYNTHETIC reference only. No collectors, network access or production authorization.
|
||||||
|
* Input is a deliberately simplified, reconciled fixture, NOT a production event schema.
|
||||||
|
* Conflicts fail closed (no output); reconciliation/quarantine storage is not implemented.
|
||||||
|
*/
|
||||||
|
import { readFileSync } from 'node:fs';
|
||||||
|
import { pathToFileURL } from 'node:url';
|
||||||
|
export const LABEL = 'SYNTHETIC — illustrative, not Eldorado observations';
|
||||||
|
export const CALCULATION_VERSION = 'synthetic-1.0.0';
|
||||||
|
export const ratio = (n, d, scale = 100) => d === 0 ? null : n / d * scale;
|
||||||
|
export function time(value) {
|
||||||
|
if (typeof value !== 'string' || !/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d{1,3})?(?:Z|\+00:00)$/.test(value)) throw new Error('UTC timestamp required');
|
||||||
|
const t = Date.parse(value);
|
||||||
|
if (!Number.isFinite(t) || new Date(t).toISOString().slice(0,19) !== value.slice(0,19)) throw new Error('Invalid timestamp');
|
||||||
|
return t;
|
||||||
|
}
|
||||||
|
const canonical = value => JSON.stringify(value, (_, v) => v && typeof v === 'object' && !Array.isArray(v) ? Object.fromEntries(Object.entries(v).sort(([a],[b]) => a.localeCompare(b))) : v);
|
||||||
|
const without = (row, keys) => Object.fromEntries(Object.entries(row).filter(([k]) => !keys.includes(k)));
|
||||||
|
export function dedup(events) {
|
||||||
|
const kept = new Map();
|
||||||
|
for (const e of events) {
|
||||||
|
if (!e.producer || !e.event_id) throw new Error('Missing transport identity');
|
||||||
|
if (time(e.received_at) < time(e.occurred_at)) throw new Error('Receipt before occurrence');
|
||||||
|
const key = canonical([e.producer, e.event_id]), prior = kept.get(key);
|
||||||
|
if (prior && canonical(without(prior,['received_at'])) !== canonical(without(e,['received_at']))) throw new Error('Conflicting duplicate requires quarantine');
|
||||||
|
if (!prior || time(e.received_at) < time(prior.received_at)) kept.set(key,e);
|
||||||
|
}
|
||||||
|
return [...kept.values()];
|
||||||
|
}
|
||||||
|
function result(n, d, as_of, {unit = '%', scale = 100, unknown = 0, exclusions = {}, ...extra} = {}) {
|
||||||
|
return {label:LABEL, as_of, calculation_version:CALCULATION_VERSION, numerator:n, denominator:d, unit, value_or_null:ratio(n,d,scale), unknown_count:unknown, exclusions, coverage:{known_percent:ratio(d-unknown,d)}, warnings:unknown ? ['Unknown records remain visible; this is not a failure/non-use rate.'] : [], ...extra};
|
||||||
|
}
|
||||||
|
function taskCohort(events, start, end, as_of) {
|
||||||
|
const lo=time(start), hi=time(end), cutoff=time(as_of);
|
||||||
|
if (lo >= hi) throw new Error('Invalid half-open window');
|
||||||
|
const starts=new Map(), terminal=new Map();
|
||||||
|
for (const e of dedup(events)) {
|
||||||
|
if (time(e.occurred_at)>cutoff || time(e.received_at)>cutoff) continue;
|
||||||
|
if (e.event_type.startsWith('task.') && !e.task_id) throw new Error('Missing task ID');
|
||||||
|
if (e.event_type==='task.started') {
|
||||||
|
if (!Number.isFinite(e.horizon_hours) || e.horizon_hours<0) throw new Error('Missing/invalid observation horizon');
|
||||||
|
const prior=starts.get(e.task_id);
|
||||||
|
if (prior && (time(prior.occurred_at)!==time(e.occurred_at) || prior.horizon_hours!==e.horizon_hours)) throw new Error('Conflicting semantic task start');
|
||||||
|
starts.set(e.task_id,e);
|
||||||
|
} else if (['task.accepted','task.failed','task.abandoned','task.cancelled'].includes(e.event_type)) {
|
||||||
|
if (e.event_type==='task.accepted' && e.independent_evidence!==true) continue;
|
||||||
|
const prior=terminal.get(e.task_id);
|
||||||
|
if (prior && prior.event_type!==e.event_type) throw new Error('Conflicting task terminal state');
|
||||||
|
if (!prior || time(e.occurred_at)<time(prior.occurred_at)) terminal.set(e.task_id,e);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
for (const [id,e] of terminal) if (starts.has(id) && time(e.occurred_at)<time(starts.get(id).occurred_at)) throw new Error('Terminal before start');
|
||||||
|
const eligible = new Set([...starts].filter(([,e]) => time(e.occurred_at)>=lo && time(e.occurred_at)<hi && time(e.occurred_at)+e.horizon_hours*3600000<=cutoff).map(([id])=>id));
|
||||||
|
return {starts, terminal, eligible};
|
||||||
|
}
|
||||||
|
// Snapshot rows are pre-reconciled at fixture as_of. Optional receipt/occurrence
|
||||||
|
// timestamps support late-record tests; missing timestamps are NOT inferred events.
|
||||||
|
function unique(rows, fields=['id']) {
|
||||||
|
const map=new Map();
|
||||||
|
for (const r of rows) {
|
||||||
|
if (fields.some(k=>typeof r[k]!=='string' || !r[k])) throw new Error('Missing semantic identity');
|
||||||
|
const key=canonical(fields.map(k=>r[k])), payload=without(r,['producer','event_id','received_at']);
|
||||||
|
if (map.has(key) && canonical(without(map.get(key),['producer','event_id','received_at']))!==canonical(payload)) throw new Error('Semantic conflict requires reconciliation');
|
||||||
|
const prior=map.get(key);
|
||||||
|
if (!prior || (r.received_at && prior.received_at && time(r.received_at)<time(prior.received_at))) map.set(key,r);
|
||||||
|
}
|
||||||
|
return [...map.values()];
|
||||||
|
}
|
||||||
|
const visible = (r, as_of) => (!r.received_at || time(r.received_at)<=time(as_of)) && (!r.occurred_at || time(r.occurred_at)<=time(as_of));
|
||||||
|
const within = (t,start,end) => time(t)>=time(start) && time(t)<time(end);
|
||||||
|
function horizon(r) {
|
||||||
|
if (!Number.isFinite(r.followup_hours) || r.followup_hours<0) throw new Error('Missing/invalid followup horizon');
|
||||||
|
return r.followup_hours*3600000;
|
||||||
|
}
|
||||||
|
export function association(rows) {
|
||||||
|
const map=new Map();
|
||||||
|
for (const r of rows) {
|
||||||
|
const tuple={skill_id:r.skill_id,revision:r.revision ?? null,version_status:!Object.hasOwn(r,'revision') ? 'missing' : r.revision===null ? 'unknown' : 'known',client:r.client,missing_reason:r.missing_reason ?? null};
|
||||||
|
if (!map.has(r.task_id)) map.set(r.task_id,new Map());
|
||||||
|
map.get(r.task_id).set(canonical(tuple),tuple);
|
||||||
|
}
|
||||||
|
return Object.fromEntries([...map].map(([id, tuples])=>[id,[...tuples.values()].sort((a,b)=>canonical(a).localeCompare(canonical(b)))]));
|
||||||
|
}
|
||||||
|
export function deployments(rows) {
|
||||||
|
const effects=unique(rows,['service_id','deployment_id']).filter(r=>r.environment==='production' && r.production_effect===true);
|
||||||
|
return {effects:effects.length,successful:effects.filter(r=>r.succeeded===true).length,change_fail_rate:ratio(effects.filter(r=>r.intervention===true).length,effects.length),rework_rate:ratio(effects.filter(r=>r.planned===false && Boolean(r.incident_id)).length,effects.length)};
|
||||||
|
}
|
||||||
|
export function matureDefects(changes,defects,as_of,start='0001-01-01T00:00:00Z',end=as_of) {
|
||||||
|
const eligible=unique(changes).filter(c=>visible(c,as_of) && within(c.accepted_at,start,end) && time(c.accepted_at)+horizon(c)<=time(as_of));
|
||||||
|
const affected=new Set();
|
||||||
|
for (const d of unique(defects)) {
|
||||||
|
const c=eligible.find(c=>c.id===d.change_id);
|
||||||
|
if (c && d.confirmed===true && visible(d,as_of) && time(d.detected_at)>=time(c.accepted_at) && time(d.detected_at)<=time(c.accepted_at)+horizon(c)) affected.add(c.id);
|
||||||
|
}
|
||||||
|
return [affected.size,eligible.length];
|
||||||
|
}
|
||||||
|
export function survey(rows,invited,as_of) {
|
||||||
|
if (!Number.isInteger(invited) || invited<0) throw new Error('Invalid invitation count');
|
||||||
|
const all=unique(rows), valid=all.filter(r=>Number.isInteger(r.score) && r.score>=1 && r.score<=5);
|
||||||
|
if (all.length>invited) throw new Error('Responses exceed invitations');
|
||||||
|
const suppressed=valid.length<5;
|
||||||
|
return result(suppressed?null:valid.reduce((n,r)=>n+r.score,0),valid.length,as_of,{unit:'points (1–5)',scale:1,value_or_null:suppressed?null:ratio(valid.reduce((n,r)=>n+r.score,0),valid.length,1),suppressed,exclusions:{invalid_answers:all.length-valid.length},coverage:{response_percent:ratio(valid.length,invited)},distribution:suppressed?null:Object.fromEntries([1,2,3,4,5].map(s=>[s,valid.filter(r=>r.score===s).length])),warnings:suppressed?['People cohort below five suppressed.']:[]});
|
||||||
|
}
|
||||||
|
export function calculate(f) {
|
||||||
|
if (f.synthetic!==true || f.schema_version!=='1.0') throw new Error('Explicit synthetic schema 1.0 fixture required');
|
||||||
|
const {start,end,as_of}=f, kpis={};
|
||||||
|
kpis['validated-task-success']=success(f.events,start,end,as_of);
|
||||||
|
const trials=unique(f.selection).filter(r=>visible(r,as_of));
|
||||||
|
const scored=trials.filter(r=>typeof r.relevant==='boolean' && typeof r.activated==='boolean');
|
||||||
|
const tp=scored.filter(r=>r.relevant && r.activated).length;
|
||||||
|
for (const [id,den] of [['selection-precision',scored.filter(r=>r.activated).length],['selection-recall',scored.filter(r=>r.relevant).length]]) {
|
||||||
|
kpis[id]=result(tp,den,as_of,{unknown:trials.length-scored.length,coverage:{scorable_percent:ratio(scored.length,trials.length)},exclusions:{unscorable:trials.length-scored.length}});
|
||||||
|
}
|
||||||
|
const effects=unique(f.deployments,['service_id','deployment_id']).filter(r=>visible(r,as_of) && r.environment==='production' && r.production_effect===true && within(r.deployed_at,start,end));
|
||||||
|
const mature=effects.filter(r=>time(r.deployed_at)+horizon(r)<=time(as_of));
|
||||||
|
kpis['change-fail-rate']=result(mature.filter(r=>r.intervention===true).length,mature.length,as_of,{unknown:mature.filter(r=>typeof r.intervention!=='boolean').length,exclusions:{immature:effects.length-mature.length}});
|
||||||
|
kpis['deployment-rework-rate']=result(effects.filter(r=>r.planned===false && Boolean(r.incident_id)).length,effects.length,as_of,{unknown:effects.filter(r=>typeof r.planned!=='boolean' || (r.planned===false && !Object.hasOwn(r,'incident_id'))).length});
|
||||||
|
const [affected,accepted]=matureDefects(f.changes,f.defects,as_of,start,end);
|
||||||
|
const matureChanges=unique(f.changes).filter(r=>visible(r,as_of) && within(r.accepted_at,start,end) && time(r.accepted_at)+horizon(r)<=time(as_of));
|
||||||
|
kpis['escaped-quality-rate']=result(affected,accepted,as_of,{unknown:matureChanges.filter(r=>r.linkage_complete!==true).length,exclusions:{outside_window_immature_or_late:unique(f.changes).length-matureChanges.length},pending_triage_count:unique(f.defects).filter(r=>visible(r,as_of) && r.confirmed!==true).length});
|
||||||
|
const attempts=unique(f.attempts).filter(r=>visible(r,as_of));
|
||||||
|
kpis['policy-effects']=result(attempts.filter(r=>r.actual_effect===true).length,attempts.length,as_of,{unknown:attempts.filter(r=>typeof r.actual_effect!=='boolean').length,blocked_count:attempts.filter(r=>r.blocked===true).length});
|
||||||
|
const {eligible}=taskCohort(f.events,start,end,as_of);
|
||||||
|
const costs=unique(f.costs).filter(r=>visible(r,as_of) && (eligible.has(r.task_id) || r.task_id==='shared_pool'));
|
||||||
|
if (costs.some(r=>r.currency!==f.currency || !Number.isFinite(r.amount) || r.amount<0)) throw new Error('Invalid cost or mixed currency: approved conversion required');
|
||||||
|
const missing=f.expected_cost_buckets.filter(b=>!costs.some(r=>r.bucket===b));
|
||||||
|
kpis['cost-per-accepted-outcome']=result(costs.reduce((sum,r)=>sum+r.amount,0),kpis['validated-task-success'].numerator,as_of,{scale:1,unit:`${f.currency}/accepted outcome`,partial_estimate:missing.length>0,coverage:{missing_cost_buckets:missing},warnings:missing.length?['Partial estimate, not total cost; missing cost buckets.']:[]});
|
||||||
|
kpis['human-experience']=survey(f.survey.responses.filter(r=>visible(r,as_of)),f.survey.invited,as_of);
|
||||||
|
return {label:LABEL,as_of,calculation_version:CALCULATION_VERSION,window:{start,end},kpis,associations:association(f.associations),not_implemented:['supported-bundle-coverage','useful-adoption','change-lead-time','deployment-frequency','failed-deployment-recovery-time','maintenance-health','department-outcome'],limitations:['Synthetic simplified reconciled snapshots only; not the full production event envelope.','Snapshot rows without timestamps are assumed frozen at as_of, not missing-event evidence.','No causal attribution, uncertainty intervals, authorization or telemetry collection.','Survey implements primary item only; no cross-slice disclosure protection.','Defect severity strata and policy severity counts are not implemented.']};
|
||||||
|
}
|
||||||
|
if (process.argv[1] && import.meta.url===pathToFileURL(process.argv[1]).href) {
|
||||||
|
try {
|
||||||
|
if (process.argv.length>3) throw new Error('Usage: node scripts/ai-kpi.mjs [synthetic-fixture.json]');
|
||||||
|
const source=process.argv[2] ?? new URL('./fixtures/ai-kpi-synthetic.json',import.meta.url);
|
||||||
|
console.log(JSON.stringify(calculate(JSON.parse(readFileSync(source,'utf8'))),null,2));
|
||||||
|
} catch (error) { console.error(`Synthetic KPI calculation failed: ${error.message}`); process.exitCode=1; }
|
||||||
|
}
|
||||||
|
export function success(events,start,end,as_of) {
|
||||||
|
const {starts,terminal,eligible}=taskCohort(events,start,end,as_of);
|
||||||
|
const n=[...eligible].filter(id=>terminal.get(id)?.event_type==='task.accepted').length;
|
||||||
|
const unknown=[...eligible].filter(id=>!terminal.has(id)).length;
|
||||||
|
return result(n,eligible.size,as_of,{unknown, known_outcome_coverage:ratio(eligible.size-unknown,eligible.size), orphan_terminal_count:[...terminal.keys()].filter(id=>!starts.has(id)).length, excluded_start_count:starts.size-eligible.size, exclusions:{outside_window_or_immature:starts.size-eligible.size}});
|
||||||
|
}
|
||||||
@@ -0,0 +1,153 @@
|
|||||||
|
import test from 'node:test';
|
||||||
|
import assert from 'node:assert/strict';
|
||||||
|
import { existsSync, readFileSync } from 'node:fs';
|
||||||
|
const moduleUrl = new URL('./ai-kpi.mjs', import.meta.url);
|
||||||
|
import { spawnSync } from 'node:child_process';
|
||||||
|
import * as api from './ai-kpi.mjs';
|
||||||
|
const fixture = () => JSON.parse(readFileSync(new URL('./fixtures/ai-kpi-synthetic.json', import.meta.url)));
|
||||||
|
test('semantic change duplicates preserve the complete quality report including exclusions', () => {
|
||||||
|
const original = fixture();
|
||||||
|
const repeated = fixture();
|
||||||
|
repeated.changes.push({...repeated.changes[0]});
|
||||||
|
assert.deepEqual(api.calculate(repeated).kpis['escaped-quality-rate'], api.calculate(original).kpis['escaped-quality-rate']);
|
||||||
|
});
|
||||||
|
test('CLI report exposes implemented KPI contracts and explicit omissions', async () => {
|
||||||
|
const m = await import(moduleUrl);
|
||||||
|
assert.equal(typeof m.calculate, 'function');
|
||||||
|
const r = m.calculate(fixture());
|
||||||
|
assert.equal(Object.keys(r.kpis).length, 9);
|
||||||
|
assert.equal(r.not_implemented.length, 7);
|
||||||
|
assert.equal(r.kpis['cost-per-accepted-outcome'].value_or_null, 60);
|
||||||
|
assert.equal(r.kpis['selection-precision'].value_or_null, 50);
|
||||||
|
assert.equal(r.kpis['selection-recall'].value_or_null, 50);
|
||||||
|
assert.equal(r.kpis['change-fail-rate'].value_or_null, 100);
|
||||||
|
assert.equal(r.kpis['deployment-rework-rate'].value_or_null, 100);
|
||||||
|
assert.equal(r.kpis['escaped-quality-rate'].value_or_null, 100);
|
||||||
|
assert.equal(r.kpis['policy-effects'].value_or_null, 50);
|
||||||
|
assert.equal(r.kpis['human-experience'].value_or_null, 4);
|
||||||
|
});
|
||||||
|
function event(id,task,kind,day=1,extra={}) {
|
||||||
|
const timestamp=`2026-01-${String(day).padStart(2,'0')}T00:00:00Z`;
|
||||||
|
return {producer:'synthetic',event_id:id,task_id:task,event_type:kind,occurred_at:timestamp,received_at:timestamp,...extra};
|
||||||
|
}
|
||||||
|
const run = (events,as_of=fixture().as_of) => api.success(events,fixture().start,fixture().end,as_of);
|
||||||
|
test('transport duplicates and redelivery use earliest receipt in either order',()=>{
|
||||||
|
const f=fixture(), duplicate={...f.events[0],received_at:'2026-01-06T00:00:00Z'};
|
||||||
|
assert.deepEqual(run([...f.events,f.events[0]]),run(f.events));
|
||||||
|
assert.deepEqual(run([...f.events,duplicate]),run(f.events));
|
||||||
|
assert.deepEqual(run([duplicate,...f.events]),run(f.events));
|
||||||
|
});
|
||||||
|
test('transport conflicts fail closed',()=>assert.throws(()=>run([...fixture().events,{...fixture().events[0],task_id:'other'}]),/Conflicting duplicate/));
|
||||||
|
test('retry and cross-feed semantic duplicate never add tasks',()=>{
|
||||||
|
const f=fixture();
|
||||||
|
assert.equal(run([...f.events,event('retry','accepted','attempt.started',2),event('retry-fail','accepted','attempt.failed',2),{...f.events[0],producer:'mirror',event_id:'mirror-start'}]).denominator,4);
|
||||||
|
});
|
||||||
|
test('immature task and half-open end excluded',()=>{
|
||||||
|
const r=run([...fixture().events,event('boundary','boundary','task.started',5,{horizon_hours:0})]);
|
||||||
|
assert.equal(r.excluded_start_count,2);
|
||||||
|
assert.equal(r.denominator,4);
|
||||||
|
});
|
||||||
|
test('all implemented zero denominator values are null',()=>{
|
||||||
|
const f=fixture();
|
||||||
|
for (const k of ['events','selection','deployments','changes','defects','attempts','costs','associations']) f[k]=[];
|
||||||
|
f.survey={invited:0,responses:[]};
|
||||||
|
for (const r of Object.values(api.calculate(f).kpis)) assert.equal(r.value_or_null,null);
|
||||||
|
});
|
||||||
|
test('orphan terminal does not increase accepted count',()=>{
|
||||||
|
const r=run([...fixture().events,event('orphan','absent','task.accepted',2,{independent_evidence:true})]);
|
||||||
|
assert.equal(r.orphan_terminal_count,1); assert.equal(r.numerator,1);
|
||||||
|
});
|
||||||
|
test('late arrival restates only when received',()=>{
|
||||||
|
const events=[...fixture().events,event('late','unknown','task.accepted',3,{independent_evidence:true,received_at:'2026-01-06T00:00:00Z'})];
|
||||||
|
assert.equal(run(events).numerator,1);
|
||||||
|
assert.equal(run(events,'2026-01-06T00:00:00Z').numerator,2);
|
||||||
|
});
|
||||||
|
test('unknown, absent and mixed versions retained without latest inference',()=>{
|
||||||
|
const rows=['a','b','a',null].map(revision=>({task_id:'t',skill_id:'s',revision,client:'Cline'}));
|
||||||
|
rows.push({task_id:'t',skill_id:'s',client:'Cline'});
|
||||||
|
const r=api.association(rows).t;
|
||||||
|
assert.equal(r.length,4);
|
||||||
|
assert.equal(r.filter(x=>x.version_status==='known').length,2);
|
||||||
|
assert.deepEqual(new Set(r.filter(x=>x.revision===null).map(x=>x.version_status)),new Set(['missing','unknown']));
|
||||||
|
});
|
||||||
|
test('invalid timestamps, UTC offsets, receipt order and terminal order rejected',()=>{
|
||||||
|
for(const t of ['no','2026-02-30T00:00:00Z','2026-01-01T00:00:00+01:00']) assert.throws(()=>api.time(t));
|
||||||
|
assert.throws(()=>run([event('s','t','task.started',2,{horizon_hours:24}),event('a','t','task.accepted',1,{independent_evidence:true})]),/Terminal before start/);
|
||||||
|
assert.throws(()=>api.dedup([event('s','t','task.started',2,{received_at:'2026-01-01T00:00:00Z'})]),/Receipt before/);
|
||||||
|
});
|
||||||
|
test('missing horizon is not silently mature',()=>assert.throws(()=>run([event('s','t','task.started')]),/horizon/));
|
||||||
|
test('conflicting terminal and semantic start require reconciliation',()=>{
|
||||||
|
assert.throws(()=>run([...fixture().events,event('conflict','accepted','task.failed',3)]),/Conflicting task terminal/);
|
||||||
|
assert.throws(()=>run([...fixture().events,event('conflict','accepted','task.started',2,{horizon_hours:48})]),/semantic task start/);
|
||||||
|
});
|
||||||
|
test('no independent acceptance evidence means unknown, not accepted',()=>{
|
||||||
|
const r=run([event('s','t','task.started',1,{horizon_hours:24}),event('a','t','task.accepted',2)]);
|
||||||
|
assert.equal(r.numerator,0); assert.equal(r.unknown_count,1);
|
||||||
|
});
|
||||||
|
test('pre-start cancellation excluded; post-start cancellation remains denominator',()=>{
|
||||||
|
const r=run([event('pre','never','task.cancelled',1,{before_start:true}),event('s','started','task.started',1,{horizon_hours:24}),event('post','started','task.cancelled',2,{before_start:false})]);
|
||||||
|
assert.deepEqual([r.numerator,r.denominator,r.unknown_count],[0,1,0]);
|
||||||
|
});
|
||||||
|
test('deployment retries collapse; unknown rework not treated as planned',()=>{
|
||||||
|
const row=fixture().deployments[0];
|
||||||
|
assert.deepEqual(api.deployments([row,{...row,producer:'mirror',event_id:'2'}]),{effects:1,successful:1,change_fail_rate:100,rework_rate:100});
|
||||||
|
assert.equal(api.deployments([{...row,planned:null}]).rework_rate,0);
|
||||||
|
const f=fixture(); f.deployments[0].planned=null;
|
||||||
|
const r=api.calculate(f).kpis['deployment-rework-rate'];
|
||||||
|
assert.equal(r.denominator,1); assert.equal(r.unknown_count,1);
|
||||||
|
assert.throws(()=>api.deployments([row,{...row,planned:true}]),/Semantic conflict/);
|
||||||
|
});
|
||||||
|
test('mature deployment denominator retains unsuccessful production effects',()=>{
|
||||||
|
const f=fixture(); f.deployments[0].succeeded=false;
|
||||||
|
assert.equal(api.calculate(f).kpis['change-fail-rate'].denominator,1);
|
||||||
|
f.deployments[0].followup_hours=1000;
|
||||||
|
assert.equal(api.calculate(f).kpis['change-fail-rate'].denominator,0);
|
||||||
|
});
|
||||||
|
test('mature defect followup is linked, bounded and deduplicated',()=>{
|
||||||
|
const f=fixture();
|
||||||
|
f.changes.push({id:'new',accepted_at:'2026-01-04T00:00:00Z',followup_hours:48});
|
||||||
|
f.defects.push({...f.defects[0],id:'new-defect',change_id:'new'});
|
||||||
|
assert.deepEqual(api.matureDefects(f.changes,[...f.defects,f.defects[0]],f.as_of),[1,1]);
|
||||||
|
f.defects[0].detected_at='2026-01-04T00:00:00Z';
|
||||||
|
assert.deepEqual(api.matureDefects(f.changes,f.defects,f.as_of),[0,1]);
|
||||||
|
});
|
||||||
|
test('cost includes failed attempts, flags partial buckets and rejects mixed currencies',()=>{
|
||||||
|
const f=fixture(); let r=api.calculate(f).kpis['cost-per-accepted-outcome'];
|
||||||
|
assert.equal(r.numerator,60); assert.equal(r.partial_estimate,true);
|
||||||
|
f.costs.push({...f.costs[0]});
|
||||||
|
assert.equal(api.calculate(f).kpis['cost-per-accepted-outcome'].numerator,60);
|
||||||
|
f.costs.pop(); // Currency validation is separate from conflicting duplicate validation.
|
||||||
|
f.costs[0].currency='USD'; assert.throws(()=>api.calculate(f),/mixed currency/);
|
||||||
|
});
|
||||||
|
test('blocked attempts are not prohibited effects; unknown audits remain denominator',()=>{
|
||||||
|
const f=fixture(); f.attempts.push({id:'unknown'});
|
||||||
|
const r=api.calculate(f).kpis['policy-effects'];
|
||||||
|
assert.deepEqual([r.numerator,r.denominator,r.blocked_count,r.unknown_count],[1,3,1,1]);
|
||||||
|
});
|
||||||
|
test('survey suppresses small groups including sum and distribution',()=>{
|
||||||
|
const f=fixture(), r=api.survey(f.survey.responses.slice(0,4),10,f.as_of);
|
||||||
|
assert.equal(r.value_or_null,null); assert.equal(r.numerator,null); assert.equal(r.distribution,null);
|
||||||
|
});
|
||||||
|
test('required output fields accompany every implemented KPI',()=>{
|
||||||
|
const required=['label','as_of','calculation_version','numerator','denominator','unit','value_or_null','unknown_count','exclusions','coverage','warnings'];
|
||||||
|
for (const r of Object.values(api.calculate(fixture()).kpis)) for(const key of required) assert.ok(Object.hasOwn(r,key),key);
|
||||||
|
});
|
||||||
|
test('non-synthetic and unknown fixture schemas rejected',()=>{
|
||||||
|
assert.throws(()=>api.calculate({...fixture(),synthetic:false}),/synthetic/);
|
||||||
|
assert.throws(()=>api.calculate({...fixture(),schema_version:'future'}),/schema/);
|
||||||
|
});
|
||||||
|
test('CLI executes default and explicit fixture and fails visibly for missing input',()=>{
|
||||||
|
for(const args of [[],[new URL('./fixtures/ai-kpi-synthetic.json',import.meta.url).pathname]]) {
|
||||||
|
const r=spawnSync(process.execPath,[moduleUrl.pathname,...args],{encoding:'utf8'});
|
||||||
|
assert.equal(r.status,0,r.stderr); assert.equal(JSON.parse(r.stdout).kpis['validated-task-success'].value_or_null,25);
|
||||||
|
}
|
||||||
|
const r=spawnSync(process.execPath,[moduleUrl.pathname,'/nonexistent/synthetic-fixture.json'],{encoding:'utf8'});
|
||||||
|
assert.equal(r.status,1); assert.equal(r.stdout,''); assert.match(r.stderr,/failed/);
|
||||||
|
});
|
||||||
|
test('synthetic task calculator exists and retains failed, abandoned, unknown tasks', async () => {
|
||||||
|
assert.ok(existsSync(moduleUrl), 'calculator implementation is required');
|
||||||
|
const { success } = await import(moduleUrl);
|
||||||
|
const f = JSON.parse(readFileSync(new URL('./fixtures/ai-kpi-synthetic.json', import.meta.url)));
|
||||||
|
const r = success(f.events, f.start, f.end, f.as_of);
|
||||||
|
assert.deepEqual([r.numerator, r.denominator, r.unknown_count, r.value_or_null, r.known_outcome_coverage], [1,4,1,25,75]);
|
||||||
|
});
|
||||||
@@ -0,0 +1,43 @@
|
|||||||
|
const {chromium}=require('playwright');
|
||||||
|
const assert=require('node:assert/strict');
|
||||||
|
const fs=require('node:fs');
|
||||||
|
(async()=>{
|
||||||
|
const base=process.argv[2]||'http://127.0.0.1:4173';
|
||||||
|
const label=process.argv[3]||'accepted';
|
||||||
|
const browser=await chromium.launch({headless:true,executablePath:process.env.PLAYWRIGHT_CHROMIUM_EXECUTABLE,args:['--no-sandbox']});
|
||||||
|
const results=[];fs.mkdirSync(`.cache/story-${label}`,{recursive:true});
|
||||||
|
try{
|
||||||
|
for(const width of [1440,390]){
|
||||||
|
const context=await browser.newContext({viewport:{width,height:1000}});
|
||||||
|
const page=await context.newPage();
|
||||||
|
for(const id of ['index','target-operating-model','skills-governance','skills-quality','skills-adoption','measurement','skills-maintenance','roadmap']){
|
||||||
|
const response=await page.goto(`${base}/eldorado-v1/documentation/strategy/${id==='index'?'':id+'/'}`,{waitUntil:'networkidle'});assert.equal(response.status(),200);
|
||||||
|
const panel=page.locator('.archify-panel--story');
|
||||||
|
const iframe=panel.locator(width===390?'.story-mobile':'.story-desktop');await iframe.scrollIntoViewIfNeeded();
|
||||||
|
const frame=await (await iframe.elementHandle()).contentFrame();await frame.locator('svg[role="img"]').waitFor();
|
||||||
|
const geometry=await frame.locator('svg[role="img"]').evaluate(svg=>{
|
||||||
|
const nodes=[...svg.querySelectorAll('[data-node-id]')].map(n=>{const r=n.getBoundingClientRect();return {id:n.id,x:r.x,y:r.y,right:r.right,bottom:r.bottom};});
|
||||||
|
return {width:innerWidth,height:innerHeight,nodes,svg:svg.getBoundingClientRect().toJSON(),minLabel:Math.min(...[...svg.querySelectorAll('text[data-node-label]')].map(n=>parseFloat(getComputedStyle(n).fontSize)*n.getScreenCTM().a))};
|
||||||
|
});
|
||||||
|
assert(geometry.nodes.length>=5 && geometry.nodes.length<=7,id);
|
||||||
|
for(const n of geometry.nodes) assert(n.x>=0 && n.y>=0 && n.right<=geometry.width+1 && n.bottom<=geometry.height+1,`${id} ${width} clipped ${JSON.stringify(n)} / ${geometry.height}`);
|
||||||
|
const data=await page.locator('.strategy-content').evaluate(el=>({words:el.innerText.trim().split(/\s+/).length,overflow:document.documentElement.scrollWidth>innerWidth,openDetails:el.querySelectorAll('details[open]').length}));
|
||||||
|
assert(data.words<=200,id);assert(!data.overflow,id);assert.equal(data.openDetails,0,id);
|
||||||
|
await page.evaluate(()=>scrollTo(0,0));await page.screenshot({path:`.cache/story-${label}/${width}-${id}.png`,fullPage:true});
|
||||||
|
const opener=panel.getByRole('button',{name:/^Expand /});await opener.click();
|
||||||
|
const close=panel.getByRole('button',{name:'Close full-screen diagram',exact:true});await close.waitFor({state:'visible'});
|
||||||
|
assert.equal(await close.innerText(),'×');assert(await close.evaluate(n=>n===document.activeElement));
|
||||||
|
const box=await close.boundingBox();assert.equal(box.width,44);assert.equal(box.height,44);
|
||||||
|
await close.click();assert(await opener.evaluate(n=>n===document.activeElement));
|
||||||
|
await opener.click();await close.waitFor({state:'visible'});await page.keyboard.press('Escape');await page.waitForFunction(()=>!document.querySelector('.archify-panel--story dialog').open);assert(await opener.evaluate(n=>n===document.activeElement));
|
||||||
|
const summary=page.locator('.strategy-content > details > summary').first();await summary.click();assert(await summary.evaluate(n=>n.parentElement.open));await summary.click();
|
||||||
|
results.push({id,width,...data,geometry,modalClick:true,modalEscape:true,focusRestored:true,details:true});fs.writeFileSync(`.cache/story-${label}/results.json`,JSON.stringify(results,null,2));
|
||||||
|
}
|
||||||
|
await page.goto(`${base}/eldorado-v1/documentation/strategy/measurement/#validated-task-success`,{waitUntil:'networkidle'});
|
||||||
|
const heading=page.locator('#validated-task-success');await heading.waitFor({state:'visible'});
|
||||||
|
assert(await heading.evaluate(n=>n.closest('details').open),'hash should open metric reference');
|
||||||
|
await context.close();
|
||||||
|
}
|
||||||
|
console.log(`PASS ${results.length} desktop/mobile cases, clipping, default word count, details, modal click/Escape/focus and KPI hash navigation`);
|
||||||
|
} finally {await browser.close();}
|
||||||
|
})().catch(e=>{console.error(e);process.exitCode=1});
|
||||||
@@ -24,7 +24,6 @@ for (const file of readdirSync('diagrams').sort()) {
|
|||||||
run(['deliver',type,input,output,'--quality','showcase','--json']);
|
run(['deliver',type,input,output,'--quality','showcase','--json']);
|
||||||
run(['check',output,'--json','--require-provenance']);
|
run(['check',output,'--json','--require-provenance']);
|
||||||
renameSync(`static/diagrams/${name}/index.delivery.json`, `.cache/archify/${name}.delivery.json`);
|
renameSync(`static/diagrams/${name}/index.delivery.json`, `.cache/archify/${name}.delivery.json`);
|
||||||
copyFileSync(input,`static/diagrams/${name}.json`);
|
|
||||||
}
|
}
|
||||||
copyFileSync('vendor/archify/LICENSE','static/diagrams/ARCHIFY-LICENSE.txt');
|
copyFileSync('vendor/archify/LICENSE','static/diagrams/ARCHIFY-LICENSE.txt');
|
||||||
copyFileSync('vendor/archify/THIRD_PARTY_NOTICES.md','static/diagrams/THIRD-PARTY-NOTICES.md');
|
copyFileSync('vendor/archify/THIRD_PARTY_NOTICES.md','static/diagrams/THIRD-PARTY-NOTICES.md');
|
||||||
@@ -0,0 +1,37 @@
|
|||||||
|
{
|
||||||
|
"synthetic": true,
|
||||||
|
"label": "SYNTHETIC — illustrative, not Eldorado observations",
|
||||||
|
"schema_version": "1.0",
|
||||||
|
"start": "2026-01-01T00:00:00Z",
|
||||||
|
"end": "2026-01-05T00:00:00Z",
|
||||||
|
"as_of": "2026-01-05T00:00:00Z",
|
||||||
|
"events": [
|
||||||
|
{"producer":"synthetic","event_id":"sa","task_id":"accepted","event_type":"task.started","occurred_at":"2026-01-01T00:00:00Z","received_at":"2026-01-01T00:00:00Z","horizon_hours":48},
|
||||||
|
{"producer":"synthetic","event_id":"sf","task_id":"failed","event_type":"task.started","occurred_at":"2026-01-01T00:00:00Z","received_at":"2026-01-01T00:00:00Z","horizon_hours":48},
|
||||||
|
{"producer":"synthetic","event_id":"sb","task_id":"abandoned","event_type":"task.started","occurred_at":"2026-01-01T00:00:00Z","received_at":"2026-01-01T00:00:00Z","horizon_hours":48},
|
||||||
|
{"producer":"synthetic","event_id":"su","task_id":"unknown","event_type":"task.started","occurred_at":"2026-01-01T00:00:00Z","received_at":"2026-01-01T00:00:00Z","horizon_hours":48},
|
||||||
|
{"producer":"synthetic","event_id":"a","task_id":"accepted","event_type":"task.accepted","occurred_at":"2026-01-02T00:00:00Z","received_at":"2026-01-02T00:00:00Z","independent_evidence":true},
|
||||||
|
{"producer":"synthetic","event_id":"f","task_id":"failed","event_type":"task.failed","occurred_at":"2026-01-02T00:00:00Z","received_at":"2026-01-02T00:00:00Z"},
|
||||||
|
{"producer":"synthetic","event_id":"b","task_id":"abandoned","event_type":"task.abandoned","occurred_at":"2026-01-02T00:00:00Z","received_at":"2026-01-02T00:00:00Z"},
|
||||||
|
{"producer":"synthetic","event_id":"new","task_id":"immature","event_type":"task.started","occurred_at":"2026-01-04T00:00:00Z","received_at":"2026-01-04T00:00:00Z","horizon_hours":48}
|
||||||
|
],
|
||||||
|
"selection": [
|
||||||
|
{"id":"trial-a","relevant":true,"activated":true},
|
||||||
|
{"id":"trial-b","relevant":false,"activated":true},
|
||||||
|
{"id":"trial-c","relevant":true,"activated":false},
|
||||||
|
{"id":"trial-d","relevant":null,"activated":null}
|
||||||
|
],
|
||||||
|
"deployments": [{"service_id":"service-a","deployment_id":"deploy-a","environment":"production","production_effect":true,"succeeded":true,"intervention":true,"planned":false,"incident_id":"incident-a","deployed_at":"2026-01-02T00:00:00Z","followup_hours":24}],
|
||||||
|
"changes": [{"id":"change-a","accepted_at":"2026-01-01T00:00:00Z","followup_hours":48,"linkage_complete":true}],
|
||||||
|
"defects": [{"id":"defect-a","change_id":"change-a","confirmed":true,"detected_at":"2026-01-02T00:00:00Z"}],
|
||||||
|
"attempts": [{"id":"attempt-a","actual_effect":false,"blocked":true},{"id":"attempt-b","actual_effect":true,"blocked":false}],
|
||||||
|
"costs": [{"id":"cost-a","task_id":"accepted","amount":40,"currency":"EUR","bucket":"compute"},{"id":"cost-f","task_id":"failed","amount":20,"currency":"EUR","bucket":"compute"}],
|
||||||
|
"currency":"EUR",
|
||||||
|
"expected_cost_buckets":["compute","licenses","tooling","review","rework"],
|
||||||
|
"survey": {"invited":10,"responses":[{"id":"token-a","score":4},{"id":"token-b","score":5},{"id":"token-c","score":3},{"id":"token-d","score":4},{"id":"token-e","score":4}]},
|
||||||
|
"associations": [
|
||||||
|
{"task_id":"accepted","skill_id":"synthetic-skill","revision":"revision-a","client":"Cline"},
|
||||||
|
{"task_id":"accepted","skill_id":"synthetic-skill","revision":"revision-b","client":"Cline"},
|
||||||
|
{"task_id":"unknown","skill_id":"synthetic-skill","revision":null,"client":"Claude Code","missing_reason":"not_exposed"}
|
||||||
|
]
|
||||||
|
}
|
||||||
+94
-7
@@ -20,6 +20,7 @@ test('real build removes stale diagrams, keeps receipts private and rejects coll
|
|||||||
writeSpec('old');
|
writeSpec('old');
|
||||||
let result = build(); assert.equal(result.status,0,result.stderr);
|
let result = build(); assert.equal(result.status,0,result.stderr);
|
||||||
assert(existsSync(join(root,'static/diagrams/old/index.html')));
|
assert(existsSync(join(root,'static/diagrams/old/index.html')));
|
||||||
|
assert(!existsSync(join(root,'static/diagrams/old.json')));
|
||||||
assert(!readdirSync(join(root,'static/diagrams'),{recursive:true}).some(p=>p.endsWith('.delivery.json')));
|
assert(!readdirSync(join(root,'static/diagrams'),{recursive:true}).some(p=>p.endsWith('.delivery.json')));
|
||||||
unlinkSync(join(root,'diagrams/old.architecture.json'));
|
unlinkSync(join(root,'diagrams/old.architecture.json'));
|
||||||
writeSpec('new');
|
writeSpec('new');
|
||||||
@@ -42,7 +43,7 @@ test('three independent section menus and Structure first', () => {
|
|||||||
for (const section of ['Organization', 'Strategy', 'Contribution']) assert(config.includes(`label: '${section}'`));
|
for (const section of ['Organization', 'Strategy', 'Contribution']) assert(config.includes(`label: '${section}'`));
|
||||||
assert(!config.includes("label: 'Documentation'"));
|
assert(!config.includes("label: 'Documentation'"));
|
||||||
assert(!config.includes("label: 'Maintainer guide'"));
|
assert(!config.includes("label: 'Maintainer guide'"));
|
||||||
assert(read('sidebars/organization.ts').includes("organizationSidebar: ['structure']"));
|
assert(read('sidebars/organization.ts').includes("organizationSidebar: ['structure', 'collaboration', 'sdlc']"));
|
||||||
for (const section of ['organization','strategy','contribution']) assert(config.includes(`id: '${section}'`));
|
for (const section of ['organization','strategy','contribution']) assert(config.includes(`id: '${section}'`));
|
||||||
});
|
});
|
||||||
test('Archify is pinned, licensed and rebuilt, not a remote embed', () => {
|
test('Archify is pinned, licensed and rebuilt, not a remote embed', () => {
|
||||||
@@ -55,12 +56,98 @@ test('Archify is pinned, licensed and rebuilt, not a remote embed', () => {
|
|||||||
assert(wrapper.includes('sandbox="allow-scripts allow-downloads"'));
|
assert(wrapper.includes('sandbox="allow-scripts allow-downloads"'));
|
||||||
assert(!wrapper.includes('allow-same-origin'));
|
assert(!wrapper.includes('allow-same-origin'));
|
||||||
assert(wrapper.includes('useBaseUrl'));
|
assert(wrapper.includes('useBaseUrl'));
|
||||||
|
assert(wrapper.includes('showModal()') && wrapper.includes('onClose='));
|
||||||
|
assert(!wrapper.includes('target="_blank"'));
|
||||||
|
assert(wrapper.includes('Close full-screen diagram'));
|
||||||
|
assert(!wrapper.includes('JSON source') && !wrapper.includes('download>'));
|
||||||
|
assert(!wrapper.includes('Open full viewer'));
|
||||||
|
assert(wrapper.includes('aria-label={`Expand ${title}`}'));
|
||||||
|
assert(wrapper.includes('aria-hidden="true"'));
|
||||||
|
assert(read('src/css/custom.css').includes('justify-content: flex-end'));
|
||||||
});
|
});
|
||||||
test('example is explicitly illustrative and contains valid connected nodes', () => {
|
test('full-screen close is cross-only with an accessible name and square touch target', () => {
|
||||||
|
const wrapper = read('src/components/ArchifyDiagram/index.tsx');
|
||||||
|
const button = wrapper.match(/<button[^>]*aria-label="Close full-screen diagram"[^>]*>(.*?)<\/button>/s);
|
||||||
|
assert(button, 'close button retains its accessible name');
|
||||||
|
assert.equal(button[1], '<span aria-hidden="true">×</span>');
|
||||||
|
assert(button[0].includes('autoFocus') && button[0].includes('onClick={close}'));
|
||||||
|
const styles = read('src/css/custom.css').match(/\.archify-modal-toolbar button \{([^}]+)\}/)[1];
|
||||||
|
assert(styles.includes('width: 44px') && styles.includes('height: 44px'));
|
||||||
|
assert(styles.includes('padding: 0') && styles.includes('flex-shrink: 0'));
|
||||||
|
});
|
||||||
|
test('Product owns two teams and Technology owns five separate teams', () => {
|
||||||
const spec = JSON.parse(read('diagrams/organization-structure.architecture.json'));
|
const spec = JSON.parse(read('diagrams/organization-structure.architecture.json'));
|
||||||
assert(spec.meta.title.includes('Illustrative'));
|
const page = read('docs/organization/structure.mdx');
|
||||||
const ids = new Set(spec.components.map(n => n.id));
|
assert(!/shared-delivery|squad-/i.test(JSON.stringify(spec)));
|
||||||
assert.equal(ids.size, spec.components.length);
|
assert(!/shared squads|share a delivery structure|cross-functional teams/i.test(page));
|
||||||
for (const edge of spec.connections) assert(ids.has(edge.from) && ids.has(edge.to));
|
for (const [dept, count, heading, next] of [['product',2,'Product','Technology'],['technology',5,'Technology','Operations']]) {
|
||||||
assert(read('docs/organization/structure.mdx').includes('not Eldorado’s confirmed organization chart'));
|
const teams = spec.components.filter(n => n.id.startsWith(`${dept}-team-`));
|
||||||
|
assert.equal(teams.length, count);
|
||||||
|
const section = page.split(`### ${heading}\n`)[1].split(`### ${next}\n`)[0];
|
||||||
|
const rows = section.split('\n').filter(l => l.startsWith('| ')).slice(2);
|
||||||
|
assert.equal(rows.length, count);
|
||||||
|
for (const team of teams) {
|
||||||
|
const parents = spec.connections.filter(e => e.to === team.id);
|
||||||
|
assert.deepEqual(parents.map(e => e.from), [dept]);
|
||||||
|
assert(rows.some(row => row.startsWith(`| ${team.label} |`)));
|
||||||
|
}
|
||||||
|
}
|
||||||
|
});
|
||||||
|
test('departments share one row and each has delivery teams below it', () => {
|
||||||
|
const spec = JSON.parse(read('diagrams/organization-structure.architecture.json'));
|
||||||
|
const page = read('docs/organization/structure.mdx');
|
||||||
|
const departments = ['product', 'technology', 'operations', 'marketing', 'finance', 'people'];
|
||||||
|
const nodes = new Map(spec.components.map(n => [n.id, n]));
|
||||||
|
assert.equal(new Set(departments.map(id => nodes.get(id).pos[1])).size, 1);
|
||||||
|
for (const [i, id] of departments.entries()) {
|
||||||
|
const department = nodes.get(id);
|
||||||
|
const teams = spec.connections.filter(e => e.from === id).map(e => nodes.get(e.to));
|
||||||
|
assert.equal(teams.length, i === 0 ? 2 : i === 1 ? 5 : 1);
|
||||||
|
for (const team of teams) {
|
||||||
|
assert(team.pos[1] > department.pos[1] + department.size[1]);
|
||||||
|
assert(team.size[0] < department.size[0]);
|
||||||
|
assert.equal(team.pos[0] + team.size[0], department.pos[0] + department.size[0]);
|
||||||
|
const edge = spec.connections.find(e => e.from === id && e.to === team.id);
|
||||||
|
assert.equal(edge.toSide, 'left');
|
||||||
|
assert.equal(edge.fromSide, 'bottom');
|
||||||
|
assert.equal(spec.connections.find(e => e.from === 'management' && e.to === id).toSide, 'top');
|
||||||
|
assert.deepEqual(spec.connections.filter(e => e.to === team.id).map(e => e.from), [id]);
|
||||||
|
assert(page.includes(team.label));
|
||||||
|
}
|
||||||
|
}
|
||||||
|
for (const [i, a] of spec.components.entries()) for (const b of spec.components.slice(i + 1)) {
|
||||||
|
assert(!(a.pos[0] < b.pos[0] + b.size[0] && a.pos[0] + a.size[0] > b.pos[0] && a.pos[1] < b.pos[1] + b.size[1] && a.pos[1] + a.size[1] > b.pos[1]), `${a.id} overlaps ${b.id}`);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
test('organization content is split into linked focused pages', () => {
|
||||||
|
const structure = read('docs/organization/structure.mdx');
|
||||||
|
const collaboration = read('docs/organization/collaboration.mdx');
|
||||||
|
const sdlc = read('docs/organization/sdlc.mdx');
|
||||||
|
assert(!structure.includes('## How the departments work together'));
|
||||||
|
assert(!structure.includes('## Leadership and delivery structure'));
|
||||||
|
assert(!structure.includes('name="organization-reporting"'));
|
||||||
|
assert(collaboration.includes('## How the departments work together'));
|
||||||
|
for (const outcome of ['Better buyer experience', 'Stronger seller experience', 'Safe and trustworthy trading', 'Sustainable growth', 'AI-powered execution']) assert(collaboration.includes(outcome));
|
||||||
|
assert(sdlc.includes('title: SDLC — Software Delivery Life Cycle'));
|
||||||
|
assert(sdlc.includes('name="organization-reporting"'));
|
||||||
|
for (const role of ['Head of Engineering', 'AI Architect', 'Operational Quality', 'Brand Team Lead']) assert(sdlc.includes(role));
|
||||||
|
for (const [name, page] of [['structure',structure],['collaboration',collaboration],['sdlc',sdlc]]) {
|
||||||
|
for (const other of ['structure','collaboration','sdlc'].filter(n => n !== name)) assert(page.includes(`./${other}.mdx`));
|
||||||
|
}
|
||||||
|
});
|
||||||
|
test('organization page presents an operating model, not research notes', () => {
|
||||||
|
const page = read('docs/organization/structure.mdx');
|
||||||
|
assert(page.includes('operating model') && page.includes('## Departments and teams'));
|
||||||
|
const prohibited = /assum|job.advert|vacanc|publicly evidenced|research snapshot|## Sources|\[\d+\]|\b[EJA]:\s/i;
|
||||||
|
assert(!prohibited.test(page));
|
||||||
|
assert(page.includes('Vladas Jurkevičius') && page.includes('Lukas Deksnys'));
|
||||||
|
assert(existsSync('research/organization/reconstruction-snapshot.mdx'));
|
||||||
|
assert(JSON.parse(read('research/organization/sources.json')).sources.every(s => s.quotes?.length));
|
||||||
|
for (const name of ['organization-structure', 'organization-reporting']) {
|
||||||
|
const spec = JSON.parse(read(`diagrams/${name}.architecture.json`));
|
||||||
|
assert(!prohibited.test(JSON.stringify(spec)));
|
||||||
|
const ids = new Set(spec.components.map(n => n.id));
|
||||||
|
assert.equal(ids.size, spec.components.length);
|
||||||
|
for (const edge of spec.connections) assert(ids.has(edge.from) && ids.has(edge.to));
|
||||||
|
}
|
||||||
});
|
});
|
||||||
@@ -0,0 +1,48 @@
|
|||||||
|
import {test} from 'node:test';
|
||||||
|
import assert from 'node:assert/strict';
|
||||||
|
import {readFileSync} from 'node:fs';
|
||||||
|
const read = p => readFileSync(p, 'utf8');
|
||||||
|
const model = JSON.parse(read('research/ai-adoption/strategy-model.json'));
|
||||||
|
|
||||||
|
test('every strategy page leads with a compact diagram story and closes its references', () => {
|
||||||
|
for (const {id} of model.pages) {
|
||||||
|
const page = read(`docs/strategy/${id}.mdx`);
|
||||||
|
const narrative = page.split('<div className="strategy-content">')[1].replace(/<details>[\s\S]*?<\/details>/g, '');
|
||||||
|
assert.equal((narrative.match(/<ArchifyDiagram /g) || []).length, 1, id);
|
||||||
|
assert(narrative.includes(' story />'), id);
|
||||||
|
assert(page.indexOf(' story />') < page.indexOf('<details>'), id);
|
||||||
|
assert(!/<details\s+open/.test(page), id);
|
||||||
|
assert.equal((page.match(/<details>/g) || []).length, (page.match(/<\/details>/g) || []).length, id);
|
||||||
|
assert.equal((narrative.match(/^## /gm) || []).length, 1, id);
|
||||||
|
assert((narrative.match(/^- /gm) || []).length <= 3, id);
|
||||||
|
assert(narrative.includes('**Next:**'), id);
|
||||||
|
assert(!narrative.includes('| ---'), id);
|
||||||
|
const words = narrative.replace(/<[^>]*>/g, '').trim().split(/\s+/).length;
|
||||||
|
assert(words <= 200, `${id}: ${words} default narrative words`);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
|
test('mobile story diagrams preserve the same nodes and directed relationships', () => {
|
||||||
|
for (const {id} of model.pages) {
|
||||||
|
const page = read(`docs/strategy/${id}.mdx`);
|
||||||
|
const name = /<ArchifyDiagram name="([^"]+)"[^>]+ story/.exec(page)[1];
|
||||||
|
const desktop = JSON.parse(read(`diagrams/${name}.architecture.json`));
|
||||||
|
const mobile = JSON.parse(read(`diagrams/${name}-mobile.architecture.json`));
|
||||||
|
assert(desktop.components.length >= 5 && desktop.components.length <= 7, name);
|
||||||
|
const semantic = d => ({nodes:d.components.map(({pos,size,...n})=>n),edges:d.connections.map(({fromSide,toSide,...e})=>e)});
|
||||||
|
assert.deepEqual(semantic(desktop), semantic(mobile), name);
|
||||||
|
assert(desktop.connections.every(e => e.label && e.from !== e.to), name);
|
||||||
|
assert.equal(desktop.meta.legend.mode, 'hidden');
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
|
test('all sixteen exact KPI formulas remain reachable in the closed reference', () => {
|
||||||
|
const page = read('docs/strategy/measurement.mdx');
|
||||||
|
const contracts = page.split('<summary>All 16 KPI contracts')[1].split('</details>')[0];
|
||||||
|
assert.equal((contracts.match(/^### /gm) || []).length, 16);
|
||||||
|
for (const metric of model.kpis) {
|
||||||
|
const section = contracts.split(`### ${metric.name}\n`)[1]?.split('\n### ')[0];
|
||||||
|
assert(section, metric.name);
|
||||||
|
for (const label of ['Numerator','Denominator','Expression','Aggregation','Unit','Eligible population','Exclusions','Events and source','Owner / cadence','Missing evidence','Gaming and limits']) assert(section.includes(`| ${label} |`), `${metric.name}: ${label}`);
|
||||||
|
}
|
||||||
|
});
|
||||||
@@ -0,0 +1,40 @@
|
|||||||
|
import {test} from 'node:test';
|
||||||
|
import assert from 'node:assert/strict';
|
||||||
|
import {readFileSync, readdirSync} from 'node:fs';
|
||||||
|
const read = p => readFileSync(p, 'utf8');
|
||||||
|
const model = JSON.parse(read('research/ai-adoption/strategy-model.json'));
|
||||||
|
test('eight fixed strategy pages preserve target boundary and separate evidence', () => {
|
||||||
|
assert.equal(model.pages.length, 8);
|
||||||
|
assert.equal(readdirSync('docs/strategy').length, 8);
|
||||||
|
for (const {id} of model.pages) {
|
||||||
|
const page = read(`docs/strategy/${id}.mdx`);
|
||||||
|
assert(page.includes(`id: ${id}`));
|
||||||
|
assert(page.includes('Target operating model'));
|
||||||
|
assert(!/## Sources|\[\d+\]|Internal evidence mapping/.test(page));
|
||||||
|
assert(read('sidebars/strategy.ts').includes(`'${id}'`));
|
||||||
|
}
|
||||||
|
for (const teams of Object.values(model.organization)) for (const name of teams) {
|
||||||
|
assert(read('docs/organization/structure.mdx').includes(name));
|
||||||
|
assert(read('docs/strategy/target-operating-model.mdx').includes(name));
|
||||||
|
}
|
||||||
|
});
|
||||||
|
test('every metric has an actionable reader-facing contract', () => {
|
||||||
|
const page = read('docs/strategy/measurement.mdx');
|
||||||
|
assert.equal(model.kpis.length,16);
|
||||||
|
for (const k of model.kpis) {
|
||||||
|
const section=page.split(`### ${k.name}\n`)[1]?.split('\n### ')[0];
|
||||||
|
assert(section,k.name);
|
||||||
|
for (const field of ['Eligible population','Exclusions','Events and source','Owner / cadence','Missing evidence','Gaming and limits']) assert(section.includes(`| ${field} |`));
|
||||||
|
assert(section.includes(k.owner));
|
||||||
|
}
|
||||||
|
assert(page.includes('synthetic') && page.includes('not a production ingestion system'));
|
||||||
|
});
|
||||||
|
test('diagram preserves independent release approval and no agent production authority', () => {
|
||||||
|
const d=JSON.parse(read('diagrams/ai-adoption-target.architecture.json'));
|
||||||
|
assert(d.meta.title.startsWith('TO-BE'));
|
||||||
|
assert.equal(d.components.filter(n=>n.id==='coordinator').length,1);
|
||||||
|
assert.deepEqual(d.connections.filter(e=>e.to==='release').map(e=>e.from),['approval']);
|
||||||
|
for (const [from,to] of [['registry','coordinator'],['registry','clients'],['clients','gates'],['gates','approval'],['release','audit'],['audit','people']]) assert(d.connections.some(e=>e.from===from&&e.to===to));
|
||||||
|
assert(!d.connections.some(e=>['clients','coordinator'].includes(e.from)&&['release','approval'].includes(e.to)));
|
||||||
|
assert(d.boundaries.some(b=>b.wraps.includes('gates')&&b.wraps.includes('release')));
|
||||||
|
});
|
||||||
+30
-2
@@ -16,12 +16,40 @@ const workflow = read('.gitea/workflows/pages.yml');
|
|||||||
assert(workflow.includes('mountpoint -q'));
|
assert(workflow.includes('mountpoint -q'));
|
||||||
assert(workflow.includes("gitea.event_name == 'push' && gitea.ref == 'refs/heads/main'"));
|
assert(workflow.includes("gitea.event_name == 'push' && gitea.ref == 'refs/heads/main'"));
|
||||||
if (process.argv.includes('--build')) {
|
if (process.argv.includes('--build')) {
|
||||||
for (const route of ['index.html','docs/overview/index.html','docs/maintain/index.html','docs/reference/index.html','404.html','organization/structure/index.html','strategy/index.html','contribution/index.html','contribution/diagrams/index.html','diagrams/organization-structure/index.html']) {
|
const model = JSON.parse(read('research/ai-adoption/strategy-model.json'));
|
||||||
|
const indexes = readdirSync('build').filter(f => /^search-index.*\.json$/.test(f)).map(f => read(join('build',f))).join('\n');
|
||||||
|
for (const {id, title} of model.pages) {
|
||||||
|
const route = `strategy/${id === 'index' ? '' : `${id}/`}index.html`;
|
||||||
|
const page = read(join('build',route));
|
||||||
|
assert(page.includes(title) && page.includes('Target operating model'), route);
|
||||||
|
assert(indexes.includes(title), `Missing indexed Strategy page: ${id}`);
|
||||||
|
for (const match of page.matchAll(/href="(\/eldorado-v1\/documentation\/[^"?#]*)/g)) {
|
||||||
|
const local = decodeURIComponent(match[1].replace('/eldorado-v1/documentation/',''));
|
||||||
|
assert(existsSync(join('build', local.endsWith('/') ? `${local}index.html` : local)), `Broken built link: ${local}`);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
assert(!existsSync('build/research'), 'Background research must remain private source');
|
||||||
|
assert(!readdirSync('build/diagrams', {recursive:true}).some(f => f.endsWith('.json')), 'No public diagram JSON');
|
||||||
|
assert(read('build/diagrams/ai-adoption-target/index.html').includes('TO-BE'));
|
||||||
|
for (const route of ['index.html','docs/overview/index.html','docs/maintain/index.html','docs/reference/index.html','404.html','organization/structure/index.html','organization/collaboration/index.html','organization/sdlc/index.html','strategy/index.html','contribution/index.html','contribution/diagrams/index.html','diagrams/organization-structure/index.html']) {
|
||||||
assert(existsSync(join('build',route)), `Missing route: ${route}`);
|
assert(existsSync(join('build',route)), `Missing route: ${route}`);
|
||||||
}
|
}
|
||||||
assert(!readdirSync('build/diagrams', {recursive: true}).some(f => f.endsWith('.delivery.json')), 'Private build receipts must not be published');
|
assert(!readdirSync('build/diagrams', {recursive: true}).some(f => f.endsWith('.delivery.json')), 'Private build receipts must not be published');
|
||||||
const diagram = read('build/diagrams/organization-structure/index.html');
|
const diagram = read('build/diagrams/organization-structure/index.html');
|
||||||
assert(diagram.includes('Example leadership') && diagram.includes('node-engineering'));
|
assert(diagram.includes('node-product-team-2') && diagram.includes('node-technology-team-5'));
|
||||||
|
assert(!diagram.includes('shared-delivery'));
|
||||||
|
assert(!/A: placement|E: careers|J: advertised/.test(diagram));
|
||||||
|
assert(!diagram.includes('Example leadership'));
|
||||||
|
for (const [dept, count] of [['product', 2], ['technology', 5]]) {
|
||||||
|
for (let i = 1; i <= count; i++) assert(diagram.includes(`node-${dept}-team-${i}`));
|
||||||
|
}
|
||||||
|
const reporting = read('build/diagrams/organization-reporting/index.html');
|
||||||
|
assert(reporting.includes('AI Architect') && reporting.includes('Leads'));
|
||||||
|
assert(!/A: assumed|J: direct/.test(reporting));
|
||||||
|
const structure = read('build/organization/structure/index.html');
|
||||||
|
assert(structure.includes('Vladas Jurkevičius') && structure.includes('operating model'));
|
||||||
|
assert(!/Research snapshot|Job-advertised|careers\.eldorado\.gg|Assumed/.test(structure));
|
||||||
|
assert(!structure.includes('Illustrative integration example'));
|
||||||
assert(!diagram.includes('/opt/data/'), 'No build paths in published diagrams');
|
assert(!diagram.includes('/opt/data/'), 'No build paths in published diagrams');
|
||||||
const home = read('build/index.html');
|
const home = read('build/index.html');
|
||||||
assert(/<title\b[^>]*>Eldorado Powered By AI<\/title>/.test(home));
|
assert(/<title\b[^>]*>Eldorado Powered By AI<\/title>/.test(home));
|
||||||
|
|||||||
@@ -1,2 +1,2 @@
|
|||||||
import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
|
import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
|
||||||
export default {organizationSidebar: ['structure']} satisfies SidebarsConfig;
|
export default {organizationSidebar: ['structure', 'collaboration', 'sdlc']} satisfies SidebarsConfig;
|
||||||
@@ -1,2 +1,2 @@
|
|||||||
import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
|
import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
|
||||||
export default {strategySidebar: ['direction']} satisfies SidebarsConfig;
|
export default {strategySidebar: ['index', 'target-operating-model', 'skills-governance', 'skills-quality', 'skills-adoption', 'measurement', 'skills-maintenance', 'roadmap']} satisfies SidebarsConfig;
|
||||||
@@ -1,12 +1,54 @@
|
|||||||
import React from 'react';
|
import React, {useEffect, useId, useRef, useState} from 'react';
|
||||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||||
|
import {useLocation} from '@docusaurus/router';
|
||||||
|
|
||||||
export default function ArchifyDiagram({name, title}: {name: string; title: string}): React.ReactElement {
|
export default function ArchifyDiagram({name, title, compact = false, story = false}: {name: string; title: string; compact?: boolean; story?: boolean}): React.ReactElement {
|
||||||
if (!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(name)) throw new Error('Invalid diagram name');
|
if (!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(name)) throw new Error('Invalid diagram name');
|
||||||
const source = useBaseUrl(`/diagrams/${name}/`);
|
const source = useBaseUrl(`/diagrams/${name}/`);
|
||||||
const json = useBaseUrl(`/diagrams/${name}.json`);
|
const mobileSource = useBaseUrl(`/diagrams/${name}-mobile/`);
|
||||||
return <section className="archify-panel" aria-label={title}>
|
const dialog = useRef<HTMLDialogElement>(null);
|
||||||
<div className="archify-toolbar"><strong>Interactive diagram</strong><div><a href={source} target="_blank" rel="noopener noreferrer">Open full viewer ↗</a><a href={json} download>JSON source ↓</a></div></div>
|
const opener = useRef<HTMLButtonElement>(null);
|
||||||
<iframe src={source} title={title} sandbox="allow-scripts allow-downloads" loading="lazy" referrerPolicy="no-referrer" />
|
const headingId = useId();
|
||||||
|
const [expanded, setExpanded] = useState(false);
|
||||||
|
const {pathname, hash} = useLocation();
|
||||||
|
useEffect(() => {
|
||||||
|
if (!story || !hash) return;
|
||||||
|
let id: string;
|
||||||
|
try {id = decodeURIComponent(hash.slice(1));} catch {return;}
|
||||||
|
const frame = requestAnimationFrame(() => {
|
||||||
|
const target = document.getElementById(id);
|
||||||
|
if (!target?.closest('.strategy-content')) return;
|
||||||
|
let detail = target.closest('details');
|
||||||
|
if (!detail) return;
|
||||||
|
while (detail) {
|
||||||
|
if (detail.dataset.collapsed === 'true') {
|
||||||
|
detail.querySelector<HTMLElement>(':scope > summary')?.click();
|
||||||
|
} else if (!detail.hasAttribute('data-collapsed')) {
|
||||||
|
detail.open = true;
|
||||||
|
}
|
||||||
|
detail = detail.parentElement?.closest('details') ?? null;
|
||||||
|
}
|
||||||
|
target.scrollIntoView();
|
||||||
|
});
|
||||||
|
return () => cancelAnimationFrame(frame);
|
||||||
|
}, [story, pathname, hash]);
|
||||||
|
useEffect(() => {
|
||||||
|
if (!expanded) return;
|
||||||
|
dialog.current?.showModal();
|
||||||
|
const previousOverflow = document.body.style.overflow;
|
||||||
|
document.body.style.overflow = 'hidden';
|
||||||
|
return () => {document.body.style.overflow = previousOverflow;};
|
||||||
|
}, [expanded]);
|
||||||
|
const close = () => {dialog.current?.close();};
|
||||||
|
return <section className={`archify-panel${compact ? ' archify-panel--compact' : ''}${story ? ' archify-panel--story' : ''}`} data-diagram={name} aria-label={title}>
|
||||||
|
<div className="archify-toolbar"><button ref={opener} type="button" className="archify-expand" aria-label={`Expand ${title}`} title="Expand diagram" onClick={() => setExpanded(true)}><svg width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" aria-hidden="true"><path d="M8 3H3v5M16 3h5v5M21 16v5h-5M8 21H3v-5" /></svg></button></div>
|
||||||
|
{story ? <>
|
||||||
|
<iframe className="story-desktop" src={`${source}?embed=1&theme=light`} title={title} sandbox="allow-scripts" loading="lazy" referrerPolicy="no-referrer" />
|
||||||
|
<iframe className="story-mobile" src={`${mobileSource}?embed=1&theme=light`} title={`${title} — narrow layout`} sandbox="allow-scripts" loading="lazy" referrerPolicy="no-referrer" />
|
||||||
|
</> : <iframe src={source} title={title} sandbox="allow-scripts allow-downloads" loading="lazy" referrerPolicy="no-referrer" />}
|
||||||
|
<dialog ref={dialog} className="archify-modal" aria-labelledby={headingId} onClose={() => {setExpanded(false); opener.current?.focus();}}>
|
||||||
|
<div className="archify-modal-toolbar"><strong id={headingId}>{title}</strong><button type="button" onClick={close} autoFocus aria-label="Close full-screen diagram"><span aria-hidden="true">×</span></button></div>
|
||||||
|
{expanded && <iframe src={source} title={`${title} — expanded`} sandbox="allow-scripts allow-downloads" referrerPolicy="no-referrer" />}
|
||||||
|
</dialog>
|
||||||
</section>;
|
</section>;
|
||||||
}
|
}
|
||||||
+35
-2
@@ -92,13 +92,46 @@
|
|||||||
.footer {background: #101014; color: #afadb9; font-size: .8rem; padding: 27px;}
|
.footer {background: #101014; color: #afadb9; font-size: .8rem; padding: 27px;}
|
||||||
.theme-doc-markdown {max-width: 850px;}
|
.theme-doc-markdown {max-width: 850px;}
|
||||||
.theme-doc-markdown h1 {letter-spacing: -.035em;}
|
.theme-doc-markdown h1 {letter-spacing: -.035em;}
|
||||||
|
.strategy-content table {display: table; width: 100%; table-layout: fixed;}
|
||||||
|
.strategy-content th, .strategy-content td {overflow-wrap: anywhere; vertical-align: top;}
|
||||||
|
.strategy-content th:first-child, .strategy-content td:first-child {width: 25%;}
|
||||||
|
@media (max-width: 700px) {
|
||||||
|
.strategy-content th:first-child, .strategy-content td:first-child {width: 32%;}
|
||||||
|
.strategy-content th, .strategy-content td {padding: .65rem;}
|
||||||
|
}
|
||||||
.pagination-nav__link, .menu__link, .theme-admonition, pre {border-radius: 0;}
|
.pagination-nav__link, .menu__link, .theme-admonition, pre {border-radius: 0;}
|
||||||
a:focus-visible, button:focus-visible {outline: 3px solid #b88719; outline-offset: 4px;}
|
a:focus-visible, button:focus-visible {outline: 3px solid #b88719; outline-offset: 4px;}
|
||||||
@media (max-width: 996px) {.navbar {padding: 0 1rem;} .hero-inner {gap: 15px; padding: 55px 25px;} .hero-art {transform: scale(.85);} .start-section {padding: 35px 25px;} .start-card {padding: 20px;}}
|
@media (max-width: 996px) {.navbar {padding: 0 1rem;} .hero-inner {gap: 15px; padding: 55px 25px;} .hero-art {transform: scale(.85);} .start-section {padding: 35px 25px;} .start-card {padding: 20px;}}
|
||||||
@media (max-width: 700px) {.hero-inner {grid-template-columns: 1fr; padding: 45px 24px;} .hero-art {display: none;} .hero-copy h1 {font-size: 3rem;} .start-grid {grid-template-columns: 1fr;} .section-heading {align-items: flex-start;} .foundation-badge {display: none;} .start-section {padding: 32px 20px;} .navbar__title {font-size: 1.45rem;} .navbar__logo {height: 31px;} .navbar input {max-width: 145px;} .button--lg {font-size: .95rem;} .button--primary span {padding-left: 10px;}}
|
@media (max-width: 700px) {.hero-inner {grid-template-columns: 1fr; padding: 45px 24px;} .hero-art {display: none;} .hero-copy h1 {font-size: 3rem;} .start-grid {grid-template-columns: 1fr;} .section-heading {align-items: flex-start;} .foundation-badge {display: none;} .start-section {padding: 32px 20px;} .navbar__title {font-size: 1.45rem;} .navbar__logo {height: 31px;} .navbar input {max-width: 145px;} .button--lg {font-size: .95rem;} .button--primary span {padding-left: 10px;}}
|
||||||
.archify-panel {border: 1px solid var(--line); margin: 1.5rem 0;}
|
.archify-panel {border: 1px solid var(--line); margin: 1.5rem 0;}
|
||||||
.archify-toolbar {display: flex; justify-content: space-between; flex-wrap: wrap; gap: 12px; padding: 12px 16px; background: var(--surface); font-size: .85rem;}
|
.archify-toolbar {display: flex; justify-content: flex-end; padding: 4px; background: var(--surface);}
|
||||||
.archify-toolbar div {display: flex; gap: 20px; flex-wrap: wrap;}
|
|
||||||
.archify-panel iframe {width: 100%; height: 720px; border: 0; display: block; background: #f6f6f6;}
|
.archify-panel iframe {width: 100%; height: 720px; border: 0; display: block; background: #f6f6f6;}
|
||||||
|
.archify-panel--compact > iframe {height: 500px;}
|
||||||
|
.archify-panel--story {max-width: 740px;}
|
||||||
|
.archify-panel--story > iframe {height: auto; aspect-ratio: 480 / 408;}
|
||||||
|
.archify-panel--story > .story-mobile {display: none;}
|
||||||
|
.archify-panel--story[data-diagram="strategy-target"] > iframe {aspect-ratio: 480 / 628;}
|
||||||
|
.archify-panel--story[data-diagram="strategy-adoption"] > iframe {aspect-ratio: 545 / 408;}
|
||||||
|
.archify-panel--story[data-diagram="strategy-maintenance"] > iframe {aspect-ratio: 524 / 408;}
|
||||||
|
.strategy-content > details {margin: .65rem 0; border: 1px solid var(--line); padding: .8rem 1rem; background: var(--surface);}
|
||||||
|
.strategy-content summary {cursor: pointer; font-weight: 700;}
|
||||||
|
.strategy-content summary:focus-visible {outline: 3px solid #b88719; outline-offset: 4px;}
|
||||||
|
.strategy-content > details[open] > summary {margin-bottom: 1rem;}
|
||||||
@media (max-width: 700px) {.archify-panel iframe {height: 650px;}}
|
@media (max-width: 700px) {.archify-panel iframe {height: 650px;}}
|
||||||
|
@media (max-width: 700px) {
|
||||||
|
.archify-panel--story > .story-desktop {display: none;}
|
||||||
|
.archify-panel--story > .story-mobile {display: block; height: auto; aspect-ratio: 240 / 748;}
|
||||||
|
.archify-panel--story[data-diagram="strategy-roadmap"] > .story-mobile {aspect-ratio: 240 / 628;}
|
||||||
|
.archify-panel--story[data-diagram="strategy-adoption"] > .story-mobile {aspect-ratio: 305 / 748;}
|
||||||
|
.archify-panel--story[data-diagram="strategy-maintenance"] > .story-mobile {aspect-ratio: 284 / 748;}
|
||||||
|
.archify-panel--story[data-diagram="strategy-target"] > .story-mobile {aspect-ratio: 301 / 868;}
|
||||||
|
}
|
||||||
|
.archify-expand {display: grid; place-items: center; width: 44px; height: 44px; border: 0; padding: 0; background: transparent; color: var(--ifm-link-color); cursor: pointer;}
|
||||||
|
.archify-expand:hover {background: var(--ifm-hover-overlay);}
|
||||||
|
.archify-modal {position: fixed; inset: 0; margin: 0; padding: 0; width: 100vw; height: 100dvh; max-width: none; max-height: none; border: 0; background: var(--surface); color: var(--ifm-color-content);}
|
||||||
|
.archify-modal[open] {display: flex; flex-direction: column;}
|
||||||
|
.archify-modal::backdrop {background: #000b;}
|
||||||
|
.archify-modal-toolbar {display: flex; align-items: center; justify-content: space-between; gap: 16px; padding: 12px 20px; border-bottom: 1px solid var(--line);}
|
||||||
|
.archify-modal-toolbar button {display: inline-flex; align-items: center; justify-content: center; flex-shrink: 0; width: 44px; height: 44px; padding: 0; background: var(--gold); color: #14131a; font: inherit; font-size: 24px; font-weight: 700; border: 0; cursor: pointer;}
|
||||||
|
.archify-panel .archify-modal iframe {flex: 1; min-height: 0; height: 100%; width: 100%;}
|
||||||
@media (prefers-reduced-motion: reduce) {.start-card {transition: none;} .start-card:hover {transform: none;}}
|
@media (prefers-reduced-motion: reduce) {.start-card {transition: none;} .start-card:hover {transform: none;}}
|
||||||
@@ -11,7 +11,6 @@ export default function Home(): React.ReactElement {
|
|||||||
<p className="eyebrow">ELDORADO / AI STRATEGY</p>
|
<p className="eyebrow">ELDORADO / AI STRATEGY</p>
|
||||||
<h1>Eldorado<br/><span>Powered By AI</span></h1>
|
<h1>Eldorado<br/><span>Powered By AI</span></h1>
|
||||||
<p className="hero-description">Strategy and direction for an AI-powered Eldorado.</p>
|
<p className="hero-description">Strategy and direction for an AI-powered Eldorado.</p>
|
||||||
<Link className="button button--primary button--lg" to="/docs/overview/">Explore the documentation <span aria-hidden="true">→</span></Link>
|
|
||||||
<p className="hero-note">A starting point for shaping the strategy.</p>
|
<p className="hero-note">A starting point for shaping the strategy.</p>
|
||||||
</div>
|
</div>
|
||||||
<div className="hero-art" aria-hidden="true">
|
<div className="hero-art" aria-hidden="true">
|
||||||
|
|||||||
Reference in new issue
Block a user