{ "answersContract": 1, "generatedFrom": "site/answers.json and site/claims.json", "sourceVisibility": { "repository": "https://github.com/khaoss85/agent-crm", "note": "Evidence paths resolve in the public repository." }, "questions": [ { "slug": "can-an-agent-approve-a-deal-or-discount", "question": "Can a coding agent approve a deal or a discount on my behalf?", "answer": "No. Commercial policy is deterministic code rather than a model's judgement — a renewal at or above the threshold stops and waits for a named human (C-03) — and a test asserts the refusal, so the boundary is a property of the system rather than a promise in a README (C-04). The same refusal holds where the money is: an agent actor calling quote.approve is rejected with status 403 and code HUMAN_APPROVAL_REQUIRED, and only a human user actor can decide (C-21). The scope is exactly this: the actor is asserted, not authenticated in local-development mode — no authentication ships, and there an actor header is not identity (L-01) — so it holds a boundary against an honest agent, not against an attacker with network access, and the threshold policy is proven on the built-in renewal object with a single value threshold.", "claims": [ "C-03", "C-04", "C-21" ], "limitations": [ "L-01" ], "snippet": "No. A discount or a renewal at the threshold stops and waits for a named human. The actor is asserted, not authenticated: no authentication ships.", "url": "https://accordo.dev/answers/can-an-agent-approve-a-deal-or-discount.html", "evidence": [ { "id": "C-03", "text": "Commercial policy is deterministic code, not a model's judgement: a renewal at or above the threshold stops and waits for a named human.", "limitation": "Proven for the built-in renewal object and its single value threshold. A general policy engine over arbitrary custom objects does not exist.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js", "tests/api.test.js" ], "docs": [ "ARCHITECTURE.md", "DECISIONS.md" ] } }, { "id": "C-04", "text": "The agent cannot approve on the human's behalf. A test asserts the refusal, so the boundary is a property of the system rather than a promise in a README.", "limitation": "In local-development mode the actor is asserted, not authenticated: no authentication ships, so an actor header there is not an identity. This holds a boundary against an honest agent, not against an attacker with network access.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js" ], "docs": [ "ARCHITECTURE.md" ], "testName": "approval workflow rejects an agent pretending to make the human decision" } }, { "id": "C-21", "text": "The same refusal holds where the money is: an agent actor asking to approve a discounted quote is refused with a 403, and only a human user actor can decide.", "limitation": "The assertion lives inside a composite end-to-end test rather than a test named for it, so the citation is a file and a line rather than a test name. Extracting it into a named test is tracked in docs/strategy/GO_TO_MARKET.md; until then, cite the line.", "evidence": { "jtbd": "JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ], "testName": "commercial e2e: approval boundary, revise/version-2, concurrency, fault injection, provider failures, drift", "assertion": "tests/commercial-e2e.test.js — quote.approve with actor { type: 'agent' } rejects with status 403 and code HUMAN_APPROVAL_REQUIRED" } }, { "id": "L-01", "text": "Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md", "DECISIONS.md" ], "tests": [ "tests/production-spine.test.js", "tests/actor-fails-closed.test.js" ], "repoFacts": [ "crm app inspect reports a productionPosture that refuses to be read as a readiness claim" ], "facts": [ "spine.authentication.framework_verifier=absent", "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.tenant.crm_data_plane_enforced=enforced_by_binding", "spine.multi_tenant_single_instance=refused_at_startup", "spine.identity.contract=1" ] } } ] }, { "slug": "can-i-run-this-in-production", "question": "Can I deploy this and let my team log into it?", "answer": "A self-hosted deployment is possible, but this is not a ready-to-use hosted CRM. The framework enforces authorization and one tenant per application instance; the deployment supplies authentication. Self-hosted SQLite and dedicated-database PostgreSQL compositions exist, but are not a general production-readiness claim (L-01, L-02). Production mode requires a deployment authentication adapter; the local-development actor header is only an assertion and must not be exposed as authenticated access. The default starter is a local SQLite example (C-22), and there is no public hosted CRM account (L-07). The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08).", "claims": [ "C-22" ], "limitations": [ "L-01", "L-02", "L-07", "L-08" ], "snippet": "Self-hosted SQLite and dedicated PostgreSQL are supported. Supply deployment authentication; local actor headers and passing tests do not establish production readiness.", "facts": [ "spine.postgresql.implemented=implemented", "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.authentication.framework_verifier=absent" ], "url": "https://accordo.dev/answers/can-i-run-this-in-production.html", "evidence": [ { "id": "C-22", "text": "One command composes the whole thing and then inspects it: 76 modules, 9 packages, 71 resources, 64 actions, 7 policies and 1 providers, applied from manifests and driven end to end — then it prints the eleven things the inspector says it cannot see.", "limitation": "It composes the starter's application, not yours, and it runs entirely locally against SQLite with no authentication. The counts describe what that starter applies; a different composition gives different numbers. Wall-clock time varies by machine and is deliberately not claimed.", "evidence": { "tests": [ "tests/app-inspect.test.js", "tests/contracts-activation-e2e.test.js", "tests/delivery-economics-e2e.test.js" ], "docs": [ "docs/APPLICATION_INSPECTION.md" ], "repoFacts": [ "npm run tour runs examples/starters/b2b-lead-qualification/install.mjs, which CI runs on every push, into a directory it keeps", "the counts are the app inspect report of that composed project", "scripts/tour.js exits non-zero if the composed application is ever empty" ], "facts": [ "domain.commercial.package_native=package_native", "domain.contracts.package_native=package_native", "domain.customer_data.package_native=package_native", "domain.delivery.package_native=package_native", "domain.intelligence.package_native=package_native", "domain.lifecycle.package_native=package_native", "domain.service.package_native=package_native", "domain.signature.package_native=package_native", "domain.work.package_native=package_native" ] } }, { "id": "L-01", "text": "Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md", "DECISIONS.md" ], "tests": [ "tests/production-spine.test.js", "tests/actor-fails-closed.test.js" ], "repoFacts": [ "crm app inspect reports a productionPosture that refuses to be read as a readiness claim" ], "facts": [ "spine.authentication.framework_verifier=absent", "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.tenant.crm_data_plane_enforced=enforced_by_binding", "spine.multi_tenant_single_instance=refused_at_startup", "spine.identity.contract=1" ] } }, { "id": "L-02", "text": "createAccordoAppAsync can boot one tenant onto dedicated PostgreSQL databases. Shared-database row-level tenancy is not implemented, and this is not a production-readiness claim.", "limitation": null, "evidence": { "docs": [ "docs/PROJECT_STATUS.md", "docs/strategy/PLATFORM_CAPABILITIES.md" ], "facts": [ "spine.postgresql.implemented=implemented" ] } }, { "id": "L-07", "text": "The framework is not a hosted service: its output is an application in your repository that you run. The managed Cloud is a separate offer: a free workspace on shared capacity configured through a Project Blueprint (record types, fields and approval gates), and a paid Dedicated Cell for custom application code.", "limitation": null, "evidence": { "docs": [ "PRODUCT.md", "docs/strategy/CATEGORY.md" ] } }, { "id": "L-08", "text": "The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08). The framework is copied into the project, not installed as a framework library dependency. The accordo npm name is an empty reservation; the @accordo scope is claimed and deliberately empty.", "limitation": null, "evidence": { "tests": [ "tests/project-bootstrap.test.js" ], "docs": [ "docs/PROJECT_STATUS.md", "docs/plans/project-bootstrap-installability.md" ], "repoFacts": [ "the project bootstrap writes a project from an empty directory, dry-run unless --apply", "tests/create-accordo-package.test.js packs the publication twice, byte-identically, installs it offline and runs the generated project's own checks", "site/brand.json records the registry status and the source status as two separate fields, and scripts/distribution-check.js fails if either disagrees with the tree", "publication is staged from CI through OIDC trusted publishing and goes live only after a human approves the staged version with 2FA" ] } } ] }, { "slug": "can-an-agent-add-a-custom-crm-object", "question": "Can a coding agent add a custom CRM object without me writing page code?", "answer": "For CRUD, yes: a module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens with no page code (C-01), and one field declaration gives a generated object a foreign key, runtime target validation, schema metadata and an Admin selector (C-02). References are generated-to-generated many-to-one only — many-to-many, inverse collections, cascade delete and generated-to-core references do not exist. What is not generated is the interesting half: workflows and approvals for a custom object are still handwritten, and pipeline stages are proven on the built-in Opportunity module, with configurable pipelines for generated custom objects not claimed (C-05). Changing an object later goes through explicit revisions, a checked-in state file and append-only named migrations, but that view is source-only — what a particular database has actually applied is not knowable from it (C-19).", "claims": [ "C-01", "C-02", "C-05", "C-19" ], "limitations": [], "snippet": "For CRUD, yes: a manifest becomes migration, service, REST, SDK and Admin screens with no page code. Not generated: workflows and approvals for that object.", "url": "https://accordo.dev/answers/can-an-agent-add-a-custom-crm-object.html", "evidence": [ { "id": "C-01", "text": "Write a module manifest; the agent turns it into a migration, a service, a REST resource, an SDK method and Admin screens — with no page code.", "limitation": "Generated CRUD only. The factory does not generate workflows or approvals for a custom object — that is still handwritten (JTBD-06, partially supported).", "evidence": { "jtbd": "JTBD-01", "tests": [ "tests/module-factory-e2e.test.js", "tests/generated-api-e2e.test.js", "tests/admin-modules.test.js", "tests/admin-core.test.js" ], "docs": [ "docs/MODULE_FACTORY.md", "docs/ADMIN.md" ] } }, { "id": "C-02", "text": "Generated objects reference each other: a foreign key, runtime target validation, schema metadata and an Admin selector, all from one field declaration.", "limitation": "Generated-to-generated many-to-one only. Many-to-many, inverse collections, cascade delete and generated-to-core references do not exist.", "evidence": { "jtbd": "JTBD-01b", "tests": [ "tests/reference-fields-e2e.test.js", "tests/reference-resolver.test.js", "tests/module-factory.test.js" ], "docs": [ "docs/MODULE_FACTORY.md" ] } }, { "id": "C-05", "text": "Opportunities move through code-first pipeline stages under a server-authoritative action — the client asks, the server decides.", "limitation": "Pipelines are proven on the built-in Opportunity module. Configurable pipelines for generated custom objects are not claimed.", "evidence": { "jtbd": "JTBD-03", "tests": [ "tests/opportunity-pipeline-e2e.test.js", "tests/pipeline-contract.test.js", "tests/admin-pipeline.test.js" ], "docs": [ "docs/ACTIONS.md" ] } }, { "id": "C-19", "text": "Generated modules evolve without rewriting history: explicit revisions, a checked-in state file and append-only named migrations.", "limitation": "The view is source-only: what the checked-in revisions and migrations say is knowable; what a particular database has actually applied is not.", "evidence": { "tests": [ "tests/module-evolution.test.js", "tests/module-evolution-factory.test.js", "tests/module-migrations.test.js" ], "docs": [ "docs/MODULE_EVOLUTION.md" ] } } ] }, { "slug": "what-does-app-inspect-tell-an-agent", "question": "How does a coding agent find out what an application built with this actually contains?", "answer": "One command returns packages, capabilities, resources, actions, policies and providers as a single deterministic JSON report, read from checked-in source (C-14). It is source-only and read-only: it never opens the database, contacts a provider, reads a secret, or reports runtime, CI or authorization state — and it lists those blind spots as machine-readable limitations in its own output. Composing the starter and inspecting it gives 76 modules, 9 packages, 71 resources, 64 actions, 7 policies and 1 providers, then prints the eleven things the inspector says it cannot see (C-22). Those counts describe that starter's composition, not yours, it runs locally against SQLite with no authentication, and wall-clock time is deliberately not claimed.", "claims": [ "C-14", "C-22" ], "limitations": [], "snippet": "One command returns packages, capabilities, resources, actions, policies and providers as deterministic JSON. It never opens the database or reads a secret.", "facts": [ "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.authentication.framework_verifier=absent" ], "url": "https://accordo.dev/answers/what-does-app-inspect-tell-an-agent.html", "evidence": [ { "id": "C-14", "text": "One command tells an agent what an application actually is — packages, capabilities, resources, actions, policies, providers — read from checked-in source, in a single deterministic JSON report.", "limitation": "Source-only and read-only. It never opens the database, contacts a provider, reads a secret, or reports runtime, CI or authorization state — and it lists those blind spots as machine-readable limitations in its own output.", "evidence": { "jtbd": "JTBD-AX-01, JTBD-AX-02", "tests": [ "tests/app-inspect.test.js" ], "docs": [ "docs/APPLICATION_INSPECTION.md", "docs/AGENT_HARNESS_COMPATIBILITY.md" ], "facts": [ "rail.app_inspect.implemented=implemented", "rail.project_doctor.implemented=implemented", "rail.solution_check.implemented=implemented" ] } }, { "id": "C-22", "text": "One command composes the whole thing and then inspects it: 76 modules, 9 packages, 71 resources, 64 actions, 7 policies and 1 providers, applied from manifests and driven end to end — then it prints the eleven things the inspector says it cannot see.", "limitation": "It composes the starter's application, not yours, and it runs entirely locally against SQLite with no authentication. The counts describe what that starter applies; a different composition gives different numbers. Wall-clock time varies by machine and is deliberately not claimed.", "evidence": { "tests": [ "tests/app-inspect.test.js", "tests/contracts-activation-e2e.test.js", "tests/delivery-economics-e2e.test.js" ], "docs": [ "docs/APPLICATION_INSPECTION.md" ], "repoFacts": [ "npm run tour runs examples/starters/b2b-lead-qualification/install.mjs, which CI runs on every push, into a directory it keeps", "the counts are the app inspect report of that composed project", "scripts/tour.js exits non-zero if the composed application is ever empty" ], "facts": [ "domain.commercial.package_native=package_native", "domain.contracts.package_native=package_native", "domain.customer_data.package_native=package_native", "domain.delivery.package_native=package_native", "domain.intelligence.package_native=package_native", "domain.lifecycle.package_native=package_native", "domain.service.package_native=package_native", "domain.signature.package_native=package_native", "domain.work.package_native=package_native" ] } } ] }, { "slug": "can-an-agent-change-my-project-safely", "question": "If I point a coding agent at this, can it overwrite or destroy my project?", "answer": "The MCP server exposes project context and narrow write tools to a coding agent, and anything that generates code or destroys state is dry-run unless you pass an explicit apply flag (C-18) — so you can read the generated output before anything is written. It is stdio only and local only: there is no hosted or authenticated MCP endpoint, and the server inherits the authority of the process that starts it. Planning is separate from execution: a Solution Plan is a checked-in file with a contract and a canonical fingerprint, validated against a real inspection, so a plan written against a composition that has since moved reports itself stale (C-15). That is a document contract, not a planner and not a runtime — nothing executes a plan, and the validator refuses a plan that carries a command.", "claims": [ "C-18", "C-15" ], "limitations": [], "snippet": "Anything that generates code or destroys state is dry-run unless you pass an explicit apply flag. Nothing executes a plan; the MCP server is local stdio only.", "url": "https://accordo.dev/answers/can-an-agent-change-my-project-safely.html", "evidence": [ { "id": "C-18", "text": "The MCP server exposes project context and narrow write tools to a coding agent; anything that generates code or destroys state is dry-run unless you pass an explicit apply flag.", "limitation": "Stdio only, local only. There is no hosted or authenticated MCP endpoint, and the server inherits the local process's authority.", "evidence": { "jtbd": "JTBD-AX-02", "tests": [ "tests/mcp.test.js", "tests/scaffold.test.js" ], "docs": [ "docs/MCP.md" ] } }, { "id": "C-15", "text": "A Solution Plan is a checked-in file with a contract and a canonical fingerprint, validated against a real inspection — so a plan written against a composition that has since moved reports itself stale.", "limitation": "A document contract, not a planner and not a runtime. Nothing executes a plan, and the validator refuses a plan that carries a command.", "evidence": { "jtbd": "JTBD-AX-03", "tests": [ "tests/solution-plan.test.js" ], "docs": [ "docs/SOLUTION_PLAN.md" ], "facts": [ "rail.solution_check.implemented=implemented", "rail.solution_verify.implemented=implemented" ] } } ] }, { "slug": "is-there-a-benchmark-for-agent-built-crms", "question": "Is there a benchmark showing how often a coding agent builds a working CRM with this?", "answer": "No. The build benchmark protocol is designed and published, but it has not been run, so no Successful Agent Build Rate exists and any number quoted for this project is not ours (L-03). One narrower instrument has run: a tool-selection panel asking whether a coding agent picks the right framework command from a plain business goal. Its protocol was frozen and its expected outcomes pre-registered before the first run, its receipts are committed in the repository — including every cell that could not run — and it contains no success rate by design, because one measured arm is a pilot, not a comparison. It measures agent behaviour, not framework capability, and licenses no ranking. What exists beyond that is a test suite that runs on every push, covering happy paths and the policy boundaries that matter — hostile input, transaction rollback, idempotency, concurrency and immutability among them (C-20). A test count measures effort, not correctness, and real-browser tests are run manually and are not in CI.", "claims": [ "C-20" ], "limitations": [ "L-03" ], "snippet": "No. The protocol is published and has never been run, so no success rate exists and any number quoted for this project came from somewhere else.", "url": "https://accordo.dev/answers/is-there-a-benchmark-for-agent-built-crms.html", "evidence": [ { "id": "C-20", "text": "The verification gate runs on every push — source checks and then the whole test suite — covering happy paths and the policy boundaries that matter: hostile input, transaction rollback, idempotency, concurrency and immutability among them.", "limitation": "A test count measures effort, not correctness — read the adversarial-review categories in docs/QUALITY_GATES.md to see what is actually attacked. Real-browser tests are run manually and are not in CI.", "evidence": { "repoFacts": [ "measuredAgainst in this file records the run: npm run verify, green, at the commit named there, with a fingerprint of the tests/ tree it was taken over", ".github/workflows/ci.yml runs verify and smoke on push and pull_request, and runs the public-claims gate over full history so the measurement can be traced" ], "docs": [ "docs/QUALITY_GATES.md" ], "facts": [ "rail.project_verify.implemented=implemented", "rail.scenario_run.implemented=implemented" ] } }, { "id": "L-03", "text": "The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.", "limitation": null, "evidence": { "docs": [ "docs/strategy/CRM_BUILD_BENCHMARK.md", "docs/PROJECT_STATUS.md" ], "facts": [ "benchmark.build_rate.measured=not_measured", "benchmark.tool_selection.comparative=false" ] } } ] }, { "slug": "how-do-i-check-these-claims-myself", "question": "How do I check that these claims are true instead of taking them on trust?", "answer": "Every claim in site/claims.json names the evidence that holds it — a test file, a document, or a named repository fact — and the limitation that travels with it, so each sentence resolves to something you can check. Run the suite — it runs on every push — and read docs/QUALITY_GATES.md for the adversarial-review categories, because the count itself measures effort rather than correctness (C-20). Then run falsify: six rules are removed on purpose in one command and the suite catches every one in about two seconds, naming the test that caught it, and anything that survives is reported as a gap rather than omitted (C-23). Its scope is narrow on purpose — it falsifies six named rules, not the claims in this ledger, it proves only that a test holds each rule, and a rule that is wrong but faithfully defended survives every mutation.", "claims": [ "C-20", "C-23" ], "limitations": [], "snippet": "Every claim names the evidence that holds it and the limitation that travels with it. Falsify removes six rules on purpose; it does not falsify the ledger.", "url": "https://accordo.dev/answers/how-do-i-check-these-claims-myself.html", "evidence": [ { "id": "C-20", "text": "The verification gate runs on every push — source checks and then the whole test suite — covering happy paths and the policy boundaries that matter: hostile input, transaction rollback, idempotency, concurrency and immutability among them.", "limitation": "A test count measures effort, not correctness — read the adversarial-review categories in docs/QUALITY_GATES.md to see what is actually attacked. Real-browser tests are run manually and are not in CI.", "evidence": { "repoFacts": [ "measuredAgainst in this file records the run: npm run verify, green, at the commit named there, with a fingerprint of the tests/ tree it was taken over", ".github/workflows/ci.yml runs verify and smoke on push and pull_request, and runs the public-claims gate over full history so the measurement can be traced" ], "docs": [ "docs/QUALITY_GATES.md" ], "facts": [ "rail.project_verify.implemented=implemented", "rail.scenario_run.implemented=implemented" ] } }, { "id": "C-23", "text": "Five rules can be removed on purpose in one command, and the suite catches every one in about two seconds — naming the test that caught it. Anything that survives is reported as a gap, not omitted.", "limitation": "It falsifies six named rules, not the claims in this ledger, and it proves only that a test holds each one — a rule that is wrong but faithfully defended passes every mutation. It is not mutation testing: nothing is generated or sampled, and no score is derived.", "evidence": { "tests": [ "tests/falsify.test.js", "tests/module-factory.test.js", "tests/workflow.test.js" ], "docs": [ "docs/FALSIFY.md" ], "repoFacts": [ "npm run falsify at 6489982: 5 caught, 0 survived, 0 stale, 2.2s", "npm run falsify --only delivery-cost-rounding: caught by 'cost arithmetic is exact at every boundary' in 108.3s", "the run refuses to start over uncommitted target files and verifies every restore byte-for-byte" ] } } ] }, { "slug": "does-every-change-leave-an-audit-trail", "question": "Does every change leave an audit trail and a trace?", "answer": "Yes. Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it (C-16). That routing is also what makes the approval refusal enforceable rather than advisory: a test asserts that an agent cannot make the human's decision (C-04). What the audit is not: it records what the process did under an asserted actor, so it is not a tamper-evident or externally attestable log and it is not a compliance control — no authentication ships behind the actor it records, so that actor is only as trustworthy as the verifier a deployment supplies (L-01).", "claims": [ "C-16", "C-04" ], "limitations": [ "L-01" ], "snippet": "Yes — every mutation leaves an audit event and a step-level trace. It is not tamper-evident, not externally attestable, and no authentication ships behind it.", "url": "https://accordo.dev/answers/does-every-change-leave-an-audit-trail.html", "evidence": [ { "id": "C-16", "text": "Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.", "limitation": "Audit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js", "tests/action-runtime-semantics.test.js", "tests/event-bus-outbox.test.js" ], "docs": [ "ARCHITECTURE.md", "docs/ACTIONS.md" ] } }, { "id": "C-04", "text": "The agent cannot approve on the human's behalf. A test asserts the refusal, so the boundary is a property of the system rather than a promise in a README.", "limitation": "In local-development mode the actor is asserted, not authenticated: no authentication ships, so an actor header there is not an identity. This holds a boundary against an honest agent, not against an attacker with network access.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js" ], "docs": [ "ARCHITECTURE.md" ], "testName": "approval workflow rejects an agent pretending to make the human decision" } }, { "id": "L-01", "text": "Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md", "DECISIONS.md" ], "tests": [ "tests/production-spine.test.js", "tests/actor-fails-closed.test.js" ], "repoFacts": [ "crm app inspect reports a productionPosture that refuses to be read as a readiness claim" ], "facts": [ "spine.authentication.framework_verifier=absent", "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.tenant.crm_data_plane_enforced=enforced_by_binding", "spine.multi_tenant_single_instance=refused_at_startup", "spine.identity.contract=1" ] } } ] }, { "slug": "can-i-put-real-customer-data-in-it", "question": "Can I put real customer data in it?", "answer": "Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data (L-09). Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06). The framework enforces authorization and one tenant per application instance; the deployment supplies authentication. Self-hosted SQLite and dedicated-database PostgreSQL compositions exist, but are not a general production-readiness claim (L-01, L-02). Deterministic lead scores retain their version fingerprint and explanation (C-07).", "claims": [ "C-07" ], "limitations": [ "L-09", "L-06", "L-01" ], "snippet": "Bounded import and identity governance exist. Deployment authentication and complete subject export/erasure remain your responsibility; compliance is not claimed.", "facts": [ "spine.postgresql.implemented=implemented", "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.authentication.framework_verifier=absent", "domain.customer_data.package_native=package_native", "cdf.full_cdp.implemented=absent", "customer_timeline.complete=absent" ], "url": "https://accordo.dev/answers/can-i-put-real-customer-data-in-it.html", "evidence": [ { "id": "C-07", "text": "Scoring is explainable and versioned: every score carries the fingerprint of the model version that produced it, so a number from last quarter can still be accounted for.", "limitation": "Deterministic weighted rules, not a machine-learning model. Nothing trains, fits or backtests.", "evidence": { "jtbd": "JTBD-LI-02, JTBD-LI-07", "tests": [ "tests/lead-intelligence-e2e.test.js", "tests/intelligence-contract.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "L-09", "text": "Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "tests": [ "tests/lead-intelligence-e2e.test.js", "tests/customer-data-foundation.test.js" ], "docs": [ "docs/strategy/DATA_GOVERNANCE.md", "docs/benchmarks/CRM_JTBD_MATRIX.md" ], "repoFacts": [ "Customer Data Foundation records bounded imports and human-governed logical canonical identity without deleting or rewriting source records", "Complete subject export and erasure are not supplied by Customer Data Foundation", "scoring is a deterministic weighted model with a persisted version fingerprint (C-07)" ], "facts": [ "spine.authentication.framework_verifier=absent", "cdf.full_cdp.implemented=absent", "customer_timeline.complete=absent" ] } }, { "id": "L-06", "text": "Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search.", "limitation": null, "evidence": { "docs": [ "docs/benchmarks/CRM_JTBD_MATRIX.md" ], "tests": [ "tests/customer-data-foundation.test.js" ], "facts": [ "domain.customer_data.package_native=package_native", "cdf.full_cdp.implemented=absent" ] } }, { "id": "L-01", "text": "Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md", "DECISIONS.md" ], "tests": [ "tests/production-spine.test.js", "tests/actor-fails-closed.test.js" ], "repoFacts": [ "crm app inspect reports a productionPosture that refuses to be read as a readiness claim" ], "facts": [ "spine.authentication.framework_verifier=absent", "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.tenant.crm_data_plane_enforced=enforced_by_binding", "spine.multi_tenant_single_instance=refused_at_startup", "spine.identity.contract=1" ] } } ] }, { "slug": "how-does-quoting-and-discount-approval-work", "question": "How does it price quotes and handle discount approval?", "answer": "Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval (C-08). The approval is human by policy: an agent actor asking to approve a discounted quote is refused with status 403 and code HUMAN_APPROVAL_REQUIRED, and only a human user actor can decide (C-21). Two boundaries travel with it: catalog sync runs against a fixture provider with no real external catalog (Stripe, Zuora, ERP) connected, and money is integer cents with no FX — currencies are never summed. The refusal assertion also lives inside a composite end-to-end test rather than a test named for it, so it is cited by file and line rather than by test name.", "claims": [ "C-08", "C-21" ], "limitations": [], "snippet": "Quotes price on the server and freeze into an immutable version when a discount goes for approval, which only a human can give. The catalog is a fixture.", "url": "https://accordo.dev/answers/how-does-quoting-and-discount-approval-work.html", "evidence": [ { "id": "C-08", "text": "Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval.", "limitation": "Catalog sync runs against a fixture provider; no real external catalog (Stripe, Zuora, ERP) is connected. Money is integer cents with no FX — currencies are never summed.", "evidence": { "jtbd": "JTBD-CO-01, JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js", "tests/commercial-contract.test.js", "tests/admin-quotes.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ] } }, { "id": "C-21", "text": "The same refusal holds where the money is: an agent actor asking to approve a discounted quote is refused with a 403, and only a human user actor can decide.", "limitation": "The assertion lives inside a composite end-to-end test rather than a test named for it, so the citation is a file and a line rather than a test name. Extracting it into a named test is tracked in docs/strategy/GO_TO_MARKET.md; until then, cite the line.", "evidence": { "jtbd": "JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ], "testName": "commercial e2e: approval boundary, revise/version-2, concurrency, fault injection, provider failures, drift", "assertion": "tests/commercial-e2e.test.js — quote.approve with actor { type: 'agent' } rejects with status 403 and code HUMAN_APPROVAL_REQUIRED" } } ] }, { "slug": "what-integrations-exist", "question": "Which external services does it integrate with?", "answer": "None. Every provider is an offline fixture: enrichment runs against a fixture provider with no real external data source wired (C-06), catalog sync against a fixture provider with no Stripe, Zuora or ERP connected (C-08), and signature against a fixture provider with a test-only webhook key, where the artifact hash is provider-reported rather than independently recomputed (C-09). No DocuSign, Adobe Sign or Dropbox Sign adapter exists. There is no email, calendar or marketing integration either — an in-memory notification provider contract exists, and no adapter sends anything to anyone (L-05).", "claims": [ "C-06", "C-08", "C-09" ], "limitations": [ "L-05" ], "snippet": "None. Every provider — enrichment, catalog, signature, notification — is an offline fixture. No DocuSign, Stripe, Zuora, ERP, email or calendar adapter exists.", "url": "https://accordo.dev/answers/what-integrations-exist.html", "evidence": [ { "id": "C-06", "text": "A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.", "limitation": "Enrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.", "evidence": { "jtbd": "JTBD-04, JTBD-05, JTBD-05b, JTBD-LI-01, JTBD-LI-02, JTBD-LI-04", "tests": [ "tests/lead-qualification-e2e.test.js", "tests/lead-conversion-e2e.test.js", "tests/lead-intelligence-e2e.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "C-08", "text": "Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval.", "limitation": "Catalog sync runs against a fixture provider; no real external catalog (Stripe, Zuora, ERP) is connected. Money is integer cents with no FX — currencies are never summed.", "evidence": { "jtbd": "JTBD-CO-01, JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js", "tests/commercial-contract.test.js", "tests/admin-quotes.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ] } }, { "id": "C-09", "text": "A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.", "limitation": "A fixture signature provider with a test-only webhook key. No DocuSign, Adobe Sign or Dropbox Sign adapter exists, and the artifact hash is provider-reported rather than independently recomputed.", "evidence": { "jtbd": "JTBD-CO-07", "tests": [ "tests/signature-order-e2e.test.js", "tests/signature-contract.test.js", "tests/admin-signature.test.js" ], "docs": [ "docs/SIGNATURE_ORDER.md" ] } }, { "id": "L-05", "text": "An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.", "limitation": null, "evidence": { "jtbd": "JTBD-14", "docs": [ "docs/strategy/INTEGRATION_RUNTIME.md" ], "facts": [ "marketing_runtime.implemented=implemented" ], "tests": [ "tests/marketing-no-external-effect.test.js", "tests/marketing-e2e.test.js" ] } } ] }, { "slug": "what-happens-after-the-order-is-signed", "question": "Does it cover what happens after a deal is signed?", "answer": "Partly: verified signature evidence produces an immutable Order (C-09), activation creates a Contract, immutable version, Subscription and pending obligations (C-10), and delivery adds projects, work packages, milestones and append-only cost evidence (C-11, C-12). Terms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification. Deliverables and recorded customer acceptance exist; acceptance is evidence recorded by a user actor, not an authenticated customer signature or permission to bill. Contribution estimates exclude recurring commercial inputs and are not revenue recognition or margin.", "claims": [ "C-09", "C-10", "C-11", "C-12" ], "limitations": [], "snippet": "Order, contract, subscription, delivery and governed successor agreements are supported. No automatic renewal, cancellation execution, billing or notification.", "facts": [ "domain.lifecycle.package_native=package_native" ], "url": "https://accordo.dev/answers/what-happens-after-the-order-is-signed.html", "evidence": [ { "id": "C-09", "text": "A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.", "limitation": "A fixture signature provider with a test-only webhook key. No DocuSign, Adobe Sign or Dropbox Sign adapter exists, and the artifact hash is provider-reported rather than independently recomputed.", "evidence": { "jtbd": "JTBD-CO-07", "tests": [ "tests/signature-order-e2e.test.js", "tests/signature-contract.test.js", "tests/admin-signature.test.js" ], "docs": [ "docs/SIGNATURE_ORDER.md" ] } }, { "id": "C-10", "text": "A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed.", "limitation": "Terms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification.", "evidence": { "jtbd": "JTBD-CS-01, JTBD-CS-02", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/contracts-contract.test.js", "tests/admin-contracts.test.js", "tests/lifecycle-amendment-execution-e2e.test.js", "tests/lifecycle-amendment-execution.test.js", "tests/signed-terms-e2e.test.js" ], "docs": [ "docs/CONTRACT_ACTIVATION.md", "docs/RENEWAL_AMENDMENT.md" ], "facts": [ "domain.lifecycle.package_native=package_native" ] } }, { "id": "C-11", "text": "Pending obligations hand over into a Delivery Project with work packages, milestones and an optional partner — atomically, idempotently, and across a package boundary the kernel never learns about.", "limitation": "It hands work over and runs it through human-driven transitions. Nothing schedules, staffs, computes percent complete or bills. Deliverables and recorded customer acceptance exist as of M14b2, and acceptance there is evidence a user actor recorded — never an authenticated customer, a legal signature or authorization to bill.", "evidence": { "jtbd": "JTBD-DS-01", "tests": [ "tests/delivery-handover-e2e.test.js", "tests/delivery-execution-e2e.test.js", "tests/admin-delivery.test.js" ], "docs": [ "docs/DELIVERY_HANDOVER.md" ] } }, { "id": "C-12", "text": "Delivery records what it consumed: append-only time and expense evidence, costed server-side by a versioned fingerprinted policy, with a reproducible contribution estimate grouped by currency.", "limitation": "Deliberately not a margin: no revenue recognition, no cost of goods sold, no ARR/MRR/TCV, no annualization, no FX. A project carrying a recurring obligation returns no estimate at all and says why.", "evidence": { "jtbd": "JTBD-DS-06, JTBD-DS-07", "tests": [ "tests/delivery-economics-e2e.test.js" ], "docs": [ "docs/DELIVERY_ECONOMICS.md" ] } } ] }, { "slug": "does-it-run-scheduled-work-or-reminders", "question": "Does it send renewal reminders or run anything on a schedule?", "answer": "Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04). Supported timers can open Work, approval, lifecycle-review and service-SLA asks when composed; they do not automatically renew a contract, approve a decision or deliver a notification. Contract autoRenew and notice metadata alone starts nothing (C-10); no email/calendar adapter ships (L-05).", "claims": [ "C-10", "C-06" ], "limitations": [ "L-04", "L-05" ], "snippet": "Scheduled asks run through an explicitly started self-host worker. A timer opens an ask, never decides it; no managed service, recurrence or delivered reminder is included.", "facts": [ "spine.durable_job_store.implemented=implemented", "spine.transactional_outbox.implemented=implemented", "spine.timer_consumers.implemented=implemented", "spine.managed_jobs_service.implemented=absent" ], "url": "https://accordo.dev/answers/does-it-run-scheduled-work-or-reminders.html", "evidence": [ { "id": "C-10", "text": "A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed.", "limitation": "Terms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification.", "evidence": { "jtbd": "JTBD-CS-01, JTBD-CS-02", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/contracts-contract.test.js", "tests/admin-contracts.test.js", "tests/lifecycle-amendment-execution-e2e.test.js", "tests/lifecycle-amendment-execution.test.js", "tests/signed-terms-e2e.test.js" ], "docs": [ "docs/CONTRACT_ACTIVATION.md", "docs/RENEWAL_AMENDMENT.md" ], "facts": [ "domain.lifecycle.package_native=package_native" ] } }, { "id": "C-06", "text": "A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.", "limitation": "Enrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.", "evidence": { "jtbd": "JTBD-04, JTBD-05, JTBD-05b, JTBD-LI-01, JTBD-LI-02, JTBD-LI-04", "tests": [ "tests/lead-qualification-e2e.test.js", "tests/lead-conversion-e2e.test.js", "tests/lead-intelligence-e2e.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "L-04", "text": "Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.", "limitation": null, "evidence": { "jtbd": "JTBD-07, JTBD-10", "docs": [ "docs/strategy/JOBS_AND_OUTBOX.md" ], "facts": [ "spine.timer_consumers.implemented=implemented", "spine.managed_jobs_service.implemented=absent", "spine.durable_job_store.implemented=implemented", "spine.transactional_outbox.implemented=implemented" ] } }, { "id": "L-05", "text": "An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.", "limitation": null, "evidence": { "jtbd": "JTBD-14", "docs": [ "docs/strategy/INTEGRATION_RUNTIME.md" ], "facts": [ "marketing_runtime.implemented=implemented" ], "tests": [ "tests/marketing-no-external-effect.test.js", "tests/marketing-e2e.test.js" ] } } ] }, { "slug": "how-to-pair-a-cdp-with-a-crm-framework", "question": "How should I pair a customer data platform with this CRM framework?", "answer": "Use a CDP for broad ingestion, identity graphs, audiences and activation, and Accordo for owned CRM process code with named actions, policy, audit and trace (C-06, C-07, C-16). Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06). Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04). No prebuilt CDP connector ships (L-05); bridge mapping remains application code. Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data (L-09).", "claims": [ "C-06", "C-07", "C-16" ], "limitations": [ "L-01", "L-05", "L-06", "L-09", "L-04" ], "snippet": "Accordo adds bounded customer imports and logical identity to owned CRM process code. It is not a full CDP; connector mapping and personal-data operations remain deployment work.", "facts": [ "spine.durable_job_store.implemented=implemented", "spine.transactional_outbox.implemented=implemented", "spine.timer_consumers.implemented=implemented", "spine.managed_jobs_service.implemented=absent", "domain.customer_data.package_native=package_native", "cdf.full_cdp.implemented=absent", "customer_timeline.complete=absent" ], "url": "https://accordo.dev/answers/how-to-pair-a-cdp-with-a-crm-framework.html", "evidence": [ { "id": "C-06", "text": "A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.", "limitation": "Enrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.", "evidence": { "jtbd": "JTBD-04, JTBD-05, JTBD-05b, JTBD-LI-01, JTBD-LI-02, JTBD-LI-04", "tests": [ "tests/lead-qualification-e2e.test.js", "tests/lead-conversion-e2e.test.js", "tests/lead-intelligence-e2e.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "C-07", "text": "Scoring is explainable and versioned: every score carries the fingerprint of the model version that produced it, so a number from last quarter can still be accounted for.", "limitation": "Deterministic weighted rules, not a machine-learning model. Nothing trains, fits or backtests.", "evidence": { "jtbd": "JTBD-LI-02, JTBD-LI-07", "tests": [ "tests/lead-intelligence-e2e.test.js", "tests/intelligence-contract.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "C-16", "text": "Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.", "limitation": "Audit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js", "tests/action-runtime-semantics.test.js", "tests/event-bus-outbox.test.js" ], "docs": [ "ARCHITECTURE.md", "docs/ACTIONS.md" ] } }, { "id": "L-01", "text": "Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md", "DECISIONS.md" ], "tests": [ "tests/production-spine.test.js", "tests/actor-fails-closed.test.js" ], "repoFacts": [ "crm app inspect reports a productionPosture that refuses to be read as a readiness claim" ], "facts": [ "spine.authentication.framework_verifier=absent", "spine.authorization.enforced=enforced", "spine.tenant.isolation.mode=one_tenant_per_instance", "spine.tenant.crm_data_plane_enforced=enforced_by_binding", "spine.multi_tenant_single_instance=refused_at_startup", "spine.identity.contract=1" ] } }, { "id": "L-05", "text": "An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.", "limitation": null, "evidence": { "jtbd": "JTBD-14", "docs": [ "docs/strategy/INTEGRATION_RUNTIME.md" ], "facts": [ "marketing_runtime.implemented=implemented" ], "tests": [ "tests/marketing-no-external-effect.test.js", "tests/marketing-e2e.test.js" ] } }, { "id": "L-06", "text": "Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search.", "limitation": null, "evidence": { "docs": [ "docs/benchmarks/CRM_JTBD_MATRIX.md" ], "tests": [ "tests/customer-data-foundation.test.js" ], "facts": [ "domain.customer_data.package_native=package_native", "cdf.full_cdp.implemented=absent" ] } }, { "id": "L-09", "text": "Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "tests": [ "tests/lead-intelligence-e2e.test.js", "tests/customer-data-foundation.test.js" ], "docs": [ "docs/strategy/DATA_GOVERNANCE.md", "docs/benchmarks/CRM_JTBD_MATRIX.md" ], "repoFacts": [ "Customer Data Foundation records bounded imports and human-governed logical canonical identity without deleting or rewriting source records", "Complete subject export and erasure are not supplied by Customer Data Foundation", "scoring is a deterministic weighted model with a persisted version fingerprint (C-07)" ], "facts": [ "spine.authentication.framework_verifier=absent", "cdf.full_cdp.implemented=absent", "customer_timeline.complete=absent" ] } }, { "id": "L-04", "text": "Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.", "limitation": null, "evidence": { "jtbd": "JTBD-07, JTBD-10", "docs": [ "docs/strategy/JOBS_AND_OUTBOX.md" ], "facts": [ "spine.timer_consumers.implemented=implemented", "spine.managed_jobs_service.implemented=absent", "spine.durable_job_store.implemented=implemented", "spine.transactional_outbox.implemented=implemented" ] } } ] }, { "slug": "what-do-i-own-and-how-do-i-install-it", "question": "What do I actually own, and how do I install it?", "answer": "The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08). You own the source, and you get it by scaffolding: `npm create accordo` — the published `create-accordo@0.1.0` — scaffolds a project that boots, inspects and passes the project doctor, and it does so by copying the framework source into your repository; the same bootstrap also runs from a checkout. What does not exist is a framework dependency: the framework is vendored into the project, so upgrading means merging, not bumping a version (L-08). What you are left with is a Node application — Node 22 and a checkout, no build step, no bundler; SQLite is Node's built-in adapter, and PostgreSQL requires the one pinned driver pg@8.23.0 (C-17) — though that property belongs to the framework, not to whatever you add on top of it. A domain package you author attaches and detaches with the kernel's fingerprint unchanged and reaches another package only through a declared capability (C-13), and the scaffold that starts one writes an empty package and nothing else — no business logic, no composition, no global identity-uniqueness check — but there is no registry, marketplace, publication or sandboxing, package code runs with the host process's authority, and detaching leaves its data behind. The framework is source you run; the managed Cloud offers a free Blueprint-configured workspace and runs custom code only on a paid Dedicated Cell (L-07).", "claims": [ "C-17", "C-13" ], "limitations": [ "L-08", "L-07" ], "snippet": "You own vendored source, not a framework dependency. The published local starter predates current PostgreSQL and operations; use the source path for those.", "facts": [ "spine.postgresql.implemented=implemented" ], "url": "https://accordo.dev/answers/what-do-i-own-and-how-do-i-install-it.html", "evidence": [ { "id": "C-17", "text": "SQLite is Node's built-in node:sqlite. PostgreSQL requires one pinned runtime driver, pg@8.23.0. There is no ORM, no query builder, no build step and no framework underneath your framework.", "limitation": "Applications that select PostgreSQL carry pg@8.23.0. The SQLite path still needs no third-party driver. This is not a production-readiness claim and not shared-database tenancy; composition is dedicated-database, not row tenancy.", "evidence": { "repoFacts": [ "package.json.dependencies is exactly { pg: \"8.23.0\" }", "SQLite via node:sqlite", "the HTTP server and test runner are Node built-ins", "PostgreSQL uses the pinned pg@8.23.0 driver; there is no ORM" ], "tests": [ "tests/spine-v2-m3b-postgresql-adapter.test.js", "tests/api.test.js" ], "docs": [ "ARCHITECTURE.md", "AGENTS.md" ] } }, { "id": "C-13", "text": "A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares.", "limitation": "The scaffold that starts one writes an empty package and nothing else: no business logic, no composition, no global identity-uniqueness check. There is no registry, no marketplace, no publication and no sandboxing — package code runs with the host process's authority. Detaching leaves its data behind; there is no uninstall.", "evidence": { "jtbd": "JTBD-PK-01, JTBD-PK-02", "tests": [ "tests/package-contract.test.js", "tests/custom-package-e2e.test.js", "tests/contracts-registry-review.test.js" ], "docs": [ "docs/PACKAGE_AUTHORING.md" ], "facts": [ "domain.commercial.package_native=package_native", "domain.contracts.package_native=package_native", "domain.customer_data.package_native=package_native", "domain.delivery.package_native=package_native", "domain.intelligence.package_native=package_native", "domain.lifecycle.package_native=package_native", "domain.service.package_native=package_native", "domain.signature.package_native=package_native", "domain.work.package_native=package_native" ] } }, { "id": "L-08", "text": "The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08). The framework is copied into the project, not installed as a framework library dependency. The accordo npm name is an empty reservation; the @accordo scope is claimed and deliberately empty.", "limitation": null, "evidence": { "tests": [ "tests/project-bootstrap.test.js" ], "docs": [ "docs/PROJECT_STATUS.md", "docs/plans/project-bootstrap-installability.md" ], "repoFacts": [ "the project bootstrap writes a project from an empty directory, dry-run unless --apply", "tests/create-accordo-package.test.js packs the publication twice, byte-identically, installs it offline and runs the generated project's own checks", "site/brand.json records the registry status and the source status as two separate fields, and scripts/distribution-check.js fails if either disagrees with the tree", "publication is staged from CI through OIDC trusted publishing and goes live only after a human approves the staged version with 2FA" ] } }, { "id": "L-07", "text": "The framework is not a hosted service: its output is an application in your repository that you run. The managed Cloud is a separate offer: a free workspace on shared capacity configured through a Project Blueprint (record types, fields and approval gates), and a paid Dedicated Cell for custom application code.", "limitation": null, "evidence": { "docs": [ "PRODUCT.md", "docs/strategy/CATEGORY.md" ] } } ] } ], "refused": [ { "question": "When will a generally production-ready hosted Accordo service be available?", "why": "Authorization, per-instance tenancy and dedicated-database PostgreSQL already exist. These bounded framework capabilities establish no date or commitment for a hosted service or general production readiness." }, { "question": "What is the Successful Agent Build Rate — how often does a coding agent finish a working CRM with this?", "why": "L-03 states the benchmark has not been run and that any number quoted is not ours. A page shaped around the number would exist only to host a figure that does not exist. The accepted page 'is-there-a-benchmark-for-agent-built-crms' answers the meta-question honestly; this one cannot be answered at all." }, { "question": "How does this compare to Salesforce, HubSpot, Twenty, Odoo or a low-code CRM platform?", "why": "No claim or limitation makes any statement about another product. A comparison needs verified, dated competitor facts, and I have no internet access to establish them; docs/strategy/COMPETITOR_MAP.md exists but is strategy, not ledger evidence, so nothing in claims.json licenses a comparison sentence." }, { "question": "How long does it take an agent to build a CRM with this, and how fast is the framework?", "why": "L-02 describes bounded SQLite and dedicated PostgreSQL support, not a throughput or volume commitment. No public load-test result supports a capacity promise." }, { "question": "How well does it scale — how many records, what throughput, what response times?", "why": "SQLite and dedicated PostgreSQL support establish no public throughput, volume or response-time commitment. No public load-test result supports a capacity promise." }, { "question": "Is it secure? Has it had a security review or penetration test?", "why": "The ledger records the absence of authentication (L-01) and states that audit is not tamper-evident and not a compliance control (C-16), but it makes no positive security claim and cites no review. A page titled 'is it secure' would invite an affirmative sentence that no C-xx supports." }, { "question": "Is it SOC 2 / GDPR / HIPAA compliant, and how do I service a DSAR?", "why": "L-09 says data governance is designed and unimplemented and that a data-subject access or deletion request cannot be serviced. There is no compliance programme, certification or control mapping in the ledger, so a compliance-shaped page would imply a process that does not exist. The honest fragment already lives in 'can-i-put-real-customer-data-in-it'." }, { "question": "How do I connect it to DocuSign, Stripe, HubSpot or my email provider?", "why": "A how-to page requires steps. C-09 and C-08 state those adapters do not exist and L-05 states no adapter sends anything to anyone, so every step would be fabricated. The negative version — 'what-integrations-exist' — is accepted instead." }, { "question": "How do I import or migrate my existing CRM data into it?", "why": "L-06 records that import, export, dedupe, merge and bulk edit do not exist. There is no path to document, and a migration guide is the single most damaging thing to invent for a system that has no export either." }, { "question": "Does it have reporting, dashboards, forecasting or pipeline analytics?", "why": "No claim or limitation covers reporting or aggregation. The sentence 'reporting or aggregation over generated modules' is absent appears in site/assets/llms.txt prose, not in claims.json, so under the rule that a public sentence comes only from the ledger there is nothing to answer with. Worth adding as an L-xx if this question recurs." }, { "question": "Which coding agent works best with it — Claude Code or Codex? Which model should I use?", "why": "Nothing in the ledger compares harnesses or models, and the benchmark that would measure it has not been run (L-03). Any preference stated would be a guess presented as a measurement." }, { "question": "What does it cost, what licence does it ship under, and is there a free tier?", "why": "L-07 establishes what is hosted and what is not, but licence status is not a ledger entry — README.md says 'MIT today' with a final confirmation gated on an explicit human decision, which is precisely the kind of sentence that must not be frozen into a retrievable page ahead of that decision." }, { "question": "Who uses this in production, how many teams have adopted it, how many stars or downloads?", "why": "No adoption, usage or popularity fact exists anywhere in claims.json, and L-08 records that nothing is published, so there are no download numbers to have." }, { "question": "Can I give a coding agent a business goal and have it build the whole CRM unattended?", "why": "C-01 is scoped to generated CRUD with workflows and approvals still handwritten, and C-15 states explicitly that nothing executes a plan. An unattended end-to-end build is the exact capability the unrun benchmark (L-03) was designed to measure, so claiming it would be claiming the benchmark result." }, { "question": "Does an LLM decide anything at runtime — is this an 'AI CRM'?", "why": "Tempting, and half-answerable: C-03 says commercial policy is deterministic code rather than a model's judgement and C-07 says scoring is deterministic weighted rules rather than machine learning. But no claim or limitation states that nothing calls a model at request time anywhere in the runtime — that sentence lives in PRODUCT.md, llms.txt and OBJECTIONS.md, not in the ledger — so a page under this question would answer wider than its evidence. It becomes proposable the moment a C-xx covers the runtime as a whole." } ] }