4 ms·

Correct, that piece is missing from the article. And the answer to that question is that a tax break is effectively a form of financing, so why not let Amazon (

Correct, that piece is missing from the article. And the answer to that question is that a tax break is effectively a form of financing, so why not let Amazon (or other major corporations) be on the hook for the note? Even when that financing is paid by future tax revenues, every tax payer in the region will sign up involuntarily for a little piece of that debt. For smaller projects, this incentive mechanism makes sense. However, HQ2 will create an enormous "supply chain pull" on every aspect of government, and those costs are impossible to accurately assess. Ignore any economists projections, those are worth less than the paper they are printed on when it comes to guaranteeing billions in public debt. Here is a fun question:, are these grass roots anti-amazon campaigns being boosted/funded by the few remaining cities in the running as a means to sabotage the other cities bids, from the inside?? The campaign leaders may not even know the real answer to that. Thats what I would do if I were Chicago!

pitaj 9y ago
No, it's not financing. It's not a giveaway. It's a rebate.
- ethagknight 9y ago
  many cities are offering all kinds of grants and tax credits, so there is even a bit of a giveaway component. It is a form of financing for the benefit of Amazon, and the forgone taxes will be paid by everyone else in the jurisdiction to cover costs incurred by the city on Amazon’s behalf.
yourapostasy 9y ago
> However, HQ2 will create an enormous "supply chain pull" on every aspect of government, and those costs are impossible to accurately assess. Rather than trying to account for the supply chain pull as you noted, I wish cities and states would standardize upon an open source formatting and presentation of the data in their accounting systems. Many competing analyses of costs to various jurisdictions can then arise from private citizens and organizations, and then we can pit them against each other historically to converge upon a small set of models that are consistently predictive. We can even then gather insightful analyses from weaving together accounting and GIS datasets, for example, that weren't possible before without creating entire new bureaucracies. With more accurate cost management accounting models, we can then more reliably challenge organizations petitioning for specific tax concessions: we can reasonably accurately model the influx of X thousand employees to have $Y impact upon the cost accounting structure over Z years. NPV of that cost is $N. If spread out over F forecasted years of the concession you are proposing, at equivalent long-term bond rate of your corporation of P% at your longest-projected credit quality, then that comes to $T total cost to the jurisdiction over the time period. Then the per-employee per-$10,000 wage-adjusted cost burden to the jurisdiction on a per-unit basis becomes a calculated, known amount. Tilt the unit measure towards favoring lots of employees at moderate wages instead of a few employees at extremely high wages to incentivize high monetary velocity in the local economy, lest the extremely high wages of a few employees get translated away into capital gains-structured instruments. Compare that to existing employment data, and you know if the jurisdiction is over-paying or not for the concessions. And now the jurisdictions have a metric against which to demand a surety bond: with any future adjustments to wage and/or employee count, if it falls below a certain threshhold, the jurisdiction can collect upon a proportional amount in the surety bond for non-performance. Benefits dollars don't count, because the jurisdiction is only interested in the localized monetary velocity impact upon the localized economy that comes from wages.
- tinymollusk 9y ago
  Something I've been wondering about for a while now... Would it be possible to train an algorithm to identify similar characteristics of data from different schema? Looking at the actual data, I mean, and inferring a translation table or the like? I have a background in data engineering and don't really know where I'd get started. But if you could figure out a way to throw differently schema'd data at an algorithm and have it try to create a universal schema, you'd be wealthy. There would be a ton of challenges, but the problem you described seems like a societally valuable one to solve.
  - yourapostasy 9y ago
    That's pretty much a description of a chunk of process re-engineering gigs, and even with the data, metadata, domain experts, meetings, and documentation, the results are a struggle to obtain, so any solution will need to set some appropriate expectations. You might find some traction looking into automated ontology building, which has some promising tangents. But I think expecting any black box approach to yield high-fidelity results will end in tears, so there has to be more than just the schema'd data. For some kinds of data like account numbers, phone numbers, names, and addresses, it is possible to envision some kind of algo. But that's not where the interesting action happens. After working with lots of application developers over the years, I've learned they cram the damndest bits of information into databases, and it's dangerous to make assumptions about how they use the data (whether temporally, structurally, computationally, *etc.). Sometimes with absolutely no rhyme or reason to what or why, either; the rationale and logic is embedded entirely in front of the database within the application code. Without access to that code, even process re-engineering teams are flummoxed at just understanding a schema, not to speak of porting it. So I find it challenging to envision a scenario where inspecting only the data can yield better results; by the time we're restricting ourselves to only the data, and only at a snapshot in time, we've lost too many bits of information, and the resolution of the solution is too coarse-grained to be universally useful. As we add more inspection time, more fine-grained snapshots, and more kinds of data however, resolution goes up; the real question becomes just how much is needed to generate a MVP.

pitaj 9y ago

No, it's not financing. It's not a giveaway. It's a rebate.

ethagknight 9y ago
many cities are offering all kinds of grants and tax credits, so there is even a bit of a giveaway component. It is a form of financing for the benefit of Amazon, and the forgone taxes will be paid by everyone else in the jurisdiction to cover costs incurred by the city on Amazon’s behalf.

yourapostasy 9y ago

> However, HQ2 will create an enormous "supply chain pull" on every aspect of government, and those costs are impossible to accurately assess. Rather than trying to account for the supply chain pull as you noted, I wish cities and states would standardize upon an open source formatting and presentation of the data in their accounting systems. Many competing analyses of costs to various jurisdictions can then arise from private citizens and organizations, and then we can pit them against each other historically to converge upon a small set of models that are consistently predictive. We can even then gather insightful analyses from weaving together accounting and GIS datasets, for example, that weren't possible before without creating entire new bureaucracies. With more accurate cost management accounting models, we can then more reliably challenge organizations petitioning for specific tax concessions: we can reasonably accurately model the influx of X thousand employees to have $Y impact upon the cost accounting structure over Z years. NPV of that cost is $N. If spread out over F forecasted years of the concession you are proposing, at equivalent long-term bond rate of your corporation of P% at your longest-projected credit quality, then that comes to $T total cost to the jurisdiction over the time period. Then the per-employee per-$10,000 wage-adjusted cost burden to the jurisdiction on a per-unit basis becomes a calculated, known amount. Tilt the unit measure towards favoring lots of employees at moderate wages instead of a few employees at extremely high wages to incentivize high monetary velocity in the local economy, lest the extremely high wages of a few employees get translated away into capital gains-structured instruments. Compare that to existing employment data, and you know if the jurisdiction is over-paying or not for the concessions. And now the jurisdictions have a metric against which to demand a surety bond: with any future adjustments to wage and/or employee count, if it falls below a certain threshhold, the jurisdiction can collect upon a proportional amount in the surety bond for non-performance. Benefits dollars don't count, because the jurisdiction is only interested in the localized monetary velocity impact upon the localized economy that comes from wages.

tinymollusk 9y ago
Something I've been wondering about for a while now... Would it be possible to train an algorithm to identify similar characteristics of data from different schema? Looking at the actual data, I mean, and inferring a translation table or the like? I have a background in data engineering and don't really know where I'd get started. But if you could figure out a way to throw differently schema'd data at an algorithm and have it try to create a universal schema, you'd be wealthy. There would be a ton of challenges, but the problem you described seems like a societally valuable one to solve.
- yourapostasy 9y ago
  That's pretty much a description of a chunk of process re-engineering gigs, and even with the data, metadata, domain experts, meetings, and documentation, the results are a struggle to obtain, so any solution will need to set some appropriate expectations. You might find some traction looking into automated ontology building, which has some promising tangents. But I think expecting any black box approach to yield high-fidelity results will end in tears, so there has to be more than just the schema'd data. For some kinds of data like account numbers, phone numbers, names, and addresses, it is possible to envision some kind of algo. But that's not where the interesting action happens. After working with lots of application developers over the years, I've learned they cram the damndest bits of information into databases, and it's dangerous to make assumptions about how they use the data (whether temporally, structurally, computationally, *etc.). Sometimes with absolutely no rhyme or reason to what or why, either; the rationale and logic is embedded entirely in front of the database within the application code. Without access to that code, even process re-engineering teams are flummoxed at just understanding a schema, not to speak of porting it. So I find it challenging to envision a scenario where inspecting only the data can yield better results; by the time we're restricting ourselves to only the data, and only at a snapshot in time, we've lost too many bits of information, and the resolution of the solution is too coarse-grained to be universally useful. As we add more inspection time, more fine-grained snapshots, and more kinds of data however, resolution goes up; the real question becomes just how much is needed to generate a MVP.