Inmon (1992)
Inmon, W. H. (1992). Building the Data Warehouse. New York: John Wiley & Sons.
Origin of the corporate data-warehouse concept and the case for a single subject-oriented integrated data store.
Read sourceResearch & references
Every claim on the marketing site that needs evidence — the data-architecture argument, the AI-governance posture, the algebraic accounting backing Financial Ops, the expense-fraud and ERP-failure statistics — is anchored to a verifiable source. This page is the bibliography.
Data architecture
The Single Data Backbone is Weaver's answer to a thirty-year academic conversation about how to give business applications a single, consistent, real-time view of their data — without the integration tax. The references below trace that argument from Inmon's 1992 corporate-warehouse manifesto through the 2021 lakehouse paper from the Databricks team.
Inmon, W. H. (1992). Building the Data Warehouse. New York: John Wiley & Sons.
Origin of the corporate data-warehouse concept and the case for a single subject-oriented integrated data store.
Read sourceKimball, R. & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley.
Canonical reference on dimensional modeling and the case against silos of analytical data.
Read sourceArmbrust, M., Ghodsi, A., Xin, R., & Zaharia, M. (2021). Lakehouse: A new generation of open platforms that unify data warehousing and advanced analytics. In Proceedings of the 11th Conference on Innovative Data Systems Research (CIDR '21).
The Databricks "lakehouse" paper — the architectural argument for unifying warehouse and lake into one platform that supports both analytics and applications.
Read sourceHalevy, A., Rajaraman, A., & Ordille, J. (2006). Data integration: The teenage years. In Proceedings of the 32nd VLDB Conference, 9–16.
Survey of why enterprise data integration is structurally hard and why "every new application means another integration project."
Read sourceStonebraker, M. & Hellerstein, J. M. (2005). What goes around comes around. In Readings in Database Systems (4th ed.), MIT Press.
Historical/critical overview of how database architectures cycle, useful when arguing against fragmented stacks.
Read sourceStonebraker, M. (2010). SQL databases v. NoSQL databases. Communications of the ACM, 53(4), 10–11.
On ACID, consistency, and the cost of giving them up — supports the SDB ACID claim.
Read sourceAI governance
Every AI claim on Weaver — agentic marketing in Growth Engine, AI policy enforcement in QuickExpense, AI insights in ERP — is paired with an explicit human-control posture. That posture is grounded in the NIST AI Risk Management Framework, the OECD AI Principles, the EU AI Act, and the academic literature on responsible ML in production.
National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
US voluntary standard for managing AI risk — anchors the "AI with human control" claim with a recognised governance framework.
Read sourceOECD (2019, updated 2024). Recommendation of the Council on Artificial Intelligence. OECD/LEGAL/0449.
International AI principles adopted by 47+ countries; backs accountability and transparency claims.
Read sourceEuropean Parliament & Council (2024). Regulation (EU) 2024/1689 of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act).
EU legal framework on AI risk classes, transparency, and human oversight — directly relevant to enterprise compliance.
Read sourceBommasani, R., Hudson, D. A., Adeli, E., Altman, R., et al. (2021). On the opportunities and risks of foundation models. Stanford CRFM, arXiv:2108.07258.
Foundational survey from Stanford CRFM on capabilities, risks, and governance of large foundation models.
Read sourceAmershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., & Zimmermann, T. (2019). Software engineering for machine learning: A case study. In Proceedings of ICSE-SEIP 2019, 291–300.
Microsoft Research study showing why ML in production needs human-in-the-loop checkpoints and explicit governance.
Read sourceMitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D., & Gebru, T. (2019). Model cards for model reporting. In Proceedings of FAT* 2019, 220–229.
Origin of the "model card" — supports the explainability/auditability claim in our AI-with-human-control message.
Read sourceWirtz, J., Patterson, P. G., Kunz, W. H., Gruber, T., Lu, V. N., Paluch, S., & Martins, A. (2018). Brave new world: Service robots in the frontline. Journal of Service Management, 29(5), 907–931.
Frequently-cited framework for thinking about autonomous service agents and where humans stay in the loop.
Read sourceAccounting
Weaver's Financial Ops is built on a research-grade accounting model. The lineage starts with Pacioli's 1494 codification of double-entry bookkeeping, runs through Ellerman's 1985 reformulation in group-theoretic terms, and culminates in the K3 Labs paper on type-safe algebraic accounting that backs Weaver's ledger.
Pacioli, L. (1494). Summa de arithmetica, geometria, proportioni et proportionalità. Particularis de computis et scripturis. Venice.
The 1494 publication that codified double-entry bookkeeping — the historical anchor for any algebraic-accounting claim.
Read sourceEllerman, D. P. (1985). The mathematics of double entry bookkeeping. Mathematics Magazine, 58(4), 226–233.
Reformulation of double-entry as group theory over additive abelian groups — basis for algebraic accounting.
Read sourceEllerman, D. P. (2014). On double-entry bookkeeping: The mathematical treatment. Accounting Education: An International Journal, 23(5), 483–501.
Modern restatement of the algebraic foundation of accounting; cited by the K3 Labs algebraic-accounting paper.
Read sourceK3 Labs (2024). Algebraic Accounting: A Type-Safe Mathematical Foundation for Computational Accounting.
Weaver/K3 Labs in-house paper; the technical depth proof point behind Financial Ops.
Read sourceAssociation of Certified Fraud Examiners (2024). Occupational Fraud 2024: A Report to the Nations.
ACFE biennial study; widely-cited 5% of revenue lost to fraud and expense-reimbursement scheme statistics.
Read sourceCommittee of Sponsoring Organizations of the Treadway Commission (2013). Internal Control — Integrated Framework.
The COSO internal control framework — references for control-design and SOX compliance arguments.
Read sourceExpense & fraud
QuickExpense's real-time fraud detection is anchored in the ACFE's biennial Report to the Nations and the COSO Internal Control framework — the two most widely-cited authorities on occupational fraud and the controls that catch it.
Association of Certified Fraud Examiners (2024). Occupational Fraud 2024: A Report to the Nations.
ACFE biennial study; widely-cited 5% of revenue lost to fraud and expense-reimbursement scheme statistics.
Read sourceCommittee of Sponsoring Organizations of the Treadway Commission (2013). Internal Control — Integrated Framework.
The COSO internal control framework — references for control-design and SOX compliance arguments.
Read sourceERP
The "you don't have to rip out QuickBooks to grow up" argument on the comparison page is grounded in two decades of well-documented ERP implementation outcomes — from the Standish CHAOS reports to McKinsey's analysis of large IT projects to Panorama Consulting's annual ERP study.
Standish Group International (annual). CHAOS Report. The Standish Group, West Yarmouth, MA.
Long-running study of project success/failure rates across IT projects — anchor for "implementation risk" claims.
Read sourceBloch, M., Blumberg, S., & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey Quarterly.
17% of large IT projects go so badly they threaten the company; canonical citation for ERP implementation risk.
Read sourcePanorama Consulting Group (annual). The ERP Report. Denver, CO.
Annual ERP implementation outcomes survey — cost overruns, schedule slippage, benefit shortfalls.
Read sourceCRM
The CRM Graveyard campaign rests on academic CRM research showing that customer-relationship management succeeds as a process embedded in operations, not as a standalone tool. References include Reinartz's empirical CRM study and the Payne & Frow strategic framework, complementing the industry data already cited on /crm-graveyard.
Reinartz, W., Krafft, M., & Hoyer, W. D. (2004). The customer relationship management process: Its measurement and impact on performance. Journal of Marketing Research, 41(3), 293–305.
Foundational empirical CRM study — operationalises CRM as a process and measures its actual impact on firm performance.
Read sourcePayne, A. & Frow, P. (2005). A strategic framework for customer relationship management. Journal of Marketing, 69(4), 167–176.
Strategic CRM framework — supports the argument that CRM lives in a broader operations context, not as a standalone tool.
Read sourceAgentic marketing
Growth Engine — Weaver's deep marketing agent — sits inside an emerging academic literature on autonomous service agents and the boundary between machine and human work. References include Stanford CRFM's foundation-models survey and the leading service-research framework on AI in customer-facing roles.
Bommasani, R., Hudson, D. A., Adeli, E., Altman, R., et al. (2021). On the opportunities and risks of foundation models. Stanford CRFM, arXiv:2108.07258.
Foundational survey from Stanford CRFM on capabilities, risks, and governance of large foundation models.
Read sourceWirtz, J., Patterson, P. G., Kunz, W. H., Gruber, T., Lu, V. N., Paluch, S., & Martins, A. (2018). Brave new world: Service robots in the frontline. Journal of Service Management, 29(5), 907–931.
Frequently-cited framework for thinking about autonomous service agents and where humans stay in the loop.
Read sourceHuang, M.-H. & Rust, R. T. (2018). Artificial intelligence in service. Journal of Service Research, 21(2), 155–172.
Four-stage model of AI in service (mechanical → analytical → intuitive → empathetic) — useful frame for the marketing-agent pitch.
Read sourceLow-code / extensibility
Build Your Own — Weaver's extensibility model — is positioned within the broader low-code research showing that platforms which let domain experts build alongside engineers ship faster and accumulate less integration debt.
Sahay, A., Indamutsa, A., Di Ruscio, D., & Pierantonio, A. (2020). Supporting the understanding and comparison of low-code development platforms. In Proceedings of SEAA 2020, 171–178.
Comparative academic analysis of low-code platforms; supports Build Your Own positioning.
Read sourceForrester Research (annual). The Forrester Wave: Low-Code Development Platforms. Cambridge, MA.
Industry analyst coverage of low-code platforms.
Read sourcesrc/data/academic-references.ts and is mirrored in the internal knowledge graph at docs/messages/proof-points.md. Reference IDs are stable — they never get re-numbered.src/data/apps-research-citations.ts and use IDs 1–99. Academic / standard / foundational citations on this hub use IDs 100+.One platform, one truth. ERP, CRM, expense management, projects, and analytics — all built on Weaver's real-time Single Data Backbone.
Enterprise-grade data infrastructure that powers every Weaver app.
Six native business apps split between Strategy (Metric Tree, Business Intelligence, Growth Engine) and Operations (Project Management, Financial Ops, Sales Operations) — all on the Single Data Backbone.
What if your data platform came with native business apps? Weaver collapses Databricks + Salesforce + ERP + integration plumbing into one platform on a single real-time data backbone.
Keep the QuickBooks ledger your accountant loves. Add CRM, projects, inventory, BI, and AI agents on one data backbone.
A plain-language explanation of the Single Data Backbone — the architectural peer to Databricks and Snowflake that ships with native business apps already built on top.
Data silos are the side effect of stitched-together SaaS stacks.
Long-form thinking on the unified business platform: how to escape data silos, how AI agents fit into finance and growth, and the architecture behind the Single Data Backbone.